| 1 |
On Wed, 2004-07-21 at 17:12, Olivier Crete wrote: |
| 2 |
> I like the idea of a separate tree.. But if it really rarely changes, |
| 3 |
> rsync is just overkill and will overburden our mirrors.. Lets just make |
| 4 |
> it a tarball and put the enhancements in a rsync'ed overlay. Rsync is |
| 5 |
> for stuff that changes... |
| 6 |
|
| 7 |
That works for me. I was simply trying to propose a way to do it with |
| 8 |
the least amount of changes for the users. Perhaps have the main |
| 9 |
tarball delivered by rsync so a version switch is still transparent? |
| 10 |
|
| 11 |
> This overlays should probably each have their own cvs module (or all be |
| 12 |
> directories under the same module, I dont really care... Where all |
| 13 |
> package maintainers would have access.. And then we can mark them stable |
| 14 |
> using the same kind of procedures we currently use for GLSAs... |
| 15 |
> |
| 16 |
> Also, the problem with maintaining older versions is that we need to |
| 17 |
> have at least one machine available for each version where the concerned |
| 18 |
> devs can test security updates.. Ok, maybe at least one per |
| 19 |
> architectures using chroots... but its still a lot of infrastructure.. |
| 20 |
> That's why reducing the number of stable releases to maybe even just one |
| 21 |
> a year might be a good idea. |
| 22 |
|
| 23 |
I'm not opposed to that. I think I would prefer 2, simply to reduce the |
| 24 |
amount changed between releases, making it easier for users to upgrade. |
| 25 |
Switching to 2 releases per year with a 4 release retention puts us at 2 |
| 26 |
years of support in the -release trees. Switching to 1 year release |
| 27 |
cycles puts us out to 4 years. An awful lot can change in 4 years in |
| 28 |
the Linux world. I'm not sure we would possibly be able to keep up with |
| 29 |
such a long-reaching goal. |
| 30 |
|
| 31 |
Personally, I would say we try to move on this by 2005.0 and see what |
| 32 |
happens, without changing release schedules and only supporting 4 |
| 33 |
releases. This would carry us through 2005.X and into 2006.X, where we |
| 34 |
could make adjustments to the release cycle if we deem it necessary. |
| 35 |
|
| 36 |
-- |
| 37 |
Chris Gianelloni |
| 38 |
Release Engineering QA Manager/Games Developer |
| 39 |
Gentoo Linux |
| 40 |
|
| 41 |
Is your power animal a penguin? |
Archives