From: Chris Gianelloni <wolf31o2@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Revisiting GLEP 19
Date: Wed, 21 Jul 2004 17:39:57 -0400 [thread overview]
Message-ID: <1090445997.19552.156.camel@localhost> (raw)
In-Reply-To: <1090444335.372.18.camel@montreal>
[-- Attachment #1: Type: text/plain, Size: 2072 bytes --]
On Wed, 2004-07-21 at 17:12, Olivier Crete wrote:
> I like the idea of a separate tree.. But if it really rarely changes,
> rsync is just overkill and will overburden our mirrors.. Lets just make
> it a tarball and put the enhancements in a rsync'ed overlay. Rsync is
> for stuff that changes...
That works for me. I was simply trying to propose a way to do it with
the least amount of changes for the users. Perhaps have the main
tarball delivered by rsync so a version switch is still transparent?
> This overlays should probably each have their own cvs module (or all be
> directories under the same module, I dont really care... Where all
> package maintainers would have access.. And then we can mark them stable
> using the same kind of procedures we currently use for GLSAs...
>
> Also, the problem with maintaining older versions is that we need to
> have at least one machine available for each version where the concerned
> devs can test security updates.. Ok, maybe at least one per
> architectures using chroots... but its still a lot of infrastructure..
> That's why reducing the number of stable releases to maybe even just one
> a year might be a good idea.
I'm not opposed to that. I think I would prefer 2, simply to reduce the
amount changed between releases, making it easier for users to upgrade.
Switching to 2 releases per year with a 4 release retention puts us at 2
years of support in the -release trees. Switching to 1 year release
cycles puts us out to 4 years. An awful lot can change in 4 years in
the Linux world. I'm not sure we would possibly be able to keep up with
such a long-reaching goal.
Personally, I would say we try to move on this by 2005.0 and see what
happens, without changing release schedules and only supporting 4
releases. This would carry us through 2005.X and into 2006.X, where we
could make adjustments to the release cycle if we deem it necessary.
--
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux
Is your power animal a penguin?
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
next prev parent reply other threads:[~2004-07-21 21:39 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-07-20 13:14 [gentoo-dev] Revisiting GLEP 19 Kurt Lieber
2004-07-20 19:36 ` RNuno
2004-07-20 20:43 ` Dylan Carlson
2004-07-20 21:03 ` Tom Payne
2004-07-20 21:18 ` Kurt Lieber
2004-07-20 21:36 ` Dylan Carlson
2004-07-20 21:14 ` Olivier Crete
2004-07-20 21:41 ` Dylan Carlson
2004-07-20 22:06 ` Stuart Herbert
2004-07-20 22:50 ` Kurt Lieber
2004-07-21 14:53 ` Toby Dickenson
2004-07-20 22:58 ` Dylan Carlson
2004-07-21 20:00 ` Chris Gianelloni
2004-07-21 21:12 ` Olivier Crete
2004-07-21 21:39 ` Chris Gianelloni [this message]
2004-07-21 21:57 ` Michael Marineau
2004-07-22 12:24 ` Chris Gianelloni
2004-07-21 0:27 ` Michael Marineau
2004-07-21 0:54 ` Dylan Carlson
2004-07-21 1:07 ` Michael Marineau
2004-07-21 1:43 ` Dylan Carlson
2004-07-22 18:28 ` Martin Schlemmer
2004-07-21 16:13 ` Marius Mauch
2004-07-21 17:25 ` Dylan Carlson
2004-07-21 20:12 ` Chris Gianelloni
2004-07-21 1:55 ` Barry Shaw
2004-07-21 3:10 ` Michael Marineau
2004-07-21 6:50 ` Daniel Ostrow
2004-07-21 20:25 ` Chris Gianelloni
2004-07-21 20:21 ` Chris Gianelloni
2004-07-22 9:00 ` [gentoo-dev] " Duncan
2004-07-22 12:57 ` Chris Gianelloni
2004-07-21 12:39 ` [gentoo-dev] " Stuart Herbert
2004-07-21 12:56 ` Daniel Ostrow
2004-07-21 12:58 ` Toby Dickenson
2004-07-21 13:15 ` Stuart Herbert
2004-07-21 13:43 ` Jason Wever
2004-07-21 14:47 ` Carsten Lohrke
2004-07-21 15:08 ` Stuart Herbert
2004-07-21 15:45 ` Georgi Georgiev
2004-07-21 15:57 ` Ciaran McCreesh
2004-07-21 17:15 ` Carsten Lohrke
2004-07-23 4:22 ` Andrew Cowie
2004-07-21 20:51 ` Chris Gianelloni
2004-07-22 10:34 ` Carsten Lohrke
2004-07-22 13:06 ` Chris Gianelloni
2004-07-23 14:18 ` Carsten Lohrke
2004-07-23 14:45 ` Chris Gianelloni
2004-07-21 15:25 ` aeriksson
2004-07-21 15:36 ` Stuart Herbert
2004-07-21 16:34 ` aeriksson
2004-07-21 19:32 ` Stuart Herbert
2004-07-21 22:55 ` Marius Mauch
2004-07-22 0:08 ` Donnie Berkholz
2004-07-22 0:24 ` Marius Mauch
2004-07-22 0:29 ` Donnie Berkholz
2004-07-22 12:31 ` Chris Gianelloni
2004-07-22 12:27 ` Chris Gianelloni
2004-07-21 15:38 ` Lina Pezzella
2004-07-21 16:26 ` Dylan Carlson
2004-07-21 17:59 ` FRLinux
2004-07-21 16:39 ` Christian Birchinger
2004-07-21 20:42 ` Chris Gianelloni
2004-07-22 8:58 ` Stuart Herbert
2004-07-21 14:33 ` Lars Weiler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1090445997.19552.156.camel@localhost \
--to=wolf31o2@gentoo.org \
--cc=gentoo-dev@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox