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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
