LWN: Comments on "Why some drivers are not merged early"

Why some drivers are not merged early

man_ls — Sun, 22 Jun 2008 17:54:22 +0000

Sure, but to what degree? That is the interesting question, and it can be formulated as a trade-off. Is the increase in quality worth the initial bugginess?

Why some drivers are not merged early

mitchskin — Sat, 21 Jun 2008 08:17:27 +0000

On the other hand, the idea that in-tree code tends to be less buggy than out-of-tree code is relatively uncontroversial. So, for many drivers at least, a "merge first and fix it up later" policy may well lead to the best results in the shortest period of time.

Maybe having high hurdles to inclusion is what makes in-tree code less buggy in the first place? One wonders whether adopting the approach advocated by the second sentence above might make the first sentence less truthful.

Why some drivers are not merged early

jgsack@san.rr.com — Fri, 20 Jun 2008 22:55:33 +0000

Seems like we might be able to learn a lesson from the delay in getting a decent wireless
stack.

Something (like this) likely to affect everybody is not that hard to identify. Every
distribution should recognize that a coordinated effort, probably with centralized resources,
possibly with special task funding would be a benefit to themselves. Could not someone (at
each distro) be charged with the job of looking for these needs/opportunities?

Regards,
..jim

Disinclusion

corbet — Thu, 19 Jun 2008 16:03:16 +0000

That really only works in the time between merging and the first stable release thereafter. Once the driver is shipped, yanking it out will break things for users, and that's generally considered to be undesirable.

Why some drivers are not merged early

johnkarp — Thu, 19 Jun 2008 15:55:01 +0000

Couldn't disinclusion be used as a stick? i.e. 'Fix these critical issues 
or your driver gets tossed'