From: Pavel Machek <pavel@ucw.cz>
To: cluster-devel.redhat.com
Subject: [Cluster-devel] Re: [GFS2] Change argument of gfs2_dinode_out [17/70]
Date: Sat, 2 Dec 2006 11:40:17 +0000 [thread overview]
Message-ID: <20061202114016.GA4030@ucw.cz> (raw)
In-Reply-To: <1165015786.1194.133.camel@xenon.msp.redhat.com>
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.
WARNING: multiple messages have this Message-ID (diff)
From: Pavel Machek <pavel@ucw.cz>
To: Russell Cattelan <cattelan@thebarn.com>
Cc: Al Viro <viro@ftp.linux.org.uk>,
cluster-devel@redhat.com, linux-kernel@vger.kernel.org
Subject: Re: [Cluster-devel] Re: [GFS2] Change argument of gfs2_dinode_out [17/70]
Date: Sat, 2 Dec 2006 11:40:17 +0000 [thread overview]
Message-ID: <20061202114016.GA4030@ucw.cz> (raw)
In-Reply-To: <1165015786.1194.133.camel@xenon.msp.redhat.com>
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.
next prev parent reply other threads:[~2006-12-02 11:40 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-30 12:15 [Cluster-devel] [GFS2] Change argument of gfs2_dinode_out [17/70] Steven Whitehouse
2006-11-30 12:15 ` Steven Whitehouse
2006-12-01 19:19 ` [Cluster-devel] " Russell Cattelan
2006-12-01 19:19 ` Russell Cattelan
2006-12-01 19:25 ` [Cluster-devel] " Al Viro
2006-12-01 19:25 ` Al Viro
2006-12-01 20:52 ` [Cluster-devel] " Russell Cattelan
2006-12-01 20:52 ` Russell Cattelan
2006-12-01 21:08 ` Al Viro
2006-12-01 21:08 ` Al Viro
2006-12-01 23:29 ` Russell Cattelan
2006-12-01 23:29 ` Russell Cattelan
2006-12-02 1:10 ` Al Viro
2006-12-02 1:10 ` Al Viro
2006-12-03 19:06 ` Russell Cattelan
2006-12-03 19:54 ` Christoph Hellwig
2006-12-03 22:44 ` Alan
2006-12-02 11:40 ` Pavel Machek [this message]
2006-12-02 11:40 ` Pavel Machek
2006-12-03 20:21 ` Rik van Riel
2006-12-03 20:21 ` Rik van Riel
2006-12-04 10:05 ` Steven Whitehouse
2006-12-04 10:05 ` Steven Whitehouse
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20061202114016.GA4030@ucw.cz \
--to=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.