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

[Kevyn Shortell]

On Tue, 2004-02-03 at 02:04, Dan Armak wrote:

These are just my opinions, don't claim to be an expert bug having
worked in a production enviroment with a large quanity of systems....

> On Monday 02 February 2004 17:17, Kurt Lieber wrote:
> > Please take a moment to review the GLEP and offer any feedback or ask any
> > questions.
>
> If we're introducing stable keywords, why do we need a cvs branch? So far
> keywords have been used to identify logical trees and people have been
> talking about changing the cvs/rsync setup somehow to allow users to fetch a
> tree with just the keywords they want. Ebuild revision numbers allow
> different ebuilds for different keywords/trees for the same package version.
>
> 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 lot of ebuilds have been 'accidently' deleted by over-zealous space
reclaimation workers not knowing which builds work on all supported
arches.  

Yes a stable branch is a lot of work. But that's the whole point. It is
a 'stable' branch thereby implying a lot of work has gone into it to
make it so. Until we can go 6 months without someone deleting a critical
ebuild that's required by an alt-arch just because they their particular
arch has a newer version, we need a seperate 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.

From an enterprise perspective having something tagged stable after 2
weeks, does not qualify as stable, that's enough to move it to the alpha
stage. Having something beat on for a month with no critical bugs might
qualify for the beta stage, have it go for 2 months without any
significant bugs might qualify for the stable monkier. Just because it
doesn't have any obvious bugs doesn't mean there isn't any. Memory leaks
come to mind. Those take days, weeks sometimes to be flushed out.

>
> If it isn't different and it's just a matter of the package being more and
> more tested and used and proven without known (unfixed) bugs/vulnerabilites,
> I don't think it's appropriate to create keywords by adding several modifiers
> to an arch's name (~ and stable). We're not really combining the properties
> of ~ and 'stable', and might as well assign stability levels with keywords
> like 0:x86 for ~x86, ..., 3:x86 for stable:x86.

I think this is where having a seperate branch would actually help. If
it's in the stable branch, there's no keyword required to tag it as
such.

>
> Or, what is the difference? The GLEP doesn't actually explain the meaning of
> 'stable' marking - the uncertainty Stuart refers to.
>
> 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.

It makes sense. Packages in wide usage get significant bug reports
compared to those that aren't. However it's almost impossible to
determine currently if a package in portage has seen much use or not. 

Bug reports are some indication, but not always. I had someone after 3
weeks of bitching about to his friends and others finally come on the
irc channel and say pcmcia doesn't seem to work very well on the kernel
version he had tried. I asked him to fill out a bug report so we could
get more that it just didn't work and we'd be happy to take a whack at
fixing it. He said he hadn't filled out a bug report and when he got
around to it he would (still hasn't).

Just goes to show that something in heavy use, with no bug reports can't
really always be considered as stable, just because you haven't seen any
issues. If we're going to have a real 'stable' profile/branch/whatever
it needs to have serious testing and accountability before we slap the
stable monkier on it. Our reputation depends on it.

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

Why should that be a determining factor? If the package has been
*proven* stable, why not consider it? Determining what the target
audience of stable packages seems to be a no brainer. If it got included
on a RH CD, it would lead creedence to the packages stability and
interest. After all SOMEONE wanted it, right? =)

> Both these are an RFC more than a suggestion; I want to understand the GLEP's
> idea, not propose an alternative of my own.
-- 
trance @ irc.freenode.net #gentoo-ppc
Kevyn Shortell <trance@g.o>
Gentoo PPC Operational Manager / PPC dev