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

[Dan Armak]

On Tuesday 03 February 2004 13:19, Kevyn Shortell wrote:
> 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.

If that's the case, we won't be helping fix the problem, we'll just have a 
hopefully never-broken stable tree and a sometimes-broken main tree. 

I don't know the details of the accidental deletions. In fact not having 
committed to Gentoo cvs in about 7 months (though hoping to do so again 
sometime soon) I don't know how much e.g. repoman can help in such cases. Is 
it a really insoluble problem with the keywords system and current tools, or 
just developers who aren't careful/thorough enough?

In either case, stable-marked ebuilds shouldn't only ever be removed at their 
set 'timeout' dates every quarter, at which point the entire tree is 
rechecked for deps etc. anyway. As for other modifications, if an ebuild is 
marked stable for one arch but not for another, any change to it that's not 
meant to affect the stable tree needs a new revision. Is it too much to ask 
that developers adhere to rules like these?

I can understand a separate stable tree if we expect that stable and 
non-stable keywords will rarely be given to the same ebuild revision, thus 
eliminating the single-tree benefit of code sharing/reuse. That would however 
imply that many ebuilds will be revision-bumped (not version-bumped) even 
though they've existed for a long time (to enter the stable tree) and a newer 
version is usually available. Does someone have statistics or predictions for 
this?

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

I wasn't complaining about introducing extra keywords, just that they weren't 
consistent with existing ones. As I understand you, you agree that the new 
keywords simply represent a gradual increase in known/perceived package 
stability and testedness, a difference in quality and not in quantity. Is 
this correct?

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

Yes. However, the GLEP and what's been said in the thread so far hasn't 
addressed any (formal?) extra testing etc. to be performed by us, only 
judging that a package is stable. Is this still going to be left at the 
maintainer's discretion?

-- 
Dan Armak
Gentoo Linux developer (KDE)
Matan, Israel
Public GPG key: http://dev.gentoo.org/~danarmak/danarmak-gpg-public.key
Fingerprint: DD70 DBF9 E3D4 6CB9 2FDD  0069 508D 9143 8D5F 8951