lkml.org 
[lkml]   [2008]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT]: Networking
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


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