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

[Troy McCorkell <tdm@sgi.com>]

On 03/22/2013 11:22 AM, Troy McCorkell wrote:
> On 03/22/2013 02:37 AM, Dave Chinner wrote:
>> 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.
>
> As I understood the history, this reorganization has been talked about 
> for a long time, and agreed upon at the Linux Filesystem meeting.
>
> Dave did the work to reorganized the tests and posted as a RFC. A 
> couple people sent
> back rough feedback like "the output from this test ends up in the 
> main directory".
>
> SGI wanted to make sure benchmarks are available and easy to use.
> Dave said many or all of the benchmarks in xfstests are out of date, 
> he even provided examples of better benchmarks.
>
> We all got sucked into other projects until recently Eric pinged  on 
> this series because it
> will benefit the whole Linux filesystem community.
>
> Phil took over reporting the series, and reposted it to the list. Dave 
> reposted the series that
> he had with updates.
>
> I thought we all reached a common agreement on the reorganization. We 
> all want it. SGI
> would like to add benchmarking as a follow-up patch.  Dave wanted to 
> make sure that if
> done, benchmarking is done correctly. Dave's latest series is more up 
> to date. I thought
> we were going to do a quick re-review, and get it committed ASAP.
>
> We will complete the review of Dave's second patch set and get it 
> committed ASAP.
> I expect it will be committed the beginning of next week.
>
> Thank you,
> Troy McCorkell
> SGI XFS Manager
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs

Rich is updating the patch set to TOT.   He'll complete it today and do 
a test run.
The patch series should be committed tomorrow. (Wed March 27)

Thanks,
Troy

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