Re: [gentoo-server] Stable Portage tree

[Lance Albertson]

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 <ramereth@g.o>
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