[gentoo-dev] GLEP 19: Gentoo Stable Portage Tree -- ideas

Hi, I was recently reading this post [1] about gentoo's future, it
mentioned a few items in relation to enterprise Gentoo, and that it
currently needs features that just aren't available yet.

One such example of a feature thats not available yet is GLEP 19: Gentoo
Stable Tree [2].
Now, I notice that it is over a year old since last edit, and that it is
still Draft, not Differed or Rejected.
So, I propose to change it in hopes of making it a feasible,
implementable idea.

The part of this GLEP that specifically is the issue, and making it
unable to be voted on, is the section concerning the exact details of
how/where the 'stable' tree would be located; currently this GLEP lists
a few ideas but settles on using KEYWORDS="stable". However, the point
was brought up (and noted inside of the GLEP) that in order for that new
keyword to work for independent archs, it would have to be
'stable:arch'. So, I am here to say 'No' to that idea. Specifically
because I believe it will make dev even greater then what it currently
is. Hence I propose that instead of a separate tree based on these
'stable:arch' keywords, the existing tree is used /with/ a new
keywording system: KEYWORDS="+arch" will denote these stable ebuilds.
Also, in order to prevent excess dev-work and to make a predictable
cycle, the following will also occur: prior to the release of the year's
..0 media (ex 2006.0) a script would be ran that add +arch for each arch
keyword (max one +arch per arch). Over the course of time, major bug
fixes and security updates would allow for items to be marked +arch
quickly, without necessarily waiting for the next media release.

When the .0 media is released, it would include the usual portage tree
in tar.bz2 which will serve as a static place for enterprise to install
Gentoo from. All security and Major bug fixes would be included in .1
and .2 releases, but the vast majority of the tree would remain the same
over the course of the year (enterprise's goals).

Also, a few items which can be considered for this stable tree:
- using a simple script it would be possible to make a copy of the tree
which only contains these +arch entries, this could be used to make
easier to manage tar balls of the stable tree for distribution to clients.
- the existing portage code would consider +arch as a subset of arch,
the reason both keywords will exist is to maintain compatibility with
older versions of portage which will not recognize this.

Anyways, I would personally like to see if this can stir some interest.
I would be willing to help test and help make this GLEP a reality,
however I can not implement this myself as I lack python skills, but I
do want to help the portage team, as much as I can, to make this happen,
as I have some great benefit from this added feature.

Also, I hope I covered everything, and if the response from the mailing
list is good I may consider revising the existing GLEP and prepare it
for submittal to the council in feburary, or march, depending on how
much revision the GLEP needs, and if my idea is better or worse then the
current solution proposed.

Thanks for taking the time to look at this, Please respond with personal
opinions (+ and -)

Andrew Muraco

Tuxp3

[1] http://article.gmane.org/gmane.linux.gentoo.devel/34870
[2] http://www.gentoo.org/proj/en/glep/glep-0019.html
--
gentoo-dev.DeleteThis@gentoo.org mailing list

Chris Bainbridge posted <623652d50601060100w2bd03634i.TakeThisOut@mail.gmail.com>,
excerpted below, on Fri, 06 Jan 2006 09:00:59 +0000:

> The problems being:
>
> 1) Manpower. There are already 10,000 open bugs in bugzilla (and
> growing) without adding more.
> 2) Lack of interest. Most developers aren't interested in supporting
> "old" packages.
> 3) The enterprise. Both of the above problems would be fixed if
> enterprises were contributing developers and/or money. However, they
> aren't, so why is that? The truth is most enterprises want to go to a
> big company to buy their software. They want one homogeneous binary
> system, not a flexible way of building packages from source, and they
> want someone else to do it and be responsible for it.

> The only way I can see to solve these problems is more automation. []
> For QA gentoo really needs a compile farm with automated compile,
> install and test (from those ebuilds that support it). Make the system
> smarter, instead of throwing more people at the problem.

You didn't say it, but it should be self-evident. The automation solution
is tied to money, which, ultimately, comes back to #3.

I know it's been said before, but really, Gentoo doesn't seem to fit the
enterprise mold well enough to get the enterprise money. There are
better fitting organizations out there, that require less direct
modificatiion to get them into the enterprise mold, so /they/ get the
enterprise money. I know some disagree with this and think Gentoo should
be specifically targeting the enterprise, but IMO, that's not Gentoo's
niche and never will be.

OTOH, it's entirely possible a Gentoo /based/ enterprise distribution may
emerge at some point. IMO, however, there's enough conflict with what
makes Gentoo great at what it does today, that such efforts should be
separate from Gentoo itself.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


--
gentoo-dev.TakeThisOut@gentoo.org mailing list