lkml.org 
[lkml]   [2008]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [GIT]: Networking
From
Date
Hi Linus,

> > John was just pointing out (like myself before) that a lot of people are
> > under the impression that documentation updates and new drivers should
> > not be queued up and merged as soon as possible.
>
> I think (and hey, I'm flexible, and we can discuss this) that the rules
> should be:
>
> - by default, the answer should always be "don't push anything after the
> merge window unless it fixes a regression or a nasty bug".
>
> Here "nasty bug" is something that is a problem in practice, and not
> something theoretical that people haven't really reported.
>
> - but as a special case, we relax that for totally new drivers (and that
> includes things like just adding a new PCI or USB ID's to old drivers),
> because (a) it can't really regress and (b) support for a specific
> piece of hardware can often be critical.
>
> With regard to that second case, I'd like to note that obviously even a
> totally new driver _can_ regress, in the sense that it can cause build
> errors, or problems that simply wouldn't have happened without that
> driver. So the "cannot regress" obviously isn't strictly true, but I
> think everybody understands what I really mean.
>
> It should also be noted that the "new driver" exception should only be an
> issue for things that _matter_.
>
> For example, a machine without networking support (or without suppoort for
> a some other really core driver that provides basic functionality) is
> practically useless. But a machine without support for some particular
> webcam or support for some special keys on a particular keyboard? That
> really doesn't matter, and might as well wait for the next release.
>
> So the "merge drivers early" is for drivers that reasonably _matter_ in
> the sense that it allows people to test Linux AT ALL on the platform. It
> shouldn't be "any possible random driver".
>
> IOW, think about the drivers a bit like a distro would think about
> backporting drivers to a stable kernel. Which ones are really needed?
>
> Also, note that "new driver" really should be that. If it's an older
> driver, and you need to touch _any_ old code to add a new PCI ID or
> something, the whole argument about it not breaking falls away. Don't do
> it. I think, for example, that the SCSI people seem to be a bit too eager
> sometimes to update their drivers for new revisions of cards, and they do
> it to old drivers.
>
> And finally - the rules should be guidelines. It really isn't always
> black-and-white, but most of the time the simple question of "could this
> _possibly_ be just queued for the next release without hurting anything"
> should be the basic one. If the answer is "yes", then wait.

I am perfectly fine with these rules. You only had to spell them out :)

Regards

Marcel




\
 
 \ /
  Last update: 2008-08-20 19:35    [W:0.067 / U:0.052 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site