On Fri, 2006-12-01 at 19:25 +0000, Al Viro wrote: > On Fri, Dec 01, 2006 at 01:19:04PM -0600, Russell Cattelan wrote: > > On Thu, 2006-11-30 at 12:15 +0000, Steven Whitehouse wrote: > > > >From 539e5d6b7ae8612c0393fe940d2da5b591318d3d Mon Sep 17 00:00:00 2001 > > > From: Steven Whitehouse <[EMAIL PROTECTED]> > > > Date: Tue, 31 Oct 2006 15:07:05 -0500 > > > Subject: [PATCH] [GFS2] Change argument of gfs2_dinode_out > > > > > > Everywhere this was called, a struct gfs2_inode was available, > > > but despite that, it was always called with a struct gfs2_dinode > > > as an argument. By making this change it paves the way to start > > > eliminating fields duplicated between the kernel's struct inode > > > and the struct gfs2_dinode. > > More pointless code churn. > > > > This only makes sense once the file system is working > > and we have time to do this type of cleanup on against > > a stable and TESTED code base. > > Bzzert. Cleaner code is easier to _get_ stable. "Keep it ucking fugly > until everyone stops looking at it out of sheer disgust" is a bad idea.' 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. -- Russell Cattelan <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
