Cc: Hua Zhong <hzhong@...>, Carlo Florendo <subscribermail@...>, Roman Zippel <zippel@...>, Linus Torvalds <torvalds@...>, Michael Chang <thenewme91@...>, Kasper Sandberg <lkml@...>, Linux Kernel Mailing List <linux-kernel@...>
and in this case, the reward is that the idea got used and credit was
given....
yet at the same time if people walk away just because their code didn't
get used, even though their problem got solved, should we merge "worse"
code just to prevent that ? That's almost blackmail, and also just
stupid.
(not suggesting that SD in this case was better or worse, just trying to
make a general point)
And he did manage to get some of his code in, just not all. He also
managed to get people interested in his problem so much that a healthy
stint of competition happened and his problem got solved. If people walk
away because they don't 100% always get things done EXACTLY their way..
well so be it.
here's the thing. Fair scheduling DID get explored. deeply so.
now, getting people interested in your problem (and that is needed to
get them to pay attention to it) is a sales job, no ifs and buts there.
You need to convince them that 1) the problem is real, 2) the problem is
relevant. If you also have a proposed solution you also need to convince
them that 3) the solution solves the problem and 4) that it's the right
way to solve the problem. That isn't politics, it's part of how the
ecosystem works; people are not stupid, but you need to convince them
about your problem and solution. And that "default a bit skeptical and
overworked" approach is the foundation of the process; the same way as
you need to pass a code review before people will merge your code.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
-
