On Fri, 8 Jul 2005, Ed Cogburn wrote:
Maybe its because Hans and Co., having only a finite amount of dev time,
would much prefer to spend that time on R4 rather than R3? Maybe if we
were to let R4 into the kernel, it wouldn't be long after that R3 could be
retired because everyone has moved to R4? Maybe if R4 had been allowed
into the mainstream kernel a year ago, this ENTIRE ARGUMENT would be moot?
Since when has there been a requirement for all new code to have a signed
support contract before it enters the kernel? Don't tell me this is
normal, because I damn well know its not. Early on and for the most part
even today, good stuff gets into the kernel without any explicit or at
least meaningful promises of long term support. That stuff stays in the
kernel as long as there is someone willing to maintain it, and it
disappears from the kernel when there is no one left willing to keep it
up-to-date. That has always been the basic rule, without it Linux would
never have gone beyond the stage of being Linus's toy, because if Linus had
demanded such a support commitment up front, people would have lost
interest in hacking on his toy.
Devs should be free to work on whatever they want, because most of them are
doing this on their own time anyway, otherwise they might just decide to
hack on some other OS, or a fork of Linux instead. Demanding long term
support commitment from volunteers is just bizarre, since pretty soon, you
won't have many volunteers left, with the ones still remaining consistently
lying to you as everyone will know that the promises they are making can't
be enforced..... As for code from companies, has Linus gotten a signed
support contract from IBM for JFS? If he asked, do you really think they
would agree to one?
So this business of demanding a perpetual support contract from Hans for R3
before you even let R4 into the kernel is patently absurd. Such a contract
won't be needed once R4 gets into widespread use and stabilizes, allowing
R3 users to switch over to it, never mind that this has not been required
to my knowledge of anyone else. Either you're putting the cart before the
horse on this one without realizing it, or you're just another member of
the 'say-no-to-change' group (or worse, the say-no-to-Hans group) using any
excuse that pops into your head for why you keep saying 'no'.
it's not that they are being asked to commit to a perpetual support
contract, it's the fact that they AREN'T being asked to commit to a
perpetual support contract that makes it more important that the code that
they are asking to be merged must fit in well with the code and the
philosphy of the rest of the kernel so that it can be supported well by
others
if the kernel folks don't agree with the underlying design they may end up
accepting it for a while, but will rip it out as soon as they get an
excuse (see devfs for a perfect example)
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
-
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]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
| |
 |