Re: [GIT]: Networking

["Luis R. Rodriguez" <lrodriguez@atheros.com>]

On Wed, Sep 03, 2008 at 04:26:03PM -0700, David Miller wrote:
> From: Linus Torvalds <torvalds@linux-foundation.org>
> 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.

Before snapping at people for not following "orders" we need a clear
guideline for what should or not be sent. We're all at fault if we are
not getting this through people. Most likely not many of us subscribe to
linux-kernel so I would think the next best thing we can do is to get our
maintainers to communicate to us of new rules and give a few examples of
what can go in or not.

I trust that should this had been done *well* none of these issue would have
come up and we can avoid angry exchanges.

> 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.

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

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.

  Luis