mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Allan Sandfeld <linux@sneulv.dk>
To: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.18-rc1
Date: Wed, 13 Feb 2002 23:53:41 +0100	[thread overview]
Message-ID: <E16b8HV-0001JS-00@Princess> (raw)
In-Reply-To: <Pine.LNX.4.21.0202131732330.20915-100000@freak.distro.conectiva>
In-Reply-To: <Pine.LNX.4.21.0202131732330.20915-100000@freak.distro.conectiva>

On Wednesday 13 February 2002 20:33, Marcelo Tosatti wrote:
> So here it goes.
>
> rc1:
<snip>
> - Merge some -ac bugfixes			(Alan Cox)

Here's a crazy idea. Why not branch off the new pre-tree when commiting a 
rc-kernel? 
There's a number of patches in the ac-tree you proberbly already have 
commited to the next pre-kernel in your mind. The basic idea is that when you 
release a patch as release candidate, you shortly after release the first 
pre-patch for next kernel. For the release candidate there is test delay, 
such that at least 1 maybe 2 weeks has to pass without an unsolved release 
critical bug, before a release candidat can be promoted to be a stable 
version. This would for periods of time result in two patches for the stable 
tree. (yes, I am Debian user, how did you guess?)

The advantages are two fold, not only could it ease the presure to allow a 
rc-patch to stay rc for longer, it would even out the load on you as 
mainterner, as you could always accept new patches into the next pre-patch as 
there will always be one.  I.e you would only have to make decisions of 
whether this patch is critical or not for the stable release or merely 
something for the next release.
The disadvantage, might be that fewer hackers would test the rc, although 
this could even out with the longer rc-period, and that you might see an 
increase in your work-load if you both have the test the rc and maintain the 
next release tree.

Anyway, just a random thought.
Greetings
-Allan

  reply	other threads:[~2002-02-13 22:58 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-13 19:33 Marcelo Tosatti
2002-02-13 22:53 ` Allan Sandfeld [this message]
2002-02-13 23:05   ` Rik van Riel
2002-02-14  0:01   ` Bill Davidsen
2002-02-14 16:14   ` Tom Rini
2002-02-14 13:14 ` Adrian Bunk
2002-02-14 13:40   ` Alan Cox
2002-02-14 13:42     ` Matthias Andree
2002-02-14 13:49     ` Adrian Bunk
2002-02-14 14:51   ` M. Edward (Ed) Borasky
2002-02-15 13:41 willy tarreau

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=E16b8HV-0001JS-00@Princess \
    --to=linux@sneulv.dk \
    --cc=linux-kernel@vger.kernel.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

all inboxes | Powered by JetHome®