In August 2006 Adrian Bunk took over maintainership of the 2.6.16.y stable kernel [story]. With the release of the 2.6.16.30-pre1 patch, concerns were expressed as to what makes a stable tree. The inclusion of new features led -stable maintainer Greg K-H to observe, "all of these patches seem like these are new features being backported to the 2.6.16.y kernel, which is not really allowed under the current -stable rules." Adrian responded, "they add support for additional hardware to the saa7134 driver. If you look at the actual diff there's not much that could cause any regression since nearly all of these changes don't change anything for the already supported cards." Greg cautioned, "if you want to accept new drivers and backports like this, I think you will find it very hard to determine what to say yes or no to in the future. It's the main problem that everyone who has tried to maintain a stable tree has run into, that is why we set up the -stable rules to be what they are for that very reason."

Willy Tarreau, maintainer of the 2.4 stable kernel [story] joined in with several others expressing concerns about keeping the 2.6.16 tree stable, "when I started the 2.4-hotfix tree nearly two years ago, I wanted to avoid merging driver changes as much as possible. And particularly, I avoided to add support for new hardware. The reason is very simple. I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y does too so that they can blindly upgrade." Adrian disagreed, "bugfixes causing regressions are much more likely than new hardware support adding regressions." He went on to note that he has two rules for accepting patches, first the patch must be in Linus' tree, and second he directly asks the patch authors and subsystem maintainers for feedback. "I do know that the only value of the 2.6.16 tree lies in a lack of regressions and act accordingly," Adrian added, "but I'm trying to do this in a pragmatic way."

From: Adrian Bunk [email blocked]
To:  linux-kernel
Subject: Linux 2.6.16.30-pre1
Date:	Sat, 23 Sep 2006 00:23:00 +0200

Patch location:
ftp://ftp.kernel.org/pub/linux/kernel/people/bunk/linux-2.6.16.y/testing/

git tree:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git

RSS feed of the git tree:
http://www.kernel.org/git/?p=linux/kernel/git/stable/linux-2.6.16.y.git;a=rss


Changes since 2.6.16.29:

Adrian Bunk:
      V4L/DVB: Saa7134: document that there's also a 220RF from KWorld
      add drivers/media/video/saa7134/saa7134-input.c:flydvb_codes
      Linux 2.6.16.30-pre1

Andrew Burri:
      V4L/DVB: Add support for Kworld ATSC110

Curt Meyers:
      V4L/DVB: KWorld ATSC110: implement set_pll_input
      V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
      V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load

Giampiero Giancipoli:
      V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card

Hartmut Hackmann:
      V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
      V4L/DVB: Added PCI IDs of 2 LifeView Cards
      V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
      V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
      V4L/DVB: TDA10046 Driver update
      V4L/DVB: TDA8290 update

Peter Hartshorn:
      V4L/DVB: Added support for the Tevion DVB-T 220RF card

Henk Vergonet:
      USB: Fix unload oops and memory leak in yealink driver
      USB: add YEALINK phones to the HID_QUIRK_IGNORE blacklist

Jay Cliburn:
      via-velocity: fix speed and link status reported by ethtool

Jose Alberto Reguero:
      V4L/DVB: Add support for the Avermedia 777 DVB-T card

Julien Tous:
      [AGPGART] ATI RS350 support.

Magnus Kessler:
      [AGPGART] VIA PT880 Ultra support.

Mark M. Hoffman:
      I2C: fix 'ignore' module parameter handling

Martin Schwidefsky:
      kernel/kmod.c: fix a race condition in usermodehelper.

maximilian attems:
      V4L/DVB: Saa7134: select FW_LOADER

Michael Krufky:
      V4L/DVB: Kworld ATSC110: cleanups
      V4L/DVB: Saa7134: make unsupported secondary decoder message generic
      V4L/DVB: Medion 7134: Autodetect second bridge chip

Michael Rash:
      [TEXTSEARCH]: Fix Boyer Moore initialization bug

Rickard Osser:
      V4L/DVB: Saa7134: add support for AVerMedia A169 Dual Analog tuner card

Roland Dreier:
      Convert idr's internal locking to _irqsave variant

