Phillip Berry wrote: > On Friday 23 September 2005 03:03, Sune Kloppenborg Jeppesen wrote: > >>On Thursday 22 September 2005 18:27, Lance Albertson wrote: >> >>>Well, the problem right now is what kind of a route do we want to take? >>>For example, if Gentoo wanted to try and maintain an enterprise ready >>>solution to the stable tree issue, I don't think we could do it. On the >>>other hand, if we wanted to establish a few tools/solutions that provide >>>some enterprise ready functionality, I think we may be able to do that. >> >>Unfortunately I think you're right. While I would like to contribute to the >>maintainance of a stable Portage tree, it is definately beyond what a >>handful of devs can accomplish in the long run. >> >>New docs on the other hand should be a better priority to start out with. >> >> >>>Anyways, I'd love to hear your feedback and opinions! >> >>And I'd love to help with the docs:-) > > > Hello, > > Could some point me to, or provide a more specific breakdown of some of the > roles and tasks that would need to be tended to? > > Forgive me if i appear ignorant to the problems and issues with maintaining > an > enterprise ready tree but in my mind running a stable tree would involve : > > 1. Identifiying a version of a package that is stable > 2. Marking that package as stable > 3. Pushing that package to the rsync servers > 4. ? > 5. ? > 6. ?
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. 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. 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. 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). 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. 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. 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 :). Thoughts on that rough plan? -- Lance Albertson <[EMAIL PROTECTED]> Gentoo Infrastructure | Operations Manager --- GPG Public Key: <http://www.ramereth.net/lance.asc> Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 ramereth/irc.freenode.net
signature.asc
Description: OpenPGP digital signature
