Messages in this thread | | | Date | Tue, 19 Aug 2008 21:47:25 -0700 (PDT) | From | david@lang ... | Subject | Re: [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
| |