On Wed, 2007-08-01 at 10:14 +0200, [email protected] wrote:
> On 8/1/07, Arjan van de Ven <[email protected]> wrote:
> > Let me repeat the key message:
> >
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> > It does not matter who's code gets merged.
> >
> > What matters is that the problem gets solved and that the Linux kernel
> > innovates forward.
>
> And, from a standpoint of ONGOING, long-term innovation: what matters
> is that brilliant, new ideas get rewarded one way or another.
and in this case, the reward is that the idea got used and credit was
given....
> Because
> if you don't, the people with the 'different' ideas walk away, you end
> up with only those who 'fit' the culture, and there goes innovation.
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)
> That's why I tried to get involved in this discussion. It doesn't
> matter who's code gets merged. But it does matter that people get
> scared away. It took the kernel folks a few years, but they managed to
> get someone kicked out who's not 'in-crowd', who clearly has a
> different view, and who has the intent and motivation to write and
> maintain code.
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.
> Of course that's 'overdone', but it conveys a point: If you focus too
> much on exploiting current code, instead of fundamentally exploring
> new ideas you go down in the long run.
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
