Re: [gentoo-dev] Revisiting GLEP 19

[Olivier Crete <tester@gentoo.org>]

Hey,


On Wed, 2004-07-21 at 16:00 -0400, Chris Gianelloni wrote:
> > 4/ we will need to have a policy about how long we'll support a profile, 
> > and a procedure for end-of-lifing profiles. (probably don't want to 
> > support a single profile for more than 2 years)
> 
> I think we had decided that a good number was 4 releases.  Now, the
> length of time for that would be determined by the release schedule,
> naturally.  The biggest problem will be our lack of manpower to back
> port fixes.  I really don't see us overcoming this problem any time
> soon.

Four releases a year is way to many.. after two years its 8 releases to
support.. This vastly exceeds our current man-power.. Debian with its
over 1000 devs only maintains one.  One a year seems like a better
number to me (maybe two a year).

In the multiple profile scenario.. that would create possibly hundreds
of ebuilds to be kept in the tree for a single package (one per release
per arch and then a few unstable... thinking of a package like glibc).. 


> I can see how profiles could be used to accomplish this sort of thing,
> but pinning of versions would not be the way to go about it.

I agree


> For simplicity, I'm going to name everything, but none of this is set in
> stone.  For one, the "gentoo-x86" CVS module would be come
> "gentoo-current", as it reflects the actual usage and state of the
> tree.  The profiles in the current tree would have their versions
> removed, as this is a fluid target.  This matches our current tree the
> best, and allows for us to make dynamic changes to the profiles between
> releases.  For example, default-x86-2005.0 (or
> default-linux/x86/2005.0), would become default-linux/x86/current.  Each
> release tree would be identified as such.  I'm going to work with
> cascading profiles, to make my life easier.  At release time, a branch
> is made for the release.  We would take the stable ebuilds/packages from
> gentoo-current and drop it into gentoo-2005.0-release and a new profile
> default-linux/x86/2005.0 would be created.  This profile would never
> change.  If there were multiple sets of stages created, such as the
> amd64 release for 2004.2, which will have both gcc 3.3 and gcc 3.4
> stages, a sub-profile would be created,
> default-linux/amd64/2005.0/gcc34.
> 
> At this point, the -release tree is turned over to -releng and the arch
> leads/maintainers for preparation for the impending release.  If changes
> are needed that only affect the LiveCD/GRP, they go into the tree
> directly.  If changes are needed that affect the package as a whole, the
> package maintainer is contacted, and the package is fixed in both the
> -current and -release trees.  At some point, the tree is frozen and a
> snapshot is made.  This becomes the official snapshot for that release. 
> A new rsync mirror set is created for the tree, and the make.globals
> SYNC is set to that new rsync mirror,
> rsync://rsync.gentoo.org/gentoo-2005.0-release/.  The stages/LiveCD/GRP
> is built for the release, and everything is golden.  The things that are
> marked as "stable" are never changed via rsync in this tree, as they are
> the unchanging base.  The release is made, the planets align, and there
> is peace for a thousand generations...

I like the idea of a separate tree.. But if it really rarely changes,
rsync is just overkill and will overburden our mirrors.. Lets just make
it a tarball and put the enhancements in a rsync'ed overlay. Rsync is
for stuff that changes...


> ...until disaster strikes and a package has a security vulnerability. 
> At this point, the package is patched, a GLSA is released, and the new
> ebuild goes into the tree as ~arch.  You will notice that I have left
> out the whole "who does the updates" part of this and there is a good
> reason for it.  I haven't got a clue.  This would need to be decided by
> interest.  After all, many people are not going to be very excited about
> applying patches to old versions of software, and that's ok.
> *** This is the weakness in not only my plan, but ANY "Enterprise
> Gentoo" plan ***

This overlays should probably each have their own cvs module (or all be
directories under the same module, I dont really care... Where all
package maintainers would have access.. And then we can mark them stable
using the same kind of procedures we currently use for GLSAs...

Also, the problem with maintaining older versions is that we need to
have at least one machine available for each version where the concerned
devs can test security updates.. Ok, maybe at least one per
architectures using chroots... but its still a lot of  infrastructure..
That's why reducing the number of stable releases to maybe even just one
a year might be a good idea.



-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list