Re: reiser4 vs politics: linux misses out again

[David Lang <david.lang@digitalinsight.com>]

On Sun, 10 Jul 2005, Ed Cogburn wrote:

> > But in most of the changesets on the bkbits site you can go back over 2
> > years and not see anything from namesys people. Nearly all of the fixes
> > commited in the past 2-3 years are from SuSe.
>
>
> So, for the sake of argument, if IBM were to drop official support for JFS,
> we'd yank JFS out of the kernel even if there was someone else willing to
> support it?  Why does it now *matter* who supports it, as long as its being
> maintained?  And will we now block IBM's hypothetical JFS2 from the kernel
> if IBM, from the programmers up to the CEO, doesn't swear on their momma's
> grave that they'll continue to support JFS1, even if JFS1 is being
> supported by others?  Jeez, this is why it doesn't take a kernel dev to see
> the problems here, common sense seems to be an increasingly rare ingredient
> in these arguments against R4.  If I didn't know better, I'd think you were
> making this stuff up as you went along....

you are completely missing the point.

the fact that the kernel group is going to have to maintain the code over 
the long run means that it must be acceptable to them before it gets 
added.

so saying that it's supported (for now) by namesys doesn't matter. if it's 
not something that is in a state that can be maintained over the long 
term by the kernel group then it can't be accepted, exactly BECOUSE nobody 
expects an outside orginization to maintain the code forever.

Namesys is allowed to maintain the code themselves outside the kernel for 
as long as they want to (and even fork the kernel if they need to make 
changes to it that aren't acceptable to the mainline). Namesys is asking 
the core kernel team to accept their code into the mainline so that it 
will be maintained by the core kernel team for the indefinate future. This 
is why it's up to Namesys to satisfy the concerns of the core team, not 
the other way around.

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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/