Re: [GIT]: Networking

[david]

On Wed, 20 Aug 2008, Marcel Holtmann wrote:

> > And then there is the Bluetooth SCO change which I agree was
> > borderline and I should have pushed back on.
>
> so this is the statement, I sent Dave to explain why that change was in
> there:
>
> ---
> For the btusb driver this adds the promised SCO support. The btusb
> driver is a new driver and will eventually replace hci_usb. Adding SCO
> support was the last missing piece. All distributions are using the
> hci_usb driver at the moment and you can only select one of them. So
> this can't introduce any regression. With this change the distributions
> are now able to select the new driver if they really want to.
> ---
>
> Was this absolutely needed after -rc3. Of course not. No questions asked
> about it. So why did it ended up in there?
>
> Almost everybody is using the hci_usb driver and that one has issues
> that are beyond fixable. So the btusb is its replacement and with this
> change it became a real alternate solution. For me this is a new driver
> that would allow people to use it in case hci_usb gives them a hard time
> and falls over again. And fixing hci_usb is not an option. A lot of
> people tried it and they failed. I think the last one was Pavel a month
> ago. This is why I re-wrote the whole beast from scratch.
>
> So that is my excuse why I thought this would be good choice to push it
> to Dave. No more excuses and no new drivers after the merge window. At
> least not from me.

one of thr goals of the new release approach was to make releases 
frequently enough that it's not a big deal to miss a merge window, you 
only have to wait a couple of months (rather then a couple of years under 
the old model).

while I don't see a bit problem with drivers going in for previously 
unsupported hardware (at least since I custom compile my kernels with all 
unnessasary drivers disabled, so I wouldn't even try to compile them ;-) 
it doesn't hurt much, either as a user, or for you as a developer (as you 
note above) to go ahead and delay till the next merge window.

the benifits of delaying are that the changes in the -rc cycle are clearer 
and smaller. this should make the progress towards the release more 
obvious, and avoid distractions like the one that started this thread. 
yes, this will make the -rc1/-rc2 even bigger as there is more stuff going 
in, but it looks like that is being handled well (in part thanks to the 
preview that -next is providing)

so as a user/tester I want to thank you for being so willing to delay new 
stuff for the next merge window, may others learn to follow your example.

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/