1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
Kurt Lieber wrote: |
5 |
|
6 |
| Second, there was some question about how often the tree would be updated. |
7 |
| The GLEP doesn't really specify this, but I think once a year is a |
8 |
| reasonable timeframe. |
9 |
| |
10 |
| Third, many folks want long-term support of these releases. I *don't* |
11 |
| think this is viable and am not willing to personally sponsor this. A |
12 |
core |
13 |
| component of this GLEP is that we will *not* be backporting security |
14 |
fixes. |
15 |
| (at least not as a rule) We will be relying on the versions that the |
16 |
| original authors provide except in very unusual circumstances. The reason |
17 |
| for this is simple -- we don't have the resources to guarantee that we can |
18 |
| backport things (and, more importantly, guarantee that they'll work right |
19 |
| once backported) Suppporting a profile for four or more years almost |
20 |
| guarantees you'll be doing a lot of backporting. I don't plan to |
21 |
| incorporate long-term support as part of this GLEP. That might, however, |
22 |
| be an excellent opportunity for commercial companies with greater finanial |
23 |
| resources than us. |
24 |
| |
25 |
|
26 |
My main concern here is that if you've got a core server, which |
27 |
typically has lifetime of 3 to 4 years, you don't want to be |
28 |
reinstalling it every year (in many cases you can't). That said, I |
29 |
agree that its unlikely there are resources to maintain a tree for years |
30 |
on end. As a compromise, if some consideration was given to easing |
31 |
migration, that would be suitable. Given the fact that servers have a |
32 |
very minimal level of software on them anyway, its probably not too much |
33 |
of a big deal. |
34 |
|
35 |
| |
36 |
| Finally, the current GLEP doesn't really address how to ensure a minimum |
37 |
| life for all ebuilds in the tree. I'm open to suggestions on this, |
38 |
but the |
39 |
| best idea I've heard so far is using a separate rsync module and removing |
40 |
| the --delete option from the command used to populate it. |
41 |
| |
42 |
|
43 |
I like this idea. That way if the end user doesn't want to upgrade, the |
44 |
original ebuild stays in portage and they can stick with that. |
45 |
|
46 |
Backporting has been mentioned in Greg k-h's post and I think thats |
47 |
something we want to stay away from. Ebuild maintainers may not have |
48 |
the programming skill necessary to backport fixes from one version of |
49 |
the software to another. The upstream maintainers are the experts in |
50 |
that respect and thats where that decision should stay. In my |
51 |
experience once the upstream maintainer stops maintaining a certain |
52 |
version of the software, migration to the new version is necessary anyway. |
53 |
|
54 |
The other downside to backporting is that it causes tonnes of false |
55 |
positives if you do any proactive network scanning. Not a major really, |
56 |
but its one of my pet hates 8) |
57 |
|
58 |
| So, at this point, I'm suggesting three changes to the GLEP: |
59 |
| |
60 |
| 1) specify annual updates for the stable tree |
61 |
| 2) replacing the stable keywording stuff with stable profiling stuff |
62 |
| 3) adding a separate rsync module for the stable portage tree (or one for |
63 |
| each release of the stable portage tree) |
64 |
| |
65 |
|
66 |
These all sound like good alterations, keeping the GLEP focussed is a |
67 |
sensible idea. |
68 |
|
69 |
Baz |
70 |
-----BEGIN PGP SIGNATURE----- |
71 |
Version: GnuPG v1.2.3 (GNU/Linux) |
72 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
73 |
|
74 |
iD8DBQFBFys7JvZkjpKMF2wRAutzAJ9pyJb/0VHtvuEOE3ggv2CIMpOGZACfZ2Cm |
75 |
sjiNxtYa8Q1HB+RKlZv9RzA= |
76 |
=630p |
77 |
-----END PGP SIGNATURE----- |
78 |
|
79 |
-- |
80 |
gentoo-dev@g.o mailing list |