[gentoo-dev] The problem of stable/current. Was: Re: [gentoo-dev] the vision for Gentoo

[James Yonan]

> > 3) How do we best implement this vision?
>
> I like the recent developments in this regard, namely the proposal for
> the new managment structure and GLEPs (which as a formal way of
> proposing new features for the distribution can do great things for
> user-dev interaction). *But* another thing I'd like to see (which may
> contradict some of my aforementioned thoughts), is Gentoo being a little
> less of a moving target: clear definitions of goals for a certain
> release, an easy to access roadmap (both should be taken care of by the
> new managment structure), clear responsibility for package
> maintainership (taken care of by herds I guess) and things like this.
>
> About how to achieve this I'm not quite sure, although the BSD way of
> -stable/-current seems to be a viable solution to some of my issues, it
> somehow doesn't feel "gentooish" to me.

Just to throw out an idea on creating a generalization to stable/current (I'm
new to Gentoo, so I'm not sure how much of this has already been done, or to
what extent these ideas have already been made concrete in the portage concept).

Why not create a notion of a distribution "checkpoint"?

A checkpoint is a file that contains all information necessary to build a
particular gentoo distribution as it existed at some point in time, similar to
the idea of a cvs tag, or saving the game before you do something that's
likely to get you killed :)  Taking the idea further, a checkpoint file could
be created as a snapshot of a distribution as it exists on a given machine, or
it could be edited by a distribution maintainer to favor a more conservative
or more experimental build, or you could extract a checkpoint that represents
the gentoo portage tree cvs at a particular date and time.  When you emerge
gentoo on a particular machine, you could specify an optional checkpoint file,
or select from a list of checkpoint files which have known properties such as
Stable, Experimental, etc.  Additionally, anyone could publish their own
checkpoint file, and others could use it to build similar distributions for
themselves. For example, someone with 400 days of uptime on a heavily used
server would have a checkpoint file which would be potentially valuable for
others seeking a very solid distribution.

As far as the format of the checkpoint file is concerned, it would basically
be a patch against a known, benchmark snapshot of the gentoo portage tree
(expressed as a cvs tag), and would be presented in a way that would bring the
power of diff, patch, and cvs (+ some of the distributed repository concepts
that are coming out of bitkeeper) to bear on the problem of evolving,
mutating, and merging distributions.

There are other potential benefits to the checkpoint concept.  Security
updates could be released as patches to a distribution checkpoint, allowing
stable users to get the minimal upgrade needed to implement the security fix,
rather than forcing a total upgrade.

This could help do away with an either-or stable or experimental designation,
as there would be a set of published stable checkpoints, each with their own
empirical history to back up their claims to stability.

In a lot of respects, the current cvs organization of gentoo makes this a very
straightforward concept, as a checkpoint simply becomes a patch against a
particular known snapshot of the gentoo portage tree.  So in the same way that
people start with vanilla kernels and then add patches, so too could you start
with a known gentoo benchmark release and then patch the distribution with a
"distribution patch" to make something games-centric, embedded centric,
stability-centric, etc.

I tend to think of gentoo as being a kind of source code for defining
distributions, and I think this concept fits in very nicely with Gentoo's
meta-distribution character.  In fact, I suspect that diffing, patching, and
merging portage trees is something that is already commonly done with a
distribution such as gentoo.  My proposal would then be to make it more
accessible, and better integrated.  The goal would be to create the
documentation and infrastructure so that someone could type "emerge search
distributions" and get a list of different possible gentoo distributions.  The
implementation of this would require an expansion of the .ebuild file concept,
so that a distribution checkpoint could be represented as an ebuild.  In that
sense ebuilds would become nested, i.e. a whole portage tree could be
minimally encapsulated within one .ebuild file, where the portage tree would
be represented as some known benchmark tree + a patch delta.

Just some ideas...

James


--
gentoo-dev@g.o mailing list