[Top] [All Lists]

Re: [PATCH 00/20] xfs-cmds staging tree

To: Mark Goodwin <markgw@xxxxxxx>
Subject: Re: [PATCH 00/20] xfs-cmds staging tree
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 29 Dec 2008 03:41:28 -0500
Cc: Nathan Scott <nscott@xxxxxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <49585F70.5090709@xxxxxxx>
References: <20081222163831.755809000@xxxxxxxxxxxxxxxxxxxxxx> <494FF9B3.9030103@xxxxxxx> <20081222204956.GA23453@xxxxxxxxxxxxx> <495010A2.2030903@xxxxxxx> <20081222221613.GA7128@xxxxxxxxxxxxx> <1229986947.4662.13.camel@xxxxxxxxxxxxxxxxxx> <49585F70.5090709@xxxxxxx>
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Dec 29, 2008 at 04:26:08PM +1100, Mark Goodwin wrote:
> If we split it, we only loose the top level GNUmakefile, but gain the
> potential for separate maintainership (or even group write if needed)
> for each of the sub-projects. SGI can manage git/ptools for this easily
> enough internally.
> So the proposal would be to set up:
> git://oss.sgi.com/xfs/{acl,attr,xfstests,xfsprogs,xfsdump,dmapi,xfsmisc}.git
> as bare repositories, each with a 'master' and 'stable' branch (initially
> identical) and merge from master to stable whenever we want to release
> (and also grab tarballs to preserve Barry's previous release process until
> such time as the distros catch on).
> Before I go and do this, note we already have Russell's ptools/cvs
> mirror at git://oss.sgi.com/xfs-cmds which has the advantage of some
> history. Would we want to keep any of that history? Since this already
> mirrors t-o-t ptools, I could just as easily take a clone of that as
> git://oss.sgi.com/xfs/xfs-cmds.git and be done with it. Opinions?

I've setup a few experimental trees:


which do import all the history from the public CVS tree.  Unlike the
git tree on oss.sgi.com it does this in a nicer way by hacking cvsps to
actually detect ptool changest properly insted of splitting them into
multiple git commits due to the different per-file comments, having a
mapping from sgi login IDs to proper real names and having a single
import instead of multiple import and their merges.

The only real problem with these is that the CVS tree hasn't been
updated since October (and I've missed a few names on my first round of

I think these should be used as a model for the future trees, we can
have these kernel.org trees for the community (current Eric, Dave and me
could commit to those about, and we should add Nathan and Andreas soon),
and then sgi can pull them into their trees for official releases or
product trees.

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