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

[Kurt Lieber]

On Tue, Feb 03, 2004 at 12:04:59PM +0200 or thereabouts, Dan Armak wrote:
> A real separate cvs branch seems like a lot of extra work; most updates going
> into the stable branch will probably also go into the main tree. What am I
> missing?

A key part of the GLEP is ensuring that ebuilds stay in the tree for a
minimum of one year.  As has been proven time and time again, we don't have
the necessary QA or control over our current tree to offer this feature, so
I felt it was betetr implemented by offering a separate tree.  

Also, with one tree, we cannot offer atomic updates to our users.  That is
to say, with one tree, there would have to be some period of time where the
stable tree was 'in flux' as devs went through and marked new ebuilds
stable.  With a separate tree, devs have an entire quarter where they can
mark things stable at their leisure.  Then, at a pre-defined date, we pull
those ebuilds and can offer one, consistent tree to those folks who want
the stable branch.

> About keyword naming, I agree with Stuart's note elsewhere in the thread that
> 'stable' is misleading. I also want to ask how the transition of
> arch-->~stable:arch-->stable:arch is different from the existing transition
> of ~arch-->arch.

'stable' is meant to indicate that the tree is a stable one.  Not that the
ebuilds within them are more stable.  However, down the road, I would
hope/expect that our nascent QA efforts would expand and offer additional
QA around these ebuilds as well.  That's outside the scope of this GLEP,
however.

As for your question on transition, for 95% of all stable ebuilds, the path
should be:

~arch --> arch --> stable:arch

~stable is there primarily for off-cycle updates.  If we need to issue a
GLSA and updated ebuild with very little testing, it would be included in
the stable tree marked as ~stable:arch.  Then, after 'adequate' testing, it
would be moved to stable:arch

I didn't explicitly state this in the GLEP because I don't want to have
this be the only thing it can be used for.  Depending on how people start
using this tree, we may look to expand to use it for other purposes.

> One possible distinction is: stable status is given to a package that is
> widely enough used and respected in the big bad world and has no known bugs,
> as opposed to a package that's in portage for a month and has no bugs but
> hasn't actually seen much use or been a target for attempted attacks. The
> latter would never move beyond a regular arch keyword.
>
> Some ebuilds might perhaps never be considered for the stable tree at all
> because the target audience demonstrably isn't interested in them (based also
> on actual usage data after the tree is up).
>
> Both these are an RFC more than a suggestion; I want to understand the GLEP's
> idea, not propose an alternative of my own.

I understand the uncertainty, but at the same time, I want to have some
uncertainty built into the GLEP.  Right now, there is a demonstrable need
for enterprise users to have a more stable tree than we currently offer.
That is the primary purpose of creating a separate tree.

However, it is entirely possible that we will extend and expand this tree
to be used in other ways.  I don't want this GLEP to say "this is the only
way this tree may be used" because I'd like to leave some room in it to
grow and expand depending on the needs of our users.

At least initially, I expect a lot of server-specific ebuilds to make it
into the stable tree as these are the ones that our users have expressed an
interest in so far.  As such, if this GLEP is approved, it will be where my
initial focus goes -- making sure MTAs, LAMP stuff, etc. make their way
into the tree.

In terms of what constitutes 'stable', that will largely be left up to the
herd and/or package maintainer. Remember, 'stable' refers more to the fact
that the tree itself does not change, rather than the ebuilds themselves
being more stable.  (This is another example of something that may change
down the road once we improve our QA efforts)

--kurt