[Top] [All Lists]

Re: [ANNOUNCE, DISCUSS] xfsprogs: libxfs-4.1-update branch created

To: Brian Foster <bfoster@xxxxxxxxxx>, Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [ANNOUNCE, DISCUSS] xfsprogs: libxfs-4.1-update branch created
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Mon, 11 May 2015 09:50:09 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20150511123917.GA43723@xxxxxxxxxxxxxxx>
References: <20150511000508.GD16689@dastard> <20150511123917.GA43723@xxxxxxxxxxxxxxx>
On 5/11/15 7:39 AM, Brian Foster wrote:


> What's the proposition with regard to submission/review process? I don't
> think we necessarily need the userspace bits until there is some review
> feedback on the kernel bits because that just increases development and
> review overhead (though nothing precludes posting both, of course). Also
> (and I think we discussed this briefly at LSF), I assume it is
> reasonable to condense a kernel patch series to a single userspace "sync
> XYZ feature to xfsprogs" patch for the bits that port directly over,
> since we have the kernel git log for finer grained history..? Case in
> point: I could squash the sparse inode kernel patches into a single
> xfsprogs patch. The functional xfsprogs bits on top of that (e.g., mkfs,
> repair, etc.) would of course remain as independent patches that require
> indepenent review.

I'd prefer fine-grained, myself; that way, going forward, we can have a
more or less 1:1 commit history.  With libxfs in userspace up to date,
it should be pretty easy, if not even scriptable, and I think the minimal
extra time needed to keep the fine-grained history around would be useful.


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