1 |
Phillip Berry wrote: |
2 |
> On Friday 23 September 2005 03:03, Sune Kloppenborg Jeppesen wrote: |
3 |
> |
4 |
>>On Thursday 22 September 2005 18:27, Lance Albertson wrote: |
5 |
>> |
6 |
>>>Well, the problem right now is what kind of a route do we want to take? |
7 |
>>>For example, if Gentoo wanted to try and maintain an enterprise ready |
8 |
>>>solution to the stable tree issue, I don't think we could do it. On the |
9 |
>>>other hand, if we wanted to establish a few tools/solutions that provide |
10 |
>>>some enterprise ready functionality, I think we may be able to do that. |
11 |
>> |
12 |
>>Unfortunately I think you're right. While I would like to contribute to the |
13 |
>>maintainance of a stable Portage tree, it is definately beyond what a |
14 |
>>handful of devs can accomplish in the long run. |
15 |
>> |
16 |
>>New docs on the other hand should be a better priority to start out with. |
17 |
>> |
18 |
>> |
19 |
>>>Anyways, I'd love to hear your feedback and opinions! |
20 |
>> |
21 |
>>And I'd love to help with the docs:-) |
22 |
> |
23 |
> |
24 |
> Hello, |
25 |
> |
26 |
> Could some point me to, or provide a more specific breakdown of some of the |
27 |
> roles and tasks that would need to be tended to? |
28 |
> |
29 |
> Forgive me if i appear ignorant to the problems and issues with maintaining an |
30 |
> enterprise ready tree but in my mind running a stable tree would involve : |
31 |
> |
32 |
> 1. Identifiying a version of a package that is stable |
33 |
> 2. Marking that package as stable |
34 |
> 3. Pushing that package to the rsync servers |
35 |
> 4. ? |
36 |
> 5. ? |
37 |
> 6. ? |
38 |
|
39 |
The idea I had (at least initially), was using the snapshot releng |
40 |
builds for their release as our base tree to use for a release. After |
41 |
they finalize the tree, I'd see a group of folks going through and doing |
42 |
another round of QA and fixing any more bugs that may crop up. After its |
43 |
been established as a 'good' tree, I'd see us releasing that as |
44 |
something like 2005.1E or something like that. That part of a 'stable' |
45 |
tree is relatively easy to do aside from any issues cropping up from the |
46 |
QA section. |
47 |
|
48 |
The real fun begins during the maintenance phase where GLSAs, and |
49 |
critical software (data crippling type of things) updates need to be |
50 |
updated in it. This is where we'd need to decide whether to go the back |
51 |
port route, or just force folks to upgrade if the GLSA affects it. |
52 |
Essentially, our group would be managing their own tree. It sounds |
53 |
fairly simple, but to ensure a level of quality, we'd need to test the |
54 |
new ebuild/upgrade in some type of QA environment (which we currently |
55 |
don't have enough good man power for). |
56 |
|
57 |
Next, say when the next release comes out (2006.0E), we'd have to come |
58 |
up with a clean upgrade path to ensure no breakages. This is the part |
59 |
that will require a lot of time and effort. Ideally, it'd be nice if we |
60 |
came up with a helper script to 'fix' things as the upgrade happens. |
61 |
|
62 |
Last, we'd need to decide how long to keep a particular tree updated. If |
63 |
we went on two releases per year, after 2 years we'd have 4 trees to |
64 |
keep up to date and come up with upgrade plans for each of those. |
65 |
|
66 |
Needless to say, doing it the 'right' way isn't very easy to do. Thats |
67 |
one of the things our server team would need to establish is what kind |
68 |
of level do we want to maintain. Thats kind of where the idea of a third |
69 |
party would come into play and possibly help fund a few folks to do this |
70 |
kind of work as a job :). |
71 |
|
72 |
Thoughts on that rough plan? |
73 |
|
74 |
-- |
75 |
Lance Albertson <ramereth@g.o> |
76 |
Gentoo Infrastructure | Operations Manager |
77 |
|
78 |
--- |
79 |
GPG Public Key: <http://www.ramereth.net/lance.asc> |
80 |
Key fingerprint: 0423 92F3 544A 1282 5AB1 4D07 416F A15D 27F4 B742 |
81 |
|
82 |
ramereth/irc.freenode.net |