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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
