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 <[EMAIL PROTECTED]> Gentoo PPC Operational Manager / PPC dev
signature.asc
Description: This is a digitally signed message part
