Message-ID: <4d8e3fd30808201150j75a7d72bme81551305d3a68b9@mail.gmail.com>
Date:	Wed, 20 Aug 2008 20:50:42 +0200
From:	"Paolo Ciarrocchi" <paolo.ciarrocchi@...il.com>
To:	"Linus Torvalds" <torvalds@...ux-foundation.org>
Cc:	"John W. Linville" <linville@...driver.com>,
	"David Miller" <davem@...emloft.net>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	netdev@...r.kernel.org,
	"Linux Kernel Mailing List" <linux-kernel@...r.kernel.org>,
	"Marcel Holtmann" <marcel@...tmann.org>
Subject: Re: [GIT]: Networking

On Wed, Aug 20, 2008 at 7:33 PM, Marcel Holtmann <marcel@...tmann.org> wrote:
> 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 :)

I wonder whether if it would be a good idea to periodically send out an email
with the basic rules to be followed in each phase of the project.


regards,
-- 
Paolo
http://paolo.ciarrocchi.googlepages.com/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists