Re: [GIT]: Networking

[david]

On Wed, 3 Sep 2008, Luis R. Rodriguez wrote:

> On Wed, Sep 03, 2008 at 04:26:03PM -0700, David Miller wrote:
> > From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > Date: Wed, 3 Sep 2008 16:24:16 -0700 (PDT)
> >
> > > On Wed, 3 Sep 2008, Linus Torvalds wrote:
> > > > What's so hard to understand about this?
> > >
> > > Here's a simple rule of thumb:
> > >  - if it's not on the regression list
> > >  - if it's not a reported security hole
> > >  - if it's not on the reported oopses list
> > > then why are people sending it to me?
> > >
> > > IOW, if it's just another random improvement, and you send it to me
> > > outside of the merge window, then what is the point of the merge window?
> >
> > This is exactly what I've been trying to tell the Intel wireless folks
> > but they refuse to listen.
>
> What I think really happens here IMHO is communication needs to be
> enhanced. I only recently noticed that "regression only" policy for
> 2.6.27 for example. I think some of us were rather surprised by it too.

the policy has been the same for quite a while, it's not new for 2.6.27

> > I just won't take their stuff until they get their act in gear.
> >
> > No problem.
>
> On the other side of the spectrum, and to try to understand this better,
> since ath9k is new we obviously cannot get regressions, this means
> unless we find a security hole in our driver or if we can generate an
> oops with 2.6.27 we cannot send patches for ath9k for 2.6.27?
>
> It seems to make sense to me for purposes of stabalizing the kernel for
> sure, however, on the other hand it does also make 2.6.27 miss out on a
> few possible small fixes which may appear here and there.
>
> What will happen then is distributions will end up using their own
> patches on top of the kernel, or users using something like
> compat-wireless to get more bleeding edge stuff. This is exactly what we
> want to avoid.

no, if it's that bad it can go into the -stable kernel patches. but the 
next release kernel will be out in just a couple of months, so it only 
matters for that short window.

> To avoid it I do think another exception needs to be made for patches:
>
> * Small fixes which make something that was not working, which was
>  supposed to work work

but you can't prove that this patch doesn't break something else (if only 
by altering the timing just enough to expose a race condition somewhere)

> If these type of patches cannot be submitted we will have a stable
> kernel for sure but yet buggy leaving people to opt for alternatives
> for small fixes or driver updates.

but if you are changing the continuously, why should people test anything? 
you're going to change it in unpredictable ways before the release anyway.


it may be valid to tinker with a new driver that didn't exist before, but 
this far into the release cycle even that's highly questionable, and if 
you are asking for something to be included becouse of that you need to 
spell it when submiting the patch (and possibly in the changelog)

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/