[Top] [All Lists]

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

To: Russell Cattelan <cattelan@xxxxxxxxxxx>
Subject: Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes
From: Mark Goodwin <markgw@xxxxxxx>
Date: Thu, 24 Jul 2008 16:02:42 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <48875040.9090400@xxxxxxxxxxx>
Organization: SGI Engineering
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> <48875040.9090400@xxxxxxxxxxx>
Reply-to: markgw@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Windows/20080421)

Russell Cattelan wrote:
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)

yes. But it's git -> ptools scripts that we need, preserving history, etc.
Niv has some scripts for this - they're not production quality yet, but
we're getting there. Once this transitions, it'll be a *lot* easier for
us to pull in patches from external developer branches because we'll all
be using git for checkin.

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

once our internal dev tree is git based and internal git->ptools merging
is fully automatic, there is no actual need to shutdown the cvs crons.
It's worked for years and can stay running, no harm.

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

I think we'd just end up with a git dev branch on oss, maybe with a
daily pull from the internal dev tree (Russell, that would render
your cvs->git mirror obsolete I guess). In any case, patch flow and
turn-around should be greatly improved.

Anyone have comments on any of the above?

-- Mark

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