| 1 |
On Fri, 2005-09-23 at 11:32 +1000, Phillip Berry wrote: |
| 2 |
> Hello, |
| 3 |
> |
| 4 |
> Could some point me to, or provide a more specific breakdown of some of the |
| 5 |
> roles and tasks that would need to be tended to? |
| 6 |
> |
| 7 |
> Forgive me if i appear ignorant to the problems and issues with maintaining an |
| 8 |
> enterprise ready tree but in my mind running a stable tree would involve : |
| 9 |
> |
| 10 |
> 1. Identifiying a version of a package that is stable |
| 11 |
keep upgrades to a reasonable minimum ... "never touch a running system" |
| 12 |
> 2. Marking that package as stable |
| 13 |
that includes lots of testing. Then some more testing. ... |
| 14 |
Also each major release (2005.0/2005.1/2006.0/...) would most likely be |
| 15 |
its own branch and need testing ... |
| 16 |
Did I mention QA and testing? ;-) |
| 17 |
> 3. Pushing that package to the rsync servers |
| 18 |
Why rsync? updates for an "enterprise" tree should be infrequent enough |
| 19 |
for tarballs to be easier |
| 20 |
(less overhead, easier to see what needs to be fetced, ...) |
| 21 |
> 4. ? |
| 22 |
Backport security fixes to older versions? |
| 23 |
> 5. ? |
| 24 |
> 6. ? |
| 25 |
> |
| 26 |
> What are the items that are missing from my list? |
| 27 |
That would only provide a stable ebuild base. |
| 28 |
Extra items such as reliable support etc. aren't even mentioned here but |
| 29 |
would most likely be needed / very useful. |
| 30 |
|
| 31 |
Patrick |
| 32 |
-- |
| 33 |
Stand still, and let the rest of the universe move |
Archives