[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: Fri, 25 Jul 2008 00:40:38 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <488951A1.9000408@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> <48875040.9090400@xxxxxxxxxxx> <48881B02.20900@xxxxxxx> <48894ECC.1070609@xxxxxxxxxxx> <488951A1.9000408@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20070728)
Mark Goodwin wrote:

Russell Cattelan wrote:
Personally I don't see a reason to keep a ptools tree in lock step with
with a git tree. ...

you might not, but you're not working for SGI anymore :)
We have loads of other trees to merge stuff into other than
those on oss.
Ya I'm familiar with the complexity disguising itself as productivity.
(But I will say I experienced a much worse complexity for the sake of
complexity situation)
Many of the internal scripts for managing this
are very intertwined with ptools. The one thing that will
really help with handling externally contributed patches is
for the primary internal SGI dev tree to become GIT based.
But not having git->ptools auto merge is not an option.
Actually if auto merge is a requirement I don't really see a shift in
policy. I don't see much difference in a ptool->git vs a git->ptools process.

Just because git is the birthing repo for changes, it seems like that is just
drawing more process into things and making change adoption
just as slow if not slower.

It seems like decoupling the process, not just switching SCM's and allowing
experimental changes to come to light sooner is what people are looking for.

PCP is in the same boat, just ask Nathan :)

Looking at this next week ...

-- Mark

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