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

[Dave Chinner <david@fromorbit.com>]

[-- Attachment #1.1: Type: text/plain, Size: 3370 bytes --]

Hi folks,

I' ve just added a branch to the xfsprogs repository on kernel.org
that is up to date with the current 4.1-rc2 kernel code. It's smoke
tested, so I don't think there's any major problems with it. Can
everyone with development patches (i.e. things that change on disk
formats) for xfsprogs please rebase their work against this branch,
retest and repost? This branch will end up being the 3.3 release
tree...

FWIW, now that I've done this update, I'm considered how we keep
this up to date in future. Keeping the userspace code up to date and
working with all the internal kernel API changes takes quite a bit
of effort and that currently is all being done by the Maintainer.
i.e. me. This is the reason that userspace is not updated
frequently.

With this update, libxfs in the kernel and userspace are mostly
identical, so I'm thinking that a new rule for XFS developers needs
to be put in place: if you modify a libxfs kernel API, then you need
to make the same change to userspace. This means all the changes
needed for xfs_repair, xfs_db, etc, need to be done as well, because
sometimes these things are non-trivial.

A good example of this is Christoph's xfs_trans_commit() patchset.
There's 42 xfs_trans_commit() calls in userspace and it has a
completely different implementation in userspace. To put that in
context, there are 61 xfs_trans_commit() in the kernel code. If I
merge that changeset into the kernel code, then Christoph walks away
and it has become the Maintainer's problem to make userspace work
with the API change.

This *sucks* from a maintainer's POV - - it simply does not scale.
This is one of the reasons why my productivity as an XFS developer
has cratered over the last year. This userspace update work needs to
be distributed over the developers making the API and functionality
changes, so I'm throwing this out there to see what people think
about solving this problem.

I'm thinking that we need a userspace dev branch similar to the
for-next branch for the kernel code, where we aggregate topic
branches that contain each set of userspace patches that add/change
functionality that is shared with the kernel. If the developer
hasn't done the work to update userspace and test the changes there,
then the change is incomplete.

Note that I'm only suggesting this for the main XFS developers
making internal API or on-disk format changes to XFS - the typical
drive-by patches and bug fixes from random people we commit to the
kernel code will still need the maintainer to push them across to
userspace.

This will make my life easier from both an update and maintenance
point of view, and will make it easier for us as developers to get
the latest dev code faster. It will also make porting kernel changes
over to userspace faster, as the patches will mostly apply cleanly
to the userspace libxfs code base. And if it gets merged quicker,
tehn we'll get better test coverage of the dev tree because we'll be
testing it sooner. And as developers, we won't have to be working
out what changed and needs forward porting from the kernel to
userspace to make stuff work....

So, what do the people I'm asking to do more work so I don't have
to spend so much time on time consuming maintenance tasks think?

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs