| 1 |
Hi, I was recently reading this post [1] about gentoo's future, it |
| 2 |
mentioned a few items in relation to enterprise Gentoo, and that it |
| 3 |
currently needs features that just aren't available yet. |
| 4 |
|
| 5 |
One such example of a feature thats not available yet is GLEP 19: Gentoo |
| 6 |
Stable Tree [2]. |
| 7 |
Now, I notice that it is over a year old since last edit, and that it is |
| 8 |
still Draft, not Differed or Rejected. |
| 9 |
So, I propose to change it in hopes of making it a feasible, |
| 10 |
implementable idea. |
| 11 |
|
| 12 |
The part of this GLEP that specifically is the issue, and making it |
| 13 |
unable to be voted on, is the section concerning the exact details of |
| 14 |
how/where the 'stable' tree would be located; currently this GLEP lists |
| 15 |
a few ideas but settles on using KEYWORDS="stable". However, the point |
| 16 |
was brought up (and noted inside of the GLEP) that in order for that new |
| 17 |
keyword to work for independent archs, it would have to be |
| 18 |
'stable:arch'. So, I am here to say 'No' to that idea. Specifically |
| 19 |
because I believe it will make dev even greater then what it currently |
| 20 |
is. Hence I propose that instead of a separate tree based on these |
| 21 |
'stable:arch' keywords, the existing tree is used /with/ a new |
| 22 |
keywording system: KEYWORDS="+arch" will denote these stable ebuilds. |
| 23 |
Also, in order to prevent excess dev-work and to make a predictable |
| 24 |
cycle, the following will also occur: prior to the release of the year's |
| 25 |
.0 media (ex 2006.0) a script would be ran that add +arch for each arch |
| 26 |
keyword (max one +arch per arch). Over the course of time, major bug |
| 27 |
fixes and security updates would allow for items to be marked +arch |
| 28 |
quickly, without necessarily waiting for the next media release. |
| 29 |
|
| 30 |
When the .0 media is released, it would include the usual portage tree |
| 31 |
in tar.bz2 which will serve as a static place for enterprise to install |
| 32 |
Gentoo from. All security and Major bug fixes would be included in .1 |
| 33 |
and .2 releases, but the vast majority of the tree would remain the same |
| 34 |
over the course of the year (enterprise's goals). |
| 35 |
|
| 36 |
Also, a few items which can be considered for this stable tree: |
| 37 |
- using a simple script it would be possible to make a copy of the tree |
| 38 |
which only contains these +arch entries, this could be used to make |
| 39 |
easier to manage tar balls of the stable tree for distribution to clients. |
| 40 |
- the existing portage code would consider +arch as a subset of arch, |
| 41 |
the reason both keywords will exist is to maintain compatibility with |
| 42 |
older versions of portage which will not recognize this. |
| 43 |
|
| 44 |
Anyways, I would personally like to see if this can stir some interest. |
| 45 |
I would be willing to help test and help make this GLEP a reality, |
| 46 |
however I can not implement this myself as I lack python skills, but I |
| 47 |
do want to help the portage team, as much as I can, to make this happen, |
| 48 |
as I have some great benefit from this added feature. |
| 49 |
|
| 50 |
Also, I hope I covered everything, and if the response from the mailing |
| 51 |
list is good I may consider revising the existing GLEP and prepare it |
| 52 |
for submittal to the council in feburary, or march, depending on how |
| 53 |
much revision the GLEP needs, and if my idea is better or worse then the |
| 54 |
current solution proposed. |
| 55 |
|
| 56 |
Thanks for taking the time to look at this, Please respond with personal |
| 57 |
opinions (+ and -) |
| 58 |
|
| 59 |
Andrew Muraco |
| 60 |
|
| 61 |
Tuxp3 |
| 62 |
|
| 63 |
[1] http://article.gmane.org/gmane.linux.gentoo.devel/34870 |
| 64 |
[2] http://www.gentoo.org/proj/en/glep/glep-0019.html |
| 65 |
-- |
| 66 |
gentoo-dev@g.o mailing list |
Archives