Comment 37 for bug 297213

Brad Figg wrote:
>>> It is quite a bit of work for us to maintain drivers that are not upstream.
>> This one I don't buy. How is it more work to rip the tp_smapi driver
>> out of the tpctl package than to include the whole thing?
>
> For this example, there is already a hdaps driver upstream. I just doesn't have
> the support that a part of the community desires. In order to put in a second
> hdaps driver, I have to go into the package, pull out the desired bits, rename
> where necessary and integrate them into our kernel tree.
>
> Now, in this case that isn't a great deal of work. However, if you apply this to
> all the requests that we get you can see how it can be quite a bit of work.

For drivers that are not in mainline for one reason or another, there's
always a trade-off between the benefit to the community and the work
required to maintain the driver out-of tree, which has to be decided on
a case-by-case basis and not by some flawed slippery-slope argument.
Besides, all the work has been done in this case already.

>>> It is felt that the maintainers of the two drivers
>>> should work together to get a combined driver upstream.
>
>> I highly doubt that this is going to happen anytime soon.
>
> That might be, however, that is what should have been happening all along. Even
> when the driver was included into Hardy. And if you want it in Karmic that's what
> it's going to take.

It's not going to happen, though -- not until either Shem Multinymous
decides to come out of his anonymity or GregKH stops worrying about a
NDA that probably doesn't exist in the first place.

http://lkml.org/lkml/2008/9/15/126

> Also, if it goes upstream, all distros can take advantage of it and it benefits a larger
> section of the community.

If the kernel-team thinks that not including the driver in their kernel
will somehow help get this driver into mainline faster, I think they're
mistaken.