> On Mon, 12 Jun 2000 colin@field.medicine.adelaide.edu.au wrote:
>
> > Cox> You are becoming the biggest hindrance to the acceptance of the file
> > system your engineers are writing for you.
>
> IOW, some of the things Reiser says may count against the premature
> inclusion of RFS in the kernel.
Reiser has some opinions regarding the political and economic nature of Linux
development. The views may have merit, or none, but that's completely
unrelated to the nature of the code he's producing/produced.
> > Reiser questions Cox's personal integrity.
>
> Immediately after this, he effectively admitted to the same fault himself.
Yes, but Reiser's not selecting packages for inclusion, is he.
> > Cox then suggests that Reiser's comments could hinder his code's
> > inclusion in 2.4.
>
> No. He indicated that Reiser was not making any progress or friends by
> making personal (unfounded) allegations. There are right and wrong ways to
> attempt to establish support for your plan: slagging off one of the most
> respected and productive members of the community on a false premise is
> probably not the right way...
Making friends and influencing kernel releases ... is that Dale Carnegie's
next book title?
You know the premise to be false, or you merely suppose it to be false? I'm
completely unconcerned as to the truth of the allegations. What seems to me
to be more interesting is that someone of reasonable intelligence could come
to believe the allegations, as a result of their interaction.
I think there's probably merit in asking the question `what influence do
corporate interests have in the selection of kernel features?' I see no merit
in labelling as paranoid someone who asks that question.
> > For Cox to even suggest this as a pretext for exclusion merely confirms
> > Reiser's perceptions. Decisions may be made on personal (not engineering)
> > grounds.
>
> This is entirely justified: including RFS without adequate integration
> testing and support/maintenance would be substantially worse than not
> including it. Reiser's antagonism strongly suggests that there will be
> limited cooperation over future development/maintenance; if this is the
> case, the code must be excluded.
Reiser's antagonism? I've been watching the reiserfs mailing list almost
since its inception, and I've not noticed any greater degree of antagonism
than I have on the linux kernel list (less, in fact.)
You're suggesting that testing/support/maintenance is somehow dependent upon
Alan Cox in person? Isn't that a problem for an open source development,
given the much trumpeted advantages of distributed debugging and support?
> > I would have hoped that Linux bundling decisions were exclusively
> > engineering-based,
>
> A rather naive approach: in practice, the code alone is no use. If Reiser
> is not prepared to cooperate and address criticism/faults of his code,
> then the code should be excluded anyway.
My understanding is that the criticism which excluded reiserfs was that it
didn't use a particular journalling system, which I believe isn't yet complete
or functional, but which was Cox's preferred system.
I didn't see any criticism of reiserfs on its merits, and I'm not sure how
you're supposed to respond to criticisms of non-compliance with a bundled o/s
capability, except perhaps stridently.
> > ``For however strong a new prince may be in troops, yet
> > will he always have need of the good will of the inhabitants, if he wishes to
> > enter into firm possession of the country.'' [Machiavelli, the Prince]
>
> The quote appears to support my side of this, not yours... Reiser is
> trying to force his code into the kernel prematurely, and rather than
> building support, he is just attacking those who oppose him - using his
> strength of troops to override the wishes of the inhabitants.
I'd thought, more, that Linux was the new prince in the big wide world of
software development (you know, the people who don't subscribe to the linux
kernel developers' list), and who might regard engineering quality as more
important than the personal relationships of the various developers. Isn't
engineering quality the thing we're all saying distinguishes Linux from
Windows? (Or is that just so much marketing?)
> > I should add, on a personal note, that I only speak freely because I have no
> > intention of ever adding a line to Linux kernel, unless it's forked.
>
> Why?
Well, it's developed by someone who half-formed an opinion on microkernels years ago and has not revised it since; who thinks a module is something you buy at Ikea; who can't/won't use a version control system and who bitches at people who do (I'm thinking of the ISDN people, here); who refuses to accept patches in .bz2 format (god knows why), who seems to adopt rather arbitrary stances on technical matters, [...big breath...] and it shows.
If I wanted to work around fairly pedestrian code while currying favour with a gerentocracy masquerading as a meritocracy, I'd go get a job with any corporate software development behemoth.
Colin.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:26 EST