|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|
|References:||<firstname.lastname@example.org> <email@example.com> <20080722042829.GB27123@infradead.org> <20080722053019.GI6761@disturbed> <20080722072733.GA15376@infradead.org> <20080723000548.GG5947@disturbed> <488692FB.firstname.lastname@example.org> <email@example.com> <48881B02.firstname.lastname@example.org> <48894ECC.email@example.com> <488951A1.firstname.lastname@example.org>|
|User-agent:||Thunderbird 126.96.36.199 (Macintosh/20070728)|
Mark Goodwin wrote:
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)
Actually if auto merge is a requirement I don't really see a shift inMany 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.
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.
|<Prev in Thread]||Current Thread||[Next in Thread>|
|Previous by Date:||REOPEN 981498 - Revert remove mounpoint UUID code, Niv Sardi-Altivanik|
|Next by Date:||Re: TAKE 981498 - kill xfs_lock_dir_and_entry, Dave Chinner|
|Previous by Thread:||Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes, Mark Goodwin|
|Next by Thread:||Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes, Niv Sardi|
|Indexes:||[Date] [Thread] [Top] [All Lists]|