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