Re: Linux 2.6.16.30-pre1

[Jean Delvare <khali@linux-fr.org>]

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