| |||||||||||||
Upstream first policyUpstream first policyPosted Jun 3, 2010 5:47 UTC (Thu) by alonz (subscriber, #815)In reply to: Upstream first policy by epa Parent article: A suspend blockers post-mortem Yet another point—many kernel developers will not accept "upstream" code without a clear, demonstrable use-case (usually on actual hardware). So embedded developers are stuck in a chicken-and-egg situation: they cannot ship working systems without a working kernel, and the (upstream) kernel will not accept required changes without seeing these systems.
(Log in to post comments)
Upstream first policy Posted Jun 3, 2010 6:18 UTC (Thu) by neilbrown (subscriber, #359) [Link]
I would be very surprised if actual hardware were required.
A driver that is just a driver will normally be accepted on its own merits with the assumption that there is hardware that it works on.
There could be a problem if you need to make changes to core-code to be able to support some aspect of the driver. You will probably be asked to show the driver that needs the functionality, but you might not want to finish of the driver depending on that functionality until you know it will be accepted.
In that case you need to open a dialogue, follow the "release-early, release often" principle (though maybe not too often) and risk the need to revise your driver if the core changes don't happen the way you hope.
Maybe the trickiest bit is know who to open the dialogue with in the first place...
|
|||||||||||||