[gentoo-dev] Improving stability - checkpoints

[gentoo-dev] Improving stability - checkpoints

[William McArthur]

[Sorry if this is a duplicate, I'm currently demonstrating a severe lack 
of email skills.]

The other day there was a discussion on IRC about improving the 
stability of the distro as a whole. The popular idea at the time was a 
stability metric applied to each package based on a few things. The 
following is my thoughts on how to improve the situation with minimal 
developer effort.

First, I don't think the stability metric idea won't have it's desired 
effect. The libpng problems would not be prevented with a stability 
metric. The problem was not with the package specificlly but the 
interaction between pacakges. Specifically packages that linked with 
libpng and expected libpng-1.0.* .

We need something to describe a stable system as a whole. There are 
other sumissions out there but I'm unconvinced that they would improve 
stability.

I propose something I've dubbed a checkpoint as a feature to be added to 
emerge and a step in our developement process. Every other month or so 
we have a package freeze where we create a new checkpoint. Checkpoint 
file(s) describe the reasonably stable leading edge of each package 
currently available. Then during this freeze we test pacakges, the 
interaction between packages and the upgrade process.

Checkpoints are not like the package.mask because they don't exclude 
packages and don't prevent the user from upgrading package past what is 
listed in the checkpoint file. They describe the newest packages that 
`emerge foo` or `emerge --update world` will upgrade to. The user is 
still free to specify a newer version manually if for some reason they 
want to. Think of them as a line in the sand where everything on one 
side is considered reasonably stable and tested.

I envision a tool, it could be part of emerge, that is like the 
java-config's --list-available-vms and --set-system-vm= arguments. The 
tool handles the selection of the current checkpoint file. For example:
============
$ emerge --list-checkpoints
x86-bleeding-edge
x86-curent-stable
x86-2002-apr
x86-2002-feb
Checkpoint is currently set to: x86-2002-feb
$ emerge --set-checkpoint=x86-2002-apr
Checkpoint is now set to: x86-2002-apr
============

The bleeding-edge and current-stable checkpoints are special. 
Bleeding-edge is effictivly no checkpoint at all, or always the newest 
packages. Current-stable is like a sym-link to the most recent 
checkpoint and is automatically updated when a new checkpoint is final. 
In the above example that would be x86-2002-apr.

Checkpoint files should not be changed once deemed final. Thus they 
should be written so to allow a little wiggle room for bugfixes, 
probably only within different releases of the same ebuild version.

This makes good use of a developers time beacuse they aren't chasing 
bugs due to all the variations of various pacages they didn't test.

Many users will like not having to compile every point release of a 
package that is needed by some package they are merging. This is a 
duplicate benefit of the world favorits and I think obsletes it.

Many more users will like the reduced risk of 'emerge --update world' 
leaving their system in a b0rken state. Users that want the bleeding 
edge can still have it by specifing a package version or the bleeding 
edge checkpoint file.

Checkpoints would only be considered supported until they are two or 
three checkpoints old.

I hope this makes sense. I'm having trouble keeping my thoughts straight 
and this is the second time I've written this due to a system crash.

As always, feed back is desired.

Sandy McArthur

Re: [gentoo-dev] Improving stability - checkpoints

[Bill Kenworthy]

One item I have not seen is the possibility of auto-rewinding something
like the libpng problem back to a working system.  CVS is a case in
point - when a build is broken, go back a version and build again. 
Williams checkpoint idea sounds similar to CVS in the way you can
specify versions.

Now this would be a *real* advance in taking some of the risk out of
bleeding edge for all users, average and developer.

BillK


On Sat, 2002-04-20 at 10:15, William McArthur wrote:
> [Sorry if this is a duplicate, I'm currently demonstrating a severe lack 
> of email skills.]
> 
> The other day there was a discussion on IRC about improving the 
> stability of the distro as a whole. The popular idea at the time was a 
> stability metric applied to each package based on a few things. The 
> following is my thoughts on how to improve the situation with minimal 
> developer effort.
> 
> First, I don't think the stability metric idea won't have it's desired 
> effect. The libpng problems would not be prevented with a stability 
> metric. The problem was not with the package specificlly but the 
> interaction between pacakges. Specifically packages that linked with 
> libpng and expected libpng-1.0.* .

Re: [gentoo-dev] Improving stability - checkpoints

[Terje Kvernes]

Bill Kenworthy <billk@iinet.net.au> writes:

  [ about checkpoints ]

> Now this would be a *real* advance in taking some of the risk out of
> bleeding edge for all users, average and developer.

  yup, and it should be very doable.  it is basically the same stuff
  as I've worked on recently, with a slightly different name.  :)

-- 
Terje