Re: [Cluster-devel] Re: [GFS2] Change argument of gfs2_dinode_out [17/70]

[Pavel Machek]

Hi!

> > > code clean up are not without risk and with no regression test suite to
> > > verify
> > > that a "cleanup" has not broken something. Cleanups are very much a
> > > hindrance to stabilization. With no know working points in a code
> > > history it becomes difficult
> > > to bisect changes and figure out when bugs were introduced
> > > Especially when cleanups are mixed in with bug fixes.
> > > 
> > > Pretty code does not equal correct code.
> > 
> > No, but convoluted and unreadable code ends up being crappier due
> > to lack of review.  And that's aside of the memory footprint,
> > likeliness of bugs introduced by code modifications (having in-core
> > and on-disk data structures with different contents and the same C
> > type => trouble that won't be caught by compiler), etc.
> 
> Nothing makes up for the complete lack of GFS2 testing.
> reviewed code does not equal correct code either.

Tested code does not equal correct code, either.

> gfs2 is supposed to be stabilized and use-able for the up coming rhel5
> release, not pretty up for somebody to print out and hang on their wall.

Feel free to keep rhel5 ugly, but we are talking mainline here.

							Pavel
-- 
Thanks for all the (sleeping) penguins.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/