On Fri, 2005-09-23 at 11:20 -0500, Lance Albertson wrote: > The idea I had (at least initially), was using the snapshot releng > builds for their release as our base tree to use for a release. After > they finalize the tree, I'd see a group of folks going through and doing > another round of QA and fixing any more bugs that may crop up. That sounds reasonable. I suggest that new versions of ebuilds should be ~ARCHed so that dedicated updates are easier (no overlays etc.) > After its > been established as a 'good' tree, I'd see us releasing that as > something like 2005.1E or something like that. That part of a 'stable' > tree is relatively easy to do aside from any issues cropping up from the > QA section. Agreed > The real fun begins during the maintenance phase where GLSAs, and > critical software (data crippling type of things) updates need to be > updated in it. This is where we'd need to decide whether to go the back > port route, or just force folks to upgrade if the GLSA affects it. I'd say upgrade - backports would consume an extreme amount of manpower while testing still needs to be done by the end-user anyway. > Essentially, our group would be managing their own tree. It sounds > fairly simple, but to ensure a level of quality, we'd need to test the > new ebuild/upgrade in some type of QA environment (which we currently > don't have enough good man power for). That's a bit of a chicken-and-egg problem ;-) > Next, say when the next release comes out (2006.0E), we'd have to come > up with a clean upgrade path to ensure no breakages. This is the part > that will require a lot of time and effort. Ideally, it'd be nice if we > came up with a helper script to 'fix' things as the upgrade happens. So do we offer upgrades for 2005.1E or do we "force" people to upgrade at least bi-yearly?
> Last, we'd need to decide how long to keep a particular tree updated. If > we went on two releases per year, after 2 years we'd have 4 trees to > keep up to date and come up with upgrade plans for each of those. I think 2 years is reasonable, any users that wish to keep a tree longer should be prepared to support that themselves (and if that only means hiring three gentoo devs fulltime ;-) ) > Needless to say, doing it the 'right' way isn't very easy to do. Thats > one of the things our server team would need to establish is what kind > of level do we want to maintain. Thats kind of where the idea of a third > party would come into play and possibly help fund a few folks to do this > kind of work as a job :). Agreed. In the beginning a "static" tree would be a nice start though > Thoughts on that rough plan? (1) Create a 2005.1-static tree (2) start adding GLSA updates as they come up (3) add new ebuilds ~arch so that updates are user-controlled (4) slowly announce our plans and pull in more helpers (5) create an extended, more precise roadmap ;-) wkr, Patrick -- Stand still, and let the rest of the universe move
signature.asc
Description: This is a digitally signed message part
