Pekka Enberg wrote:
> On 7/19/06, Tilman Schmidt <[email protected]> wrote:
>> You can't have it both ways. Either you want everything in the main
>> kernel tree or you don't. Of course there will always be a limbo of
>> code waiting for inclusion. But if it has to linger there for too
>> long (again: no matter for what reason) then it invalidates the
>> whole concept of not having a stable API. And that would be a pity.
>
> You seem to have this idea of everyone having some sacred right of
> having their code either in the kernel or supported by the kernel
> developers.
No, and seriously I cannot see how you could possibly get that
impression from what I wrote.
> It is up to the maintainers to decide what's included and what's not.
Ok. But then it's also up to them to stand by their decision and
take the heat for it. Don't jump from your left foot to your right
foot, saying "submit your code to the kernel" if someone wants to
maintain something off-tree and "maintain it separately" if they
try to submit it. State clearly: "We do not want Reiser4 in Linux"
and defend it, instead of creating a string of ifs and then
complaining that people go on about it.
> We obviously don't want _everything_ in the kernel anyway and don't
> want to stagnate the kernel development because of out-of-tree code
> either.
Well, that doesn't make sense. You can't have your cake and eat it
too. Either you have out-of-tree code or you haven't. Documents
like stable_api_nonsense.txt explicitly discourage out-of-tree code,
which is formally equivalent to saying that all kernel code should
be in-tree. Therefore an attitude which says "go on developing that
code out-of-tree, it's not ready for inclusion yet" is in direct
contradiction with the foundations of the no-stable-API policy.
> If you're unhappy about maintainer decisions, feel free to
> complain to them
Well, isn't that what the present thread is all about?
> or better yet, step up to do the necessary legwork to
> get the code included.
That's completely beside the point. There are enough people already
who are willing to do the legwork. The question is whether they and
the kernel maintainers will be able to bridge their differences
about how it should be done, and that would not be made easier by
another party entering the arena.
Seriously, what do you think would happen if I actually took the
Reiser4 code, modified it according to what I think the kernel
people would like to see, and submitted the result to lkml? I'll
tell you what'd happen: I would get heat from both sides, I would
be blamed both for perceived flaws in the original design and for
any deviation from it, my motives would be questioned, I would be
asked whether I'd commit to maintaining that code for the
foreseeable future, and there would be no right answer to that
question. No matter what I did, it would only make things worse.
(Please note that the scenario above is completely fictitious. I am
neither capable of, nor interested in, taking over the development
of Reiser4 or promoting its admission into the kernel tree.)
> After all, that's how Linux development works.
Obviously there's more to it than that. There are people involved.
HTH
Tilman
-
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]
