It's same as with Reiser4
It's same as with Reiser4
Posted Nov 12, 2008 9:11 UTC (Wed) by khim (subscriber, #9252)In reply to: The sad story of the em28xx driver by cjayachandran
Parent article: The sad story of the em28xx driver
If you are abusing developers's and users's trust it becomes suddenly much harder to integrate code in kernel. Take look on the story with Reiserfs and Reiser4: Hans promised to work with the community on Reiserfs and so after long deliberation it was included in kernel. After few years he started to close bugs and feature requests with "use reiser4" (effectively abandoning users) and stopped reiserfs support (when something went wring he pointed out that the same thing worked perfectly with previous version of kernel and basically refused to debug and fix problems thus abandoning developers). This made inclusion of reiser4 more-or-less impossible: since it was pretty clear that reiser4 will be abandoned once it'll be included all problems which usually don't act as merge blockers (because kernel developers know they can be fixed later) were declared as such (because it was not clear if Hans and his command will try to fix them after merge and history showed that he'll probably not bother).
And in most cases newer drivers support more hardware, not less. Kernel developers are quite reluctant to include driver which works on subset of hardware just because driver developer is not interested with community work. If there are technical reasons to have two drivers it's Ok, but if the reasons are political... it's different story. Multiple drivers are easily accepted as temporary solution, but then someone must merge support for other hardware - and then we have "reiserfs situation" where developer works for it's own feature and against all others...
Posted Nov 14, 2008 23:25 UTC (Fri)
by giraffedata (guest, #1954)
[Link] (2 responses)
Is it actually a requirement for driver inclusion that future support be lined up? That seems to be the opposite of the open source process. Rather, a developer puts code into the mainline so that the whole rest of the world can maintain it. In particular, users of the code — people with a material interest in it — maintain it. If the code doesn't get maintained and becomes unusable, we just drop it back out.
The article mentions the confusion factor of having two similar drivers. I can think of another drawback: division of development and test effort. All of these are weak.
Mauro doesn't explain his reason for not wanting both. He just says:
That's non sequitur to me.
Posted Nov 14, 2008 23:32 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
there have been many examples of alternate drivers for hardwar being in the kernel, very few of them have worked out well in the long run, so kernel devs don't want to do more of it.
Posted Nov 15, 2008 5:30 UTC (Sat)
by mrec (guest, #41847)
[Link]
http://mcentral.de/hg/~mrec/em28xx-new/shortlog
just check the list of contributors, and the maintainer hard fights against it now. The reason for the big patch has always been that the code had to be rebased because the maintainer basically didn't care about anything there.
Another example
http://linuxtv.org/hg/v4l-dvb/rev/dc22320bb695
I don't see any pull request on the mailinglist, Mauro does it offlist excluding everyone else from it. Ok I acknowledge that is what's wanted and how it should be done.
Markus
If I follow your analogy, you're saying that it would be bad to include Markus's new driver alongside the existing one because Markus would eventually abandon it in favor of working on yet another new driver.
It's same as with Reiser4
Both upstream and the 4 duplicated drivers have similar functionality. Also,
the upstream driver is actively maintained. So, there's no sense on accepting
those duplicated drivers.
It's same as with Reiser4
It's same as with Reiser4
It's about that this code has been available for years