[Top] [All Lists]

Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes

To: markgw@xxxxxxx
Subject: Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes
From: Russell Cattelan <cattelan@xxxxxxxxxxx>
Date: Wed, 23 Jul 2008 10:37:36 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <488692FB.1010101@xxxxxxx>
References: <1216556394-17529-1-git-send-email-david@xxxxxxxxxxxxx> <1216556394-17529-3-git-send-email-david@xxxxxxxxxxxxx> <20080722042829.GB27123@xxxxxxxxxxxxx> <20080722053019.GI6761@disturbed> <20080722072733.GA15376@xxxxxxxxxxxxx> <20080723000548.GG5947@disturbed> <488692FB.1010101@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20070728)
Mark Goodwin wrote:

Dave Chinner wrote:
On Tue, Jul 22, 2008 at 03:27:33AM -0400, Christoph Hellwig wrote:
I only fear
we'll never get it in with the current review and commit latencies
for XFS :(

I can see this being a big issue in the not-too-distant future.....

[getting off-topic for this thread, but anyway ..]
This is already a big issue, obviously, and has been for some time.

Internally, we're attempting to refine our patch acceptance processes,
(e.g. gitify our internal dev tree and mirror it on oss so it's much
easier to push back out to oss).
I'm sure you have seen this before:

That is a running mirror of the ptools tree into git. (via the cvs tree)

It would be really nice to move all xfs development to git finally shut down
the whole ptools -> cvs update process.

This would help facilitate creation of more "experimental" trees and/or branches
so there would not be such a long delay of getting patches distributed.

But the QA overhead remains a stubborn
problem. I think we're going to have to ask for QA tests (both regression
and performance) to be written as part of the patch acceptance policy -
under this policy, merely passing existing QA will not be sufficient.

We have recently set up external access to a system for QA and
regression testing for Christoph's use .. perhaps that should
be a permanent offering?

-- Mark

<Prev in Thread] Current Thread [Next in Thread>