Message-Id: <1153937787.25828.51.camel@xenon.msp.redhat.com>
Date:	Wed, 26 Jul 2006 13:16:27 -0500
From:	Russell Cattelan <cattelan@...barn.com>
To:	Hans Reiser <reiser@...esys.com>
Cc:	David Masover <ninja@...phack.com>, Jeff Garzik <jeff@...zik.org>,
	Theodore Tso <tytso@....edu>,
	LKML <linux-kernel@...r.kernel.org>,
	ReiserFS List <reiserfs-list@...esys.com>
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org
	regarding reiser4 inclusion

On Wed, 2006-07-26 at 08:26 -0600, Hans Reiser wrote:
> David Masover wrote:
> 
> >
> >
> >Although I should mention, Hans, that there is a really good reason to
> >prefer the 15 minute patches.  The patches that take a week are much
> >harder to read during that week than any number of 15 minute incremental
> >patches, because the incremental patches are already broken down into
> >nice, small, readable, ordered chunks.  And since development follows
> >some sort of logical, orderly pattern, it can be much easier to read it
> >that way than to try to consider the whole.
> >  
> >
> No, I disagree, if the code is well commented, it is easier to read the
> whole thing at the end when it has its greatest coherence and
> refinement.  A problem with Reiser4 is that its core algorithms are
> simply complex.  We pushed the envelope in multiple areas all at once.
> Benchmarks don't always suggest simple algorithms are the ones that will
> be highest performance.  Tree algorithms are notorious in the database
> industry for being simple on web pages but complex as code.
> 
> Some people program in small increments, some program things that
> require big increments of change, both kinds of people are needed.
> 
FWIW I think both points are valid.
 
Personally I find it difficult to completely stop what I'm doing 
and spend several days studying a large patch/complete new subsystem.

But on the other hand it's important that code that goes in the kernel 
gets a proper review, I think we all come to rely on the gatekeepers job
of making sure any given part of the kernel does not destabilize to the 
point were it interferes with our individual areas of development.

So exactly what level of granularity is appropriate  for changes? Well
that should probably be left of to the gatekeeper for each particular
area. In the case of filesystems generic vfs changes obviously need to 
be small and easy to digest, and more importantly easy to bisect
regressions. The core of the file system can be left to the person who
can best manage the code, but hopefully that person applies a reasonable
of granularity to the changes, thus allowing non familiar developers to
at least keep up and possibly make helpful suggestions.

If we look at the current "beliefs" surrounding XFS you can see the
affects of a code base that did not have an incremental development with
regards to linux anyways. Ok so ya XFS was a close sourced IRIX FS for
the first 8 years of it's life, and even once the Linux project started
there was another year or so encumbrance investigation and cleaning
before legal would sign off on its release.
So to this day the major hang up with XFS seems to be "it's to complex
because it has x thousands lines of code".  Hell by that argument Linux
has way more lines of code than IRIX could ever hope to have and is
therefore Linux is more complex than IRIX and to hard to understand. :-)
Fortunately many developers (especially ones that have worked on other
OS's) do not use "wc -l" as a tool to measure code
quality/readability/complexity. 
XFS unfortunately will probably always suffer from skepticism since
it did not grow up in in Linux.

Guess it's sort of like adopting a 8 year old child vs a new born, hard
to tell what happened in first 8 years.

-Russell Cattelan
cattelan@....org

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists