[PATCH 00/20] xfs-cmds staging tree

[Mark Goodwin]

Nathan Scott wrote:
> On Mon, 2008-12-22 at 17:16 -0500, Christoph Hellwig wrote:
>> On Tue, Dec 23, 2008 at 09:11:46AM +1100, Mark Goodwin wrote:
>>>> One thing we were discussing is if it's really a good idea to have all
>>>> these together.
>>> It would certainly help SGI if the directory structure for the proposed
>>> xfs-cmds tree remained the same as it is in ptools at the moment. I
>>> guess we could consider splitting each xfs-cmds directory into separate
>>> repositories, but then building it all togetheer would be a pain. It could
>>> certainly make sense to split off xfstests into it's own tree since it's
>>> not part of the xfs-cmds build.
>> Ok, sounds fair to keep it like that for now.
>
> Now seems like a good time to split it.  The distributions have to deal
> with it this way, and for the most part developers don't need to go and
> update acl/attr from the version shipped with their distro.  And now in
> xfsprogs-3.0 the exported headers are sorted out, the interface between
> the packages is much better defined ... if we don't break the link now,
> we probably never will - so I'd vote for separate trees for each self-
> contained package, personally.  Be good to allow agruen to directly be
> able to commit to acl/attr for example, as Christoph said.

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?

Cheers
-- Mark