[Top] [All Lists]

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

To: Nathan Scott <nscott@xxxxxxxxxx>
Subject: Re: [PATCH 00/20] xfs-cmds staging tree
From: Mark Goodwin <markgw@xxxxxxx>
Date: Mon, 29 Dec 2008 16:26:08 +1100
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <1229986947.4662.13.camel@xxxxxxxxxxxxxxxxxx>
Organization: SGI Engineering
References: <20081222163831.755809000@xxxxxxxxxxxxxxxxxxxxxx> <494FF9B3.9030103@xxxxxxx> <20081222204956.GA23453@xxxxxxxxxxxxx> <495010A2.2030903@xxxxxxx> <20081222221613.GA7128@xxxxxxxxxxxxx> <1229986947.4662.13.camel@xxxxxxxxxxxxxxxxxx>
Reply-to: markgw@xxxxxxx
User-agent: Thunderbird (Windows/20081105)

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:
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?

-- Mark

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