Re: [gentoo-dev] Revisiting GLEP 19

[Chris Gianelloni]

On Tue, 2004-07-20 at 16:43, Dylan Carlson wrote:
> 1/ Many Gentoo users want the ability to update packages for fixes only
> (and not just for servers)

Agreed.

> 2/ Maintaining separate trees in CVS is probably asking too much of our
> current roster, plus requires adding infrastructure and getting everyone
> to mirror the new tree(s)

Agreed.

> 3/ Users already have a good understanding of what profiles are.  This is
> useful.

Possibly... The current Gentoo profile system would need to be modified
to allow for changes.  This might be workable using cascading profiles,
though.

> 4/ Creating separate CVS trees while also using profiles seems superfluous.

Agreed.

> Therefore I believe another possible solution is to change the way we use
> profiles (both in practice and in QA policy):

I'm not sure I like the idea of changing profiles for any reason.  As
many people agreed when I asked about the creation of the
default-x86-2004.2 profile for the switch from xfree to xorg-x11 on x86,
a user should expect the same packages be installed by the same profile,
no matter where in the release cycle or on what day they do their
install.  You *will* notice that I say "packages" and not "package
versions" in that statement.

> Implications:
>
> 1/ archs will need to have a regular, predictable release schedule,
> probably at least every six months.

Like our current quarterly release schedule?

> 2/ profiles will list specific package versions whenever possible.  e.g.:
> =sys-libs/glibc-2.3.2

This would make it impossible to upgrade the version.  A version should
never be pinned in a profile.

> 3/ we will need to prepare a list of packages which should not change
> unless the user switches profiles.  those packages (e.g., toolchain) in
> the current, and older profiles do not get updated except for fixes.

No package should change.  Package versions should only change for major
fixes/security updates.  I'm not sure I see the point in this one, since
the list would be redundant.

> 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.

> 5/ we will need to have documentation for users who are upgrading from one
> profile to another (upgrade warnings, instructions and considerations)

Agreed, whether it be profile-based or not.

> 6/ repoman will need to be enhanced to check the profiles before removing
> any ebuilds from the tree that might be needed.  specific versions pinned
> in profiles need to stay until the profile is changed.

I agree that changes would need to be made.  I just am not sure that a
profile is what would bring about such changes.

Honestly, the problem that we face is manpower.  Plain and simple.  In
many cases, we don't have enough developers for what we already are
doing.  No matter what we decide as a technical solution to a stable
tree, I just don't see a possible way to solve these problems without
adding a massive number of developers.

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.

Here is my ideas on how this could be done.  Feel free to rip them
apart... Some of the ideas here would require some large changes to our
Standard Operating Procedure.

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...

...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 ***


With my method, a user can change between releases simply by overriding
SYNC in make.conf to whatever release they wish, or even to -current. 
The upgrade would be just like doing a massive "emerge sync && emerge -u
world" after not syncing for 6 months.  Everything would upgrade
smoothly.  We would update the user's profile at sync time, too.  We
would need to include some form of logic to know whether our rsync
mirror choice has changed, and take appropriate actions.  For example,
if I were going from 2005.0 to 2005.1 and running an amd64 with the
gcc34 profile, if there is an amd64/2005.1/gcc34 profile, then the
switch is simple.  If amd64 has adopted gcc 3.4 as the default, then the
profile would revert to the default.

Is there anything I missed?

Discuss amongst yourselves...

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?