On Tue, Feb 03, 2004 at 12:04:59PM +0200 or thereabouts, Dan Armak wrote: > 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 key part of the GLEP is ensuring that ebuilds stay in the tree for a minimum of one year. As has been proven time and time again, we don't have the necessary QA or control over our current tree to offer this feature, so I felt it was betetr implemented by offering a separate tree. Also, with one tree, we cannot offer atomic updates to our users. That is to say, with one tree, there would have to be some period of time where the stable tree was 'in flux' as devs went through and marked new ebuilds stable. With a separate tree, devs have an entire quarter where they can mark things stable at their leisure. Then, at a pre-defined date, we pull those ebuilds and can offer one, consistent tree to those folks who want the stable 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. 'stable' is meant to indicate that the tree is a stable one. Not that the ebuilds within them are more stable. However, down the road, I would hope/expect that our nascent QA efforts would expand and offer additional QA around these ebuilds as well. That's outside the scope of this GLEP, however. As for your question on transition, for 95% of all stable ebuilds, the path should be: ~arch --> arch --> stable:arch ~stable is there primarily for off-cycle updates. If we need to issue a GLSA and updated ebuild with very little testing, it would be included in the stable tree marked as ~stable:arch. Then, after 'adequate' testing, it would be moved to stable:arch I didn't explicitly state this in the GLEP because I don't want to have this be the only thing it can be used for. Depending on how people start using this tree, we may look to expand to use it for other purposes. > 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. I understand the uncertainty, but at the same time, I want to have some uncertainty built into the GLEP. Right now, there is a demonstrable need for enterprise users to have a more stable tree than we currently offer. That is the primary purpose of creating a separate tree. However, it is entirely possible that we will extend and expand this tree to be used in other ways. I don't want this GLEP to say "this is the only way this tree may be used" because I'd like to leave some room in it to grow and expand depending on the needs of our users. At least initially, I expect a lot of server-specific ebuilds to make it into the stable tree as these are the ones that our users have expressed an interest in so far. As such, if this GLEP is approved, it will be where my initial focus goes -- making sure MTAs, LAMP stuff, etc. make their way into the tree. In terms of what constitutes 'stable', that will largely be left up to the herd and/or package maintainer. Remember, 'stable' refers more to the fact that the tree itself does not change, rather than the ebuilds themselves being more stable. (This is another example of something that may change down the road once we improve our QA efforts) --kurt
pgp00000.pgp
Description: PGP signature
