[PATCH 03/48] libxfs: add crc format changes to generic btrees

[Dave Chinner]

On Thu, Jul 25, 2013 at 12:15:09PM -0500, Ben Myers wrote:
> Dave,
> 
> On Thu, Jul 25, 2013 at 10:48:21AM +1000, Dave Chinner wrote:
> > On Tue, Jul 23, 2013 at 01:26:48PM -0500, Ben Myers wrote:
> > > On Fri, Jun 07, 2013 at 10:25:26AM +1000, Dave Chinner wrote:
> > > > From: Dave Chinner <dchinner at redhat.com>
> > > > 
> > > > Signed-off-by: Dave Chinner <dchinner at redhat.com>
> > > 
> > > This patch mostly corresponds to commit ee1a47ab0e, and in some areas it is
> > > equivalent but slightly different.  There are some other things in here too:
> > > 
> > > * Addition of XFS_BUF_DADDR_NULL
> > > * rename of b_blkno to b_bn in struct xfs_buf
> > > * rename of b_fsprivate to b_fspriv in struct xfs_buf
> > > * addition of uuid_copy and uuid_equal, and libuuid to build
> > > 
> > > It all looks fine to me, except as below:
> > 
> > I think you'll find they are fixed up in later patches in the
> > series.
> > 
> > Indeed, I think it's a little late to asking for these patches to be
> > changed, considering that making significant changes to these first
> > few patches will mean that I have to rebase a 100 or so subsequent
> > patches.
> 
> You are mistaken...

Mistaken about what, exactly? That a rebase will take days to do and
retest, while an additional patch will take minutes? 

I don't even have this series set up with guilt anymore - it's
been so long since it was committed to the crc-dev branch that I
moved over to working on that branch and adding patches on top of it
to fix issues. I've simply assumed that this patchset is fixed in
concrete and any problems will be layered on top.

People are already using this code, so we've already got a
significant amount of test exposure to it. Going back and modifying
and completely rebasing it invalidates all that test coverage.
Rebasing is not a risk-free operation, and when that is combined
with the amount of time needed for a rebase of such a series, I'd
much prefer that code that is in the crc-dev tree remains untouched
and we layer fixes on top of it...

> > For issues that aren't fixed in later patches, I'll add new patches
> > to the end of the current series to fix them.
> 
> ...but I have no objection to taking this approach, so long as my
> concerns are addressed.

Which, for this patch, have already been addressed in subsequent
patches....

Cheers,

Dave.
-- 
Dave Chinner
david at fromorbit.com