All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Jean Delvare <khali@linux-fr.org>
Cc: Greg KH <greg@kroah.com>, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.6.16.30-pre1
Date: Sun, 24 Sep 2006 00:33:48 +0200	[thread overview]
Message-ID: <20060923223348.GH5566@stusta.de> (raw)
In-Reply-To: <20060923224909.69579243.khali@linux-fr.org>

On Sat, Sep 23, 2006 at 10:49:09PM +0200, Jean Delvare wrote:

> Hi Adrian, Greg,

Hi Jean,

> I second Greg's objection, and share his worries. "No possible
> regression" is something extremely hard to evaluate in general.
> Besides, the goal of -stable as I remember it is not "no regression"
> but rather "only bugfixes", i.e. patches don't go in without a good
> reason (default policy = reject), rather than patches are rejected if
> they may cause problem (default policy = accept.)
> 
> Adding support for new devices, even if it's only adding an ID in a
> list, is not always safe. I am not happy about new IDs being considered
> as OK for late RCs, I am even less so for -stable.

the main goals for 2.6.16 are:
- no regressions
- security fixes

And I did always say that things like adding new PCI IDs are considered 
OK for 2.6.16.

> The sole fact that Adrian felt the need to release a -pre1 for
> 2.6.16.30 betrays his lack of confidence IMHO.

No, all it says is:
- there was no reason for releasing 2.6.16.30 very soon
- my TODO list still contains reviewing 65 of the patches the -stable
  team added to 2.6.17

> And the size of ChangeLog-2.6.16.29 speaks for itself.

Except for 2 bug fixes, all of them were patches the -stable team added 
to 2.6.17.

> Given that 2.6.16.y follows the naming convention of -stable and is
> released in the official v2.6 directory on ftp.kernel.org, I'd like to
> see it follow the same rules we have for "real" -stable trees. Adrian,
> if you are going to diverge from the original intent of -stable, this
> is your own right, but then please change the name of your tree to
> 2.6.16-ab or something similar, to clear the confusion.
> 
> I will not use 2.6.16.y with its current rules, for sure, and I doubt
> any distribution will. Wasn't the whole point of 2.6.16.y to serve as a
> common base between several distributions?

No, see [1]:

<--  snip  -->

Q:
What is the target audience for this 2.6.16 series?

A:
The target audience are users still using 2.4 (or who'd still use kernel 
2.4 if they weren't forced to upgrade to 2.6 for some reason) who want a 
stable kernel series including security fixes but excluding many 
regressions.
It might also be interesting for distributions that prefer stability 
over always using the latest stuff.

<--  snip  -->


The 2.6.16 series is an offer.

If you don't want to use it it's OK.

Distributions can use it, cherry pick from it, or ignore it.

Whether a distribution uses 2.6.16 or a more recent kernel (that will 
anyway support more hardware than 2.6.16 ever will), and if a 
distribution that uses 2.6.16 will ever follow the 2.6.16 series depends 
on the goals of the distribution.


> Thanks,
> Jean Delvare

cu
Adrian

[1] http://article.gmane.org/gmane.linux.kernel/354360

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  parent reply	other threads:[~2006-09-23 22:33 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-22 22:23 Linux 2.6.16.30-pre1 Adrian Bunk
2006-09-22 22:38 ` Greg KH
2006-09-22 22:47   ` Adrian Bunk
2006-09-22 23:09     ` Greg KH
2006-09-23  4:56       ` Willy Tarreau
2006-09-23 23:21         ` Adrian Bunk
2006-09-23 23:53           ` Willy Tarreau
2006-09-24  7:46             ` Sergey Vlasov
2006-09-24 18:16             ` Adrian Bunk
2006-09-24 19:46               ` Stefan Richter
2006-09-24 19:44                 ` Willy Tarreau
2006-09-24 20:02               ` Willy Tarreau
2006-09-25  1:01                 ` Adrian Bunk
2006-09-24 10:17           ` Pavel Machek
2006-09-25  1:23             ` Adrian Bunk
2006-09-25  8:15               ` Pavel Machek
2006-09-27  5:14               ` Greg KH
2006-09-23 20:49       ` Jean Delvare
2006-09-23 20:57         ` Lee Revell
2006-09-23 21:20           ` Jean Delvare
2006-09-23 22:47             ` Adrian Bunk
2006-09-23 22:33         ` Adrian Bunk [this message]
2006-09-23 22:47           ` Lee Revell
2006-09-23 22:58             ` Adrian Bunk
2006-09-23 22:12       ` Adrian Bunk
2006-09-24 10:12     ` Pavel Machek
2006-09-25  1:20       ` Adrian Bunk
2006-09-24 20:25 ` Grant Coady

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=20060923223348.GH5566@stusta.de \
    --to=bunk@stusta.de \
    --cc=greg@kroah.com \
    --cc=khali@linux-fr.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.