Reiser4 and kernel inclusion [LWN.net]

Reiser4 and kernel inclusion

Posted Sep 22, 2005 15:55 UTC (Thu) by zooko (subscriber, #2589)
Parent article: Reiser4 and kernel inclusion

"That said, reiser4 has had a harder time and more microscopes applied to its code than many other developments. Mr. Reiser's approach to community relations, which strikes many as occasionally belligerent and paranoiac, certainly has not helped here."

In other words, some of the kernel developers are giving reiser4 an extra hard time of it because Hans Reiser has angered them and this is how they can use their power to punish him. Is that what's happening?

Or is it that Hans's alleged belligerence and paranoia has somehow contributed to technical issues which need to be solved before reiser4 can be included?

(Log in to post comments)

Reiser4 and kernel inclusion

Posted Sep 22, 2005 16:01 UTC (Thu) by zooko (subscriber, #2589) [Link]

Following up to myself because I realized that the original article suggests a third possibility: the alleged belligerence and paranoia has led kernel developers to suspect that Hans Reiser and/or his employees are unreliable maintainers of the code, and they are hesitant to include code which might be unreliably maintained by the original authors.

Honestly, having read a few of the threads on lkml myself, I still lean toward the first hypothesis: some people are angry at him, and are thus motivated to criticize his works more harshly. The latter hypothesis -- "are namesys reliable maintainers?" -- makes sense in the abstract, but if you consider the way the Linux dev process already includes plenty of personalities who are at least as belligerent as Hans is, and plenty of code that is worse-maintained than reiser3 or reiser4, I don't think that's really the explanation.

Reiser4 and kernel inclusion

Posted Sep 22, 2005 17:09 UTC (Thu) by southey (subscriber, #9466) [Link]

My understanding of the kernel development (from reading) is that the kernel does not seem to discriminate between people but rather on the actual code quality. It has been very clear that bad code (really how the code affects the complete kernel) does not enter or stay in the kernel regardless of who wrote it.

I think that the other filesystems like JFS also went through the same process (relative to the state of the kernel) except that these ports than new filesystems. These also had to undergo some changes that the respective developers made. I recall similar issues to reiser4 for when reiser3 started to be merged but reiser4 changes appear to be more invasive.

As for the current status, I think (with no knowledge of kernels) that the apparent rigid criteria applied to reiser4 is no different than say the current criteria in the kernal for real-time linux. Okay, sure a major kernel developer is involved (perhaps that is what reiser4 lacks) in the real-time changes but not all the real-time changes have been merged, some were rejected. Often these changes involved major rewrites (like making the changes less invasive etc).