Roy Marples:
      via-velocity: the link is not correctly detected when the device starts

Tamuki Shoichi:
      V4L/DVB: Add saa713x card: ELSA EX-VISION 700TV (saa7130)
      V4L/DVB: ELSA EX-VISION 700TV: fix incorrect PCI subsystem ID

Tushar Gohad:
      PFKEYV2: Fix inconsistent typing in struct sadb_x_kmprivate.



From: Greg KH [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Fri, 22 Sep 2006 15:38:59 -0700

On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> Andrew Burri:
>       V4L/DVB: Add support for Kworld ATSC110
> 
> Curt Meyers:
>       V4L/DVB: KWorld ATSC110: implement set_pll_input
>       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
>       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> 
> Giampiero Giancipoli:
>       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> 
> Hartmut Hackmann:
>       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
>       V4L/DVB: Added PCI IDs of 2 LifeView Cards
>       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
>       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
>       V4L/DVB: TDA10046 Driver update
>       V4L/DVB: TDA8290 update
> 
> Peter Hartshorn:
>       V4L/DVB: Added support for the Tevion DVB-T 220RF card

Hm, all of these patches seems like these are new features being
backported to the 2.6.16.y kernel, which is not really allowed under the
current -stable rules.

Or are these patches just bugfixes that fix with the current -stable
rules?

thanks,

greg k-h



From: Adrian Bunk [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sat, 23 Sep 2006 00:47:35 +0200

On Fri, Sep 22, 2006 at 03:38:59PM -0700, Greg KH wrote:
> On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> > Andrew Burri:
> >       V4L/DVB: Add support for Kworld ATSC110
> > 
> > Curt Meyers:
> >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > 
> > Giampiero Giancipoli:
> >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > 
> > Hartmut Hackmann:
> >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> >       V4L/DVB: TDA10046 Driver update
> >       V4L/DVB: TDA8290 update
> > 
> > Peter Hartshorn:
> >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> 
> Hm, all of these patches seems like these are new features being
> backported to the 2.6.16.y kernel, which is not really allowed under the
> current -stable rules.
> 
> Or are these patches just bugfixes that fix with the current -stable
> rules?

They add support for additional hardware to the saa7134 driver.

If you look at the actual diff there's not much that could cause any 
regression since nearly all of these change don't change anything for 
the already supported cards.

As long as there's not a serious risk of regressions, such additions are 
welcome in 2.6.16.

"is not really allowed under the current -stable rules" is a bit hard to 
answer, but considering that "Missing PCI id update for VIA IDE" was OK 
for 2.6.17.12 I'd say it's consistent with what you are doing.

> thanks,
> 
> greg k-h

cu
Adrian

-- 

       "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



From: Greg KH [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Fri, 22 Sep 2006 16:09:28 -0700

On Sat, Sep 23, 2006 at 12:47:35AM +0200, Adrian Bunk wrote:
> On Fri, Sep 22, 2006 at 03:38:59PM -0700, Greg KH wrote:
> > On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> > > Andrew Burri:
> > >       V4L/DVB: Add support for Kworld ATSC110
> > > 
> > > Curt Meyers:
> > >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> > >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> > >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > > 
> > > Giampiero Giancipoli:
> > >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > > 
> > > Hartmut Hackmann:
> > >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> > >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> > >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> > >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> > >       V4L/DVB: TDA10046 Driver update
> > >       V4L/DVB: TDA8290 update
> > > 
> > > Peter Hartshorn:
> > >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> > 
> > Hm, all of these patches seems like these are new features being
> > backported to the 2.6.16.y kernel, which is not really allowed under the
> > current -stable rules.
> > 
> > Or are these patches just bugfixes that fix with the current -stable
> > rules?
> 
> They add support for additional hardware to the saa7134 driver.

That's not a bugfix.

> If you look at the actual diff there's not much that could cause any 
> regression since nearly all of these change don't change anything for 
> the already supported cards.

I'm not disagreeing about the regression issue.  I'm just concerned
because you are starting down the slope of "backporting new driver
support" to the 2.6.16 tree, and that's something that I thought you did
not want to do.

But if it is, let us know, and we can discuss it.

> As long as there's not a serious risk of regressions, such additions are 
> welcome in 2.6.16.

Are you sure?  That really goes against the -stable rules as we
originally set them out to be.

If you want to accept new drivers and backports like this, I think you
will find it very hard to determine what to say yes or no to in the
future.  It's the main problem that everyone who has tried to maintain a
stable tree has run into, that is why we set up the -stable rules to be
what they are for that very reason.

> "is not really allowed under the current -stable rules" is a bit hard to 
> answer, but considering that "Missing PCI id update for VIA IDE" was OK 
> for 2.6.17.12 I'd say it's consistent with what you are doing.

That was a bugfix as the driver could not access that device without
that fix.  Just adding a device id is not something that we normally
will take, as that is what the sysfs "newid" is for.  That patch was
obviously something else.

thanks,

greg k-h



From: Willy Tarreau [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sat, 23 Sep 2006 06:56:10 +0200

Hi Greg, Hi Adrian,

On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:

> If you want to accept new drivers and backports like this, I think you
> will find it very hard to determine what to say yes or no to in the
> future.  It's the main problem that everyone who has tried to maintain a
> stable tree has run into, that is why we set up the -stable rules to be
> what they are for that very reason.

When I started the 2.4-hotfix tree nearly two years ago, I wanted to
avoid merging drivers changes as much as possible. And particularly,
I avoided to add support for new hardware. The reason is very simple.
I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
does too so that they can blindly upgrade. And if, for any reason,
people suspect that 2.4.X.Y might have brought a bug, then reverting
to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
previous support for any hardware. The problem with new hardware
support is that it can break sensible setups :

  - adding a new network card support will cause existing cards to be
    renumberred (it happened to me on several production systems when
    switching from 2.2 to 2.4)

  - adding support for a new IDE controller can cause hda to become
    hdc, or worse, hda to become sda (problems encountered when adding
    libata support)

  - enabling some devices might lock up memory and/or I/O address ranges
    on a bus leading to other devices not working anymore. I had this
    problem when using dlink 580 quad port nics in some buggy machines
    already equipped with adaptec starfire nics.

  - other core devices might cause system instability without the
    admin being aware they're really used (eg: ACPI, ...)

Since hardware diversity is so high that nobody can know everything, I
think it's better to avoid playing alone with people's hardware, but I
agree it's sometimes very hard to resist.

Adrian, when you have a doubt whether such a fix should go into next
release, simply tell people about the problem and ask them to test
current driver. If nobody encounters the problem, you can safely keep
the patch in your fridge until someone complains. By that time, the
risks associated with this patch will be better known.

> > "is not really allowed under the current -stable rules" is a bit hard to 
> > answer, but considering that "Missing PCI id update for VIA IDE" was OK 
> > for 2.6.17.12 I'd say it's consistent with what you are doing.
> 
> That was a bugfix as the driver could not access that device without
> that fix.

Even this might be dangerous in late -stable releases, unless it was a
recent regression.

Just my 2 cents,
Willy



From: Adrian Bunk [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sun, 24 Sep 2006 01:21:50 +0200

On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> Hi Greg, Hi Adrian,
> 
> On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> 
> > If you want to accept new drivers and backports like this, I think you
> > will find it very hard to determine what to say yes or no to in the
> > future.  It's the main problem that everyone who has tried to maintain a
> > stable tree has run into, that is why we set up the -stable rules to be
> > what they are for that very reason.
> 
> When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> avoid merging drivers changes as much as possible. And particularly,
> I avoided to add support for new hardware. The reason is very simple.
> I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> does too so that they can blindly upgrade.

Bugfixes causing regressions are much more likely than new hardware 
support adding regressions.

> And if, for any reason,
> people suspect that 2.4.X.Y might have brought a bug, then reverting
> to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> previous support for any hardware.

Either you want to use the newly supported hardware or you don't want to 
use it.

In any case, I don't see your point.

> The problem with new hardware
> support is that it can break sensible setups :
> 
>   - adding a new network card support will cause existing cards to be
>     renumberred (it happened to me on several production systems when
>     switching from 2.2 to 2.4)
> 
>   - adding support for a new IDE controller can cause hda to become
>     hdc, or worse, hda to become sda (problems encountered when adding
>     libata support)

I don't consider merging any patches that could cause the sda problem.

People not using the onboard IDE controller but a different controller, 
but OTOH having the driver for their onboard controller enabled in their 
kernel really sounds like a strange case.

>   - enabling some devices might lock up memory and/or I/O address ranges
>     on a bus leading to other devices not working anymore. I had this
>     problem when using dlink 580 quad port nics in some buggy machines
>     already equipped with adaptec starfire nics.
> 
>   - other core devices might cause system instability without the
>     admin being aware they're really used (eg: ACPI, ...)
> 
> Since hardware diversity is so high that nobody can know everything, I
> think it's better to avoid playing alone with people's hardware, but I
> agree it's sometimes very hard to resist.
> 
> Adrian, when you have a doubt whether such a fix should go into next
> release, simply tell people about the problem and ask them to test
> current driver. If nobody encounters the problem, you can safely keep
> the patch in your fridge until someone complains. By that time, the
> risks associated with this patch will be better known.

It's not that I wanted to upgrade ACPI to the latest version.

And my rules are:
- patch must be in Linus' tree
- I'm asking the patch authors and maintainers of the affected subsystem
  whether the patch is OK for 2.6.16

> > > "is not really allowed under the current -stable rules" is a bit hard to 
> > > answer, but considering that "Missing PCI id update for VIA IDE" was OK 
> > > for 2.6.17.12 I'd say it's consistent with what you are doing.
> > 
> > That was a bugfix as the driver could not access that device without
> > that fix.
> 
> Even this might be dangerous in late -stable releases, unless it was a
> recent regression.

It was a case that never worked before.

> Just my 2 cents,
> Willy

cu
Adrian

-- 

       "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



From: Willy Tarreau [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sun, 24 Sep 2006 01:53:15 +0200

On Sun, Sep 24, 2006 at 01:21:50AM +0200, Adrian Bunk wrote:
> On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> > Hi Greg, Hi Adrian,
> > 
> > On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> > 
> > > If you want to accept new drivers and backports like this, I think you
> > > will find it very hard to determine what to say yes or no to in the
> > > future.  It's the main problem that everyone who has tried to maintain a
> > > stable tree has run into, that is why we set up the -stable rules to be
> > > what they are for that very reason.
> > 
> > When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> > avoid merging drivers changes as much as possible. And particularly,
> > I avoided to add support for new hardware. The reason is very simple.
> > I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> > does too so that they can blindly upgrade.
> 
> Bugfixes causing regressions are much more likely than new hardware 
> support adding regressions.
> 
> > And if, for any reason,
> > people suspect that 2.4.X.Y might have brought a bug, then reverting
> > to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> > previous support for any hardware.
> 
> Either you want to use the newly supported hardware or you don't want to 
> use it.
> 
> In any case, I don't see your point.

The problem is when some hardware suddenly become detected and assigned
in the middle of a stable release. Do not forget that people need stable
releases to be able to blindly update and get their security vulnerabilities
fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or
adding the PCI ID of some new ethernet cards that were not supported may
lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...).
This causes real trouble to admins, particularly those doing remote
updates. At least, I think that if you manage to inform people clearly
enough, and to separate security fixes and such fixes in distinct releases,
it might work in most situations. But this is a dangerous game anyway.

> > The problem with new hardware
> > support is that it can break sensible setups :
> > 
> >   - adding a new network card support will cause existing cards to be
> >     renumberred (it happened to me on several production systems when
> >     switching from 2.2 to 2.4)
> > 
> >   - adding support for a new IDE controller can cause hda to become
> >     hdc, or worse, hda to become sda (problems encountered when adding
> >     libata support)
> 
> I don't consider merging any patches that could cause the sda problem.
> 
> People not using the onboard IDE controller but a different controller, 
> but OTOH having the driver for their onboard controller enabled in their 
> kernel really sounds like a strange case.

No, this one is common, it's the reverse which is uncommon. Think about it.
You buy a mobo, you discover that the onboard SATA is not supported, you add
a new controller but do not disable the old one in case you have time to
perform more tests.

Anyway, the case above was even not that. It was simply that if the shiny
new sata_piix driver detected the sata controller, it would then steal the
resources first, preventing ata_piix from registering.

Cheers,
Willy



From: Adrian Bunk [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sun, 24 Sep 2006 20:16:41 +0200

On Sun, Sep 24, 2006 at 01:53:15AM +0200, Willy Tarreau wrote:
> On Sun, Sep 24, 2006 at 01:21:50AM +0200, Adrian Bunk wrote:
> > On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> > > Hi Greg, Hi Adrian,
> > > 
> > > On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> > > 
> > > > If you want to accept new drivers and backports like this, I think you
> > > > will find it very hard to determine what to say yes or no to in the
> > > > future.  It's the main problem that everyone who has tried to maintain a
> > > > stable tree has run into, that is why we set up the -stable rules to be
> > > > what they are for that very reason.
> > > 
> > > When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> > > avoid merging drivers changes as much as possible. And particularly,
> > > I avoided to add support for new hardware. The reason is very simple.
> > > I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> > > does too so that they can blindly upgrade.
> > 
> > Bugfixes causing regressions are much more likely than new hardware 
> > support adding regressions.
> > 
> > > And if, for any reason,
> > > people suspect that 2.4.X.Y might have brought a bug, then reverting
> > > to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> > > previous support for any hardware.
> > 
> > Either you want to use the newly supported hardware or you don't want to 
> > use it.
> > 
> > In any case, I don't see your point.
> 
> The problem is when some hardware suddenly become detected and assigned
> in the middle of a stable release. Do not forget that people need stable
> releases to be able to blindly update and get their security vulnerabilities
> fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or
> adding the PCI ID of some new ethernet cards that were not supported may
> lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...).
> This causes real trouble to admins, particularly those doing remote
> updates. At least, I think that if you manage to inform people clearly
> enough, and to separate security fixes and such fixes in distinct releases,
> it might work in most situations. But this is a dangerous game anyway.

It seems we do not always agree.  ;-)

I did consider gcc 4 support in kernel 2.4 more dangerous and you do 
consider this more dangerous than I do.

I can always be proved wrong by getting reports from people that I broke 
their setups. If you know someone whose setup I broke, please tell him 
to inform me about this fact.

That zero feedback is good feedback is my experience since the times 
when I offered packages to run kernel 2.4 on Debian 2.2, and later 
packages to run kernel 2.6 on Debian 3.0 - I got almost zero feedback 
except for the one time when an update removed /etc/services ...

> > > The problem with new hardware
> > > support is that it can break sensible setups :
> > > 
> > >   - adding a new network card support will cause existing cards to be
> > >     renumberred (it happened to me on several production systems when
> > >     switching from 2.2 to 2.4)
> > > 
> > >   - adding support for a new IDE controller can cause hda to become
> > >     hdc, or worse, hda to become sda (problems encountered when adding
> > >     libata support)
> > 
> > I don't consider merging any patches that could cause the sda problem.
> > 
> > People not using the onboard IDE controller but a different controller, 
> > but OTOH having the driver for their onboard controller enabled in their 
> > kernel really sounds like a strange case.
> 
> No, this one is common, it's the reverse which is uncommon. Think about it.
> You buy a mobo, you discover that the onboard SATA is not supported, you add
> a new controller but do not disable the old one in case you have time to
> perform more tests.
> 
> Anyway, the case above was even not that. It was simply that if the shiny
> new sata_piix driver detected the sata controller, it would then steal the
> resources first, preventing ata_piix from registering.

I know that ATA is an area that requires extra care (and I don't plan 
any big updates in this area).

But having:
- two saa7134 cards in your computer and
- one of them formerly not supported and
- depending on one of them being the first one
is a case you can theoretically construct, but then there's the point 
that this is highly unlikely, and OTOH the value of the added support is 
more realistic.

If I was as extremely regarding regressions as you describe regarding 
hardware updates, I would also have to reject any bugfixes that are not 
security fixes since they might cause regressions.

I do know that the only value of the 2.6.16 tree lies in a lack of 
regressions and act accordingly, but I'm trying to do this in a 
pragmatic way.

> Cheers,
> Willy

cu
Adrian

-- 

       "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



From: Willy Tarreau [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sun, 24 Sep 2006 22:02:04 +0200

On Sun, Sep 24, 2006 at 08:16:41PM +0200, Adrian Bunk wrote:
> On Sun, Sep 24, 2006 at 01:53:15AM +0200, Willy Tarreau wrote:
> > On Sun, Sep 24, 2006 at 01:21:50AM +0200, Adrian Bunk wrote:
> > > On Sat, Sep 23, 2006 at 06:56:10AM +0200, Willy Tarreau wrote:
> > > > Hi Greg, Hi Adrian,
> > > > 
> > > > On Fri, Sep 22, 2006 at 04:09:28PM -0700, Greg KH wrote:
> > > > 
> > > > > If you want to accept new drivers and backports like this, I think you
> > > > > will find it very hard to determine what to say yes or no to in the
> > > > > future.  It's the main problem that everyone who has tried to maintain a
> > > > > stable tree has run into, that is why we set up the -stable rules to be
> > > > > what they are for that very reason.
> > > > 
> > > > When I started the 2.4-hotfix tree nearly two years ago, I wanted to
> > > > avoid merging drivers changes as much as possible. And particularly,
> > > > I avoided to add support for new hardware. The reason is very simple.
> > > > I want to be able to guarantee that if 2.4.X works, then any 2.4.X.Y
> > > > does too so that they can blindly upgrade.
> > > 
> > > Bugfixes causing regressions are much more likely than new hardware 
> > > support adding regressions.
> > > 
> > > > And if, for any reason,
> > > > people suspect that 2.4.X.Y might have brought a bug, then reverting
> > > > to 2.4.X.Z(Z<Y) should at most bring back older bugs but not remove
> > > > previous support for any hardware.
> > > 
> > > Either you want to use the newly supported hardware or you don't want to 
> > > use it.
> > > 
> > > In any case, I don't see your point.
> > 
> > The problem is when some hardware suddenly become detected and assigned
> > in the middle of a stable release. Do not forget that people need stable
> > releases to be able to blindly update and get their security vulnerabilities
> > fixed. Sometimes, unlocking 2 SATA ports on the mobo by adding a PCI ID or
> > adding the PCI ID of some new ethernet cards that were not supported may
> > lead to such fun things (eth0 becoming eth2, sda becoming sdc, etc...).
> > This causes real trouble to admins, particularly those doing remote
> > updates. At least, I think that if you manage to inform people clearly
> > enough, and to separate security fixes and such fixes in distinct releases,
> > it might work in most situations. But this is a dangerous game anyway.
> 
> It seems we do not always agree.  ;-)

:-)

> I did consider gcc 4 support in kernel 2.4 more dangerous and you do 
> consider this more dangerous than I do.

I initially did too (gcc4), but reviewing the fixes one at a time
reassured me.

> I can always be proved wrong by getting reports from people that I broke 
> their setups. If you know someone whose setup I broke, please tell him 
> to inform me about this fact.

Don't worry, at this game, we *all* get proved wrong once in a while, and
this does not imply that a bad decision was taken, but rather that it is
a complicated job and we're all humans.

> That zero feedback is good feedback is my experience since the times 
> when I offered packages to run kernel 2.4 on Debian 2.2, and later 
> packages to run kernel 2.6 on Debian 3.0 - I got almost zero feedback 
> except for the one time when an update removed /etc/services ...

cf above ;-)

[...]
> > Anyway, the case above was even not that. It was simply that if the shiny
> > new sata_piix driver detected the sata controller, it would then steal the
> > resources first, preventing ata_piix from registering.
> 
> I know that ATA is an area that requires extra care (and I don't plan 
> any big updates in this area).
> 
> But having:
> - two saa7134 cards in your computer and
> - one of them formerly not supported and
> - depending on one of them being the first one
> is a case you can theoretically construct, but then there's the point 
> that this is highly unlikely, and OTOH the value of the added support is 
> more realistic.

I don't personaly have problems with those cards (I don't use them at all),
I was just arguing general principles in response to Greg's comments. I
think you're already taking extreme care in what you accept, but I think
that what you're currently doing is middle way between Greg's stable policy
and what yourself would really like to do. I hope that in the end, you will
not get frustrated by refraining from merging patches you would have liked
to get, while being criticized for having merged too many.

Probably that later you will have to either maintain several other versions
(let's say 2.6.16+2.6.18) or have sort of an "enhanced" branch with more
fixes (which is easy to do with GIT).

> If I was as extremely regarding regressions as you describe regarding 
> hardware updates, I would also have to reject any bugfixes that are not 
> security fixes since they might cause regressions.

Hmm, don't say this publicly, you'll get people saying that it is what
they expect !

> I do know that the only value of the 2.6.16 tree lies in a lack of 
> regressions and act accordingly, but I'm trying to do this in a 
> pragmatic way.

That's what I observed till now. I just wanted to warn you about the risks
of getting hit.

Cheers,
Willy



From: Adrian Bunk [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Mon, 25 Sep 2006 03:01:15 +0200

On Sun, Sep 24, 2006 at 10:02:04PM +0200, Willy Tarreau wrote:
> On Sun, Sep 24, 2006 at 08:16:41PM +0200, Adrian Bunk wrote:
>...
> > > Anyway, the case above was even not that. It was simply that if the shiny
> > > new sata_piix driver detected the sata controller, it would then steal the
> > > resources first, preventing ata_piix from registering.
> > 
> > I know that ATA is an area that requires extra care (and I don't plan 
> > any big updates in this area).
> > 
> > But having:
> > - two saa7134 cards in your computer and
> > - one of them formerly not supported and
> > - depending on one of them being the first one
> > is a case you can theoretically construct, but then there's the point 
> > that this is highly unlikely, and OTOH the value of the added support is 
> > more realistic.
> 
> I don't personaly have problems with those cards (I don't use them at all),
> I was just arguing general principles in response to Greg's comments. I
> think you're already taking extreme care in what you accept, but I think
> that what you're currently doing is middle way between Greg's stable policy
> and what yourself would really like to do. I hope that in the end, you will
> not get frustrated by refraining from merging patches you would have liked
> to get, while being criticized for having merged too many.
> 
> Probably that later you will have to either maintain several other versions
> (let's say 2.6.16+2.6.18) or have sort of an "enhanced" branch with more
> fixes (which is easy to do with GIT).

Instead of 2.6.16+2.6.18, it would be easier to simply use 2.6.18.

And this is what I have in mind as a possible solution:

Start a similar stable series based on e.g. 2.6.22 or 2.6.24, and 
announce an EOL date for 2.6.16 half a year or one year after this 
branch starts.

Well, that's all very far in the future (even 2.6.22 + half a year will 
most likely be in 2008), but it's better than backporting huge updates.

> > If I was as extremely regarding regressions as you describe regarding 
> > hardware updates, I would also have to reject any bugfixes that are not 
> > security fixes since they might cause regressions.
> 
> Hmm, don't say this publicly, you'll get people saying that it is what
> they expect !

I say what I want to do, and I did say the same before I started 
maintaining the 2.6.16 branch.

> > I do know that the only value of the 2.6.16 tree lies in a lack of 
> > regressions and act accordingly, but I'm trying to do this in a 
> > pragmatic way.
> 
> That's what I observed till now. I just wanted to warn you about the risks
> of getting hit.

Is someone wants to prove me wrong, he should send me the reports of 
regressions my changes have caused...

> Cheers,
> Willy

cu
Adrian

-- 

       "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


From: Jean Delvare <khali@linux-fr.org>
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sat, 23 Sep 2006 22:49:09 +0200

Hi Adrian, Greg,

> On Sat, Sep 23, 2006 at 12:47:35AM +0200, Adrian Bunk wrote:
> > On Fri, Sep 22, 2006 at 03:38:59PM -0700, Greg KH wrote:
> > > On Sat, Sep 23, 2006 at 12:23:00AM +0200, Adrian Bunk wrote:
> > > > Andrew Burri:
> > > >       V4L/DVB: Add support for Kworld ATSC110
> > > > 
> > > > Curt Meyers:
> > > >       V4L/DVB: KWorld ATSC110: implement set_pll_input
> > > >       V4L/DVB: Kworld ATSC110: enable composite and svideo inputs
> > > >       V4L/DVB: Kworld ATSC110: initialize the tuner for analog mode on module load
> > > > 
> > > > Giampiero Giancipoli:
> > > >       V4L/DVB: Added support for the LifeView FlyDVB-T LR301 card
> > > > 
> > > > Hartmut Hackmann:
> > > >       V4L/DVB: Added support for the ADS Instant TV DUO Cardbus PTV331
> > > >       V4L/DVB: Added PCI IDs of 2 LifeView Cards
> > > >       V4L/DVB: Corrected CVBS input for the AVERMEDIA 777 DVB-T
> > > >       V4L/DVB: Added support for the new Lifeview hybrid cardbus modules
> > > >       V4L/DVB: TDA10046 Driver update
> > > >       V4L/DVB: TDA8290 update
> > > > 
> > > > Peter Hartshorn:
> > > >       V4L/DVB: Added support for the Tevion DVB-T 220RF card
> > > 
> > > Hm, all of these patches seems like these are new features being
> > > backported to the 2.6.16.y kernel, which is not really allowed under the
> > > current -stable rules.
> > > 
> > > Or are these patches just bugfixes that fix with the current -stable
> > > rules?
> > 
> > They add support for additional hardware to the saa7134 driver.
> 
> That's not a bugfix.
> 
> > If you look at the actual diff there's not much that could cause any 
> > regression since nearly all of these change don't change anything for 
> > the already supported cards.
> 
> I'm not disagreeing about the regression issue.  I'm just concerned
> because you are starting down the slope of "backporting new driver
> support" to the 2.6.16 tree, and that's something that I thought you did
> not want to do.
> 
> But if it is, let us know, and we can discuss it.

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 sole fact that Adrian felt the need to release a -pre1 for
2.6.16.30 betrays his lack of confidence IMHO. And the size of
ChangeLog-2.6.16.29 speaks for itself.

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?

Thanks,
-- 
Jean Delvare



From: Adrian Bunk [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sun, 24 Sep 2006 00:33:48 +0200

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



From: Lee Revell [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sat, 23 Sep 2006 18:47:54 -0400

On Sun, 2006-09-24 at 00:33 +0200, Adrian Bunk wrote:
> 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. 

I think the point that people are trying to make is that adding new PCI
IDs carries an inherent risk of regression.  Unless you have access to
every device with that ID for regression testing it could be the
difference between a machine where one device doesn't work and a machine
that locks up hard.

Lee



From: Adrian Bunk [email blocked]
Subject: Re: Linux 2.6.16.30-pre1
Date:	Sun, 24 Sep 2006 00:58:38 +0200

On Sat, Sep 23, 2006 at 06:47:54PM -0400, Lee Revell wrote:
> On Sun, 2006-09-24 at 00:33 +0200, Adrian Bunk wrote:
> > 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. 
> 
> I think the point that people are trying to make is that adding new PCI
> IDs carries an inherent risk of regression.  Unless you have access to
> every device with that ID for regression testing it could be the
> difference between a machine where one device doesn't work and a machine
> that locks up hard.

"a machine that locks up hard" is a pretty uncommon case, and it should 
be ruled out by the following two factors:
- patch must be in Linus' tree
- I'm asking the patch authors and maintainers of the affected subsystem
  whether the patch is OK for 2.6.16

You never achieve 0% risk, but many bug fixes have a much higher risk of 
regression.

I do know that the only value of the 2.6.16 tree lies in a lack of 
regressions and act accordingly, and as soon as people will report 
regressions compared to earlier 2.6.16 kernels I'll know that I'll have 
done something wrong (but I haven't yet gotten such bug reports).

> Lee

cu
Adrian

-- 

       "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

• Archive of above thread