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
pgp00000.pgp
Description: signature
