public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Kurt Lieber <klieber@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] GLEP 19, reloaded (again)
Date: Tue, 10 Aug 2004 13:24:09 +0000	[thread overview]
Message-ID: <20040810132409.GG29077@mail.lieber.org> (raw)
In-Reply-To: <1092144188.21441.19.camel@localhost>

[-- Attachment #1: Type: text/plain, Size: 1875 bytes --]

On Tue, Aug 10, 2004 at 09:23:08AM -0400 or thereabouts, Chris Gianelloni wrote:
> > [side note] the releases of the tree are not tied to the releases of our
> > liveCD/package sets.[/side note]
> 
> This I don't understand at all.  Why maintain 2 separate release cycles?

The release schedule for liveCDs/package sets is 4/year.  We're talking
about an annual cycle here.

> > One think that I think *everyone* agrees on is that any stable tree needs
> > to be regularly updated with security fixes.  With this in mind, I'm
> > concerned with trying to maintain multiple separate SYNC modules.  We'd
> > have to upgrade each one with every GLSA, thus doubling or tripling the
> > amount of CVS work needed each time.
> 
> So the idea is to create exactly *one* stable tree?  How is this any
> different than just doing better with our current tree?  Honestly, from
> what I've heard from our users, they want package stability (as in
> freeze) much more than anything else.  This is *exactly* why I recommend
> tying the "stable" trees with the releases.  I'm not sure I can
> understand how doing anything else really gives us anything other than
> adding more workload for the simple fact of adding workload.  Having a
> "stable" tree that still moves, and only providing a single "stable"
> tree doesn't seem to be an improvement from what we have at all.

No -- we would have one tree for each release, but the difference is that
you're talking about using the tree to control versions and I'm talking
about using profiles to control versions.  With the current proposal, the
*only* difference between the main rsync module and the "stable" module is
that the latter has the --delete option removed.  This is to ensure ebuilds
remain in the tree for a predictable period of time.  It has nothing to do
with package versioning.

--kurt

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2004-08-10 13:21 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-08 18:51 [gentoo-dev] GLEP 19, reloaded (again) Kurt Lieber
2004-08-09  5:04 ` Dylan Carlson
2004-08-09  9:52   ` Kurt Lieber
2004-08-09 14:21     ` Chris Gianelloni
2004-08-10  0:01       ` Kurt Lieber
2004-08-10  0:13         ` Corey Shields
2004-08-10  1:04           ` Olivier Crete
2004-08-10 13:26             ` Kurt Lieber
2004-08-10 13:27             ` Chris Gianelloni
2004-08-10 13:32               ` Kurt Lieber
2004-08-10 13:23         ` Chris Gianelloni
2004-08-10 13:24           ` Kurt Lieber [this message]
2004-08-10 13:55             ` Chris Gianelloni
2004-08-10 20:25               ` Jeremy Maitin-Shepard
2004-08-10 23:24               ` Kurt Lieber
2004-08-11 14:23                 ` Chris Gianelloni
2004-08-11 16:05                   ` Dylan Carlson
2004-08-11 17:51                     ` Paul de Vrieze
2004-08-11 15:44                 ` John Davis
2004-08-10 13:26           ` Corey Shields
2004-08-10 13:48             ` Chris Gianelloni
2004-08-10 14:20               ` Paul de Vrieze
2004-08-10 15:01                 ` Chris Gianelloni
2004-08-10 14:27               ` Corey Shields
2004-08-10 15:03                 ` Chris Gianelloni
2004-08-10 18:05         ` Spider
2004-08-10 19:03           ` Chris Gianelloni
2004-08-10 19:23             ` Olivier Crete
2004-08-10 20:43               ` Chris Gianelloni
2004-08-11  4:22                 ` Marius Mauch
2004-08-11  9:31                   ` Paul de Vrieze
2004-08-11 14:32                   ` Chris Gianelloni
2004-08-10 23:10               ` Kurt Lieber
2004-08-10 20:34           ` Jeremy Maitin-Shepard
2004-08-11  7:07             ` Spider
2004-08-11  7:50               ` Jeremy Maitin-Shepard
2004-08-11  8:54                 ` Spider
2004-08-09 22:11     ` Dylan Carlson
2004-08-09 22:34       ` Corey Shields
2004-08-09 15:23   ` Corey Shields
2004-08-10 20:43     ` Jeremy Maitin-Shepard
2004-08-09  6:34 ` Greg KH
2004-08-09  7:46   ` Paul de Vrieze
2004-08-09  7:56     ` Greg KH
2004-08-09  7:59       ` Paul de Vrieze
2004-08-09 10:02   ` Kurt Lieber
2004-08-09  7:43 ` Barry Shaw
2004-08-09  7:51   ` Paul de Vrieze
2004-08-09 20:56 ` Olivier Crete
2004-08-09 21:12   ` Corey Shields
2004-08-09 21:33     ` Olivier Crete
2004-08-09 21:45       ` Corey Shields
2004-08-09 22:02         ` Olivier Crete
2004-08-09 22:15           ` Dylan Carlson
2004-08-10  0:05             ` Kurt Lieber
2004-08-10 11:33               ` Paul de Vrieze
2004-08-10 18:33                 ` Dylan Carlson
2004-08-10 20:19                   ` Chris Bainbridge
2004-08-10 21:24                     ` Chris Gianelloni
2004-08-11  2:59                       ` Chris Bainbridge
2004-08-10 23:07                     ` Kurt Lieber
2004-08-11  2:40                       ` Chris Bainbridge
2004-08-11  3:21                     ` Marius Mauch
2004-08-11 12:21                       ` Chris Bainbridge

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=20040810132409.GG29077@mail.lieber.org \
    --to=klieber@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