On Sep 18, 2005, at 13:22:27, michael chang wrote:
On 9/18/05, Christoph Hellwig <[email protected]> wrote:
On Sun, Sep 18, 2005 at 01:21:23PM +0300, Denis Vlasenko wrote:
This is it. I do not say "accept reiser4 NOW", I am saying "give
Hans good code review".
that and there's much more exciting filesystems like ocfs2 around
that
This is exciting to... whom?
To the people that review the code. We're all volunteers here; if
your filesystem is so ugly and hard to read that the code reviewers
don't feel like finding time to slog through the mess, then it
probably means that you need to clean the code, document it better,
make it simpler to understand, fix the coding-style, etc.
The only thing that appears remotely interesting about it is that
it's made by Oracle and apparently is supposed to be geared toward
parallel server whatsits. This might be helpful to corporations,
but seems senseless toward many consumers. (I'm assuming there's
still at least one consumer left who still uses Linux.)
Like I said above, we're all volunteers. Personally, I find OCFS2
_much_ more interesting than reiser4, because it has a lot of cool
networked lock-managing algorithms that (given my current limited
understanding), work black magic. Given this, I'm a lot more likely
to spend time reading the OCFS2 code because its interesting than I
am reading reiser4 code, even though somebody eventually probably
needs to do said review. Hans' personal attacks on the people who
have criticized his code make such tasks even less personally
gratifying (IE: less interesting). I think some people are likely
hoping right now that if they put off the reiser4 code review long
enough, maybe the authors will take a hint and have it a bit cleaner
by the time they finally do get around to the review.
Give Hans a chance; and please try to understand, even if he's hard
to work with. Discriminate him because he's not a developer you
can talk with, and I believe that's like discriminating a guy in a
wheelchair because he can't run with you when you jog in the morning.
When you start getting into obscure discrimination analogies, the
discussion has become _way_ nontechnical. If this goes this goes any
further, somebody's probably going to compare a kernel developer to a
Nazi or Hitler, invoking Godwin's law and effectively killing the
thread. Please get this back onto a technical bent or drop it.
Not everyone has the same "common sense" that you do. Explain,
fully, with reasoning, and reproducable back-up statistics on
common hardware, what code is wrong, and what must be written
instead. We'd like to be efficient, and it's not being efficient
to play a guessing
game with us. If you don't have the time to review, then please
hold off on replying until you have a through review of at least
part of the code.
Christoph has noted a number of things in previous emails. I just
looked through the latest released code and several of them are still
valid. I would look through the latest code to see what is still
missing, but I can't get it on account of it being in bitkeeper,
which I don't have installed and don't intend to install.
I'm willing to go compare... [massive nontechnical rhetoric snipped]
Unless you have technical arguments to contribute (and you indicate
that you do not), please to not spam the LKML with useless rhetoric-
filled emails that most of us will delete because we have too many
other things to do to bother reading or responding to.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$ L++++(+
++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP+++ t+(+
++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r !y?(-)
------END GEEK CODE BLOCK------
-
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]
| |
 |