Re: [PATCH 02/25] xfstests: remove bench infrastructure

From: Dave Chinner <david@fromorbit.com>
To: Phil White <pwhite@sgi.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 02/25] xfstests: remove bench infrastructure
Date: Fri, 22 Mar 2013 18:37:43 +1100	[thread overview]
Message-ID: <20130322073743.GS17758@dastard> (raw)
In-Reply-To: <20130321235207.GK2025@caliban.engr.sgi.com>

On Thu, Mar 21, 2013 at 04:52:07PM -0700, Phil White wrote:
> On Wed, Mar 20, 2013 at 09:31:49AM +1100, Dave Chinner wrote:
> > I understand why you see value in a benchmark infrastructure, but
> > that's not the issue here. The issue at hand is whether we should be
> > trying to maintain arbitrary abstractions that are made redundant by
> > the cleanup patch in the hope they are useful in the future.
> > 
> > There are solid technical reasons for what I've done, but you
> > haven't provided any to advocate why we should accept your version
> > as a better solution. "personal interest" is a good thing to have,
> > but it's not a convincing technical argument....
> 
> Let me be clear:
> 
> Personal interest is why I took it upon myself to move this along,
> rather than letting it moulder away even further than it has while
> we wait for you to respond to our feedback.

/me does a double take

Please don't try to rewrite history.  This patchset has been held up
by SGI steadfastly refusing to remove the bench infrastructure
regardless of the technical merits of doing so, not by me failing to
respond to SGI's feedback.

> It makes me wonder what your motives are.  Did you swear some sort of
> vendetta against bench and remake?  Is there a blood oath between the
> houses of Chinner and common?

[...]

> It's unnecessary code churn.

You're calling this code churn and implying it's driven by zealotry.
I'd guess this is the first major cleanup you would have seen in the
XFS code base. We've done many and as a matter of principle they do
not leave unnecessary cruft behind.  This is the way we improve the
quality of the code base.

It's not possible to clean up code properly if you don't remove all
the problematic code and interfces when the opportunity arises.  If
it turns out we need it in future, then we pull it back out of the
revision history and use just the bits we need.  We've been through
this cycle several times before as needs have changed. e.g.  have a
look at the history of the XFS_ISIZE macro in the kernel code.

> As for my work, there's an advertising slogan which I'm adapting for you
> here: "One oughtn't post a whine before its time".  I have not posted
> that work yet.

OSS development motto:

"Release early. Release often."

> What I do know is that you're making extra work for us.

Other people do development, and they are not going to stop making
changes just because it "makes extra work for you".  I have to keep
tens of thousands of lines of patches current at the moment with all
the CRC changes, but I'm not using that as an excuse to stop other
people making changes...

> So my choices are simple here:
> 1) I could give up -- as everyone else has -- and let this linger forever,

It won't linger forever - I'm really not that far away from sticking
a fork in xfstests...

> 2) You could accept that this is a change which you have no real reason to
>    make, or
> 3) I can do what I set out to do:  Get this patch series into xfstests and
>    write extra code to bring my stuff in.
>
> The timeframe in which xfstests can move forward in cases 1 or 2 are
> unacceptable to me.  So I'm going to do 3, review your March 15th series,
> and move this forward.

OK, well lets see how that goes :)

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs