1 |
OK, as msot of the other folks who attended LWE will attest, a stable |
2 |
portage tree was the number one most-requested/discussed feature at the |
3 |
booth. So, here's a stab at summarizing the other flame^Wthread and |
4 |
suggesting some next steps... |
5 |
|
6 |
First off, some folks tried to bolt on some features to the GLEP 19. |
7 |
Things such as XML-based ChangeLogs might be nice, but they're outside the |
8 |
scope of this GLEP. So, I'm ignoring them for purposes of this discussion. |
9 |
|
10 |
Second, there was some question about how often the tree would be updated. |
11 |
The GLEP doesn't really specify this, but I think once a year is a |
12 |
reasonable timeframe. |
13 |
|
14 |
Third, many folks want long-term support of these releases. I *don't* |
15 |
think this is viable and am not willing to personally sponsor this. A core |
16 |
component of this GLEP is that we will *not* be backporting security fixes. |
17 |
(at least not as a rule) We will be relying on the versions that the |
18 |
original authors provide except in very unusual circumstances. The reason |
19 |
for this is simple -- we don't have the resources to guarantee that we can |
20 |
backport things (and, more importantly, guarantee that they'll work right |
21 |
once backported) Suppporting a profile for four or more years almost |
22 |
guarantees you'll be doing a lot of backporting. I don't plan to |
23 |
incorporate long-term support as part of this GLEP. That might, however, |
24 |
be an excellent opportunity for commercial companies with greater finanial |
25 |
resources than us. |
26 |
|
27 |
Fourth, the GLEP currently recommends use of a 'stable' keyword. A |
28 |
number of folks have suggested using a custom profile instead. This is |
29 |
less intrusive and doesn't require any changes to portage to make it work. |
30 |
It's also easier to maintain since everything is in one file. The main |
31 |
problem here is that all packages need to be explicitly listed in this file |
32 |
in order to be of any use. If we can get enough developer buy-in and maybe |
33 |
even add some repoman checks, this might be easier to manage... |
34 |
|
35 |
Finally, the current GLEP doesn't really address how to ensure a minimum |
36 |
life for all ebuilds in the tree. I'm open to suggestions on this, but the |
37 |
best idea I've heard so far is using a separate rsync module and removing |
38 |
the --delete option from the command used to populate it. |
39 |
|
40 |
So, at this point, I'm suggesting three changes to the GLEP: |
41 |
|
42 |
1) specify annual updates for the stable tree |
43 |
2) replacing the stable keywording stuff with stable profiling stuff |
44 |
3) adding a separate rsync module for the stable portage tree (or one for |
45 |
each release of the stable portage tree) |
46 |
|
47 |
With that, comments/suggestions are welcome. Please keep in mind that this |
48 |
is a very focused GLEP designed to provide a stable tree and predictable |
49 |
expiration of ebuilds to our users. It is not intended to propose other |
50 |
far-reaching changes to Gentoo Linux. |
51 |
|
52 |
--kurt |