[DISCUSS] Planning for new dev cycle (3.17)

[Dave Chinner <david@fromorbit.com>]

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

Hi everyone,

Now that the 3.16 dev cycle has drawn to a close (one more
linux-next build and I'll tag for-next and send a pull request),
it's time to look ahead for the next couple of months. I think the
current major pieces of work that are currently outstanding are
these:

	- Jeff's bulkstat rework
	- Brian's EOF prealloc scanning
	- Namjae's FALLOC_FL_INSERT_RANGE work
	- Eric's XFS_ERROR() macro removal and return () cleanup.

There's also two major pieces of infrastructure work I'd like to get
done:

	- convert XFS to negative error returns
	- restructure code to have a fs/xfs/libxfs structure similar
	  to userspace

Because Eric's XFS_ERROR removal touches the entire codebase, as
does the negative error return and the libxfs restructuring, I'd
like to get these done first and base the rest of the dev cycle work
on top of that. Eric's patches just need a minor rebase and the
libxfs restructure needs some makefile rework and review and they
should be good to go.

The issue is the negative error number patchset, and how to handle
review and testing. The patchset is already 62 patches long and it
converts roughly half the code base. It'll take me another couple of
days to convert the rest of the code, and that will probably take
another 60 patches.

I understand that reviewing 100+ patches is going to be a pain, but
each patch currently averages about +/- 10 lines. The current
diffstat is:

	37 files changed, 723 insertions(+), 722 deletions(-)

And that will probably double, so it's still going to be a fair
amount of change.

So the big question is how do we handle the review side of things.
I think testing won't be a huge issue because of the time we have in
the cycle (a couple of months to the 3.17 merge, and then a couple
more months in the 3.17-rcX cycle) to find and catch regressions,
but I'd like to know what people think about the best way to review
this change will be.

I'm happy for people to say "no, we need to review it patch by
patch, so delay it for a cycle while we work through it", but I'm
also happy for a "apply it all and look at error sources and
inversion points for problems". The second is probably easier, as
there will be very few remaining inversion points (only embedded
errors in ioctl structures, I think) and all error sources should be
negated at their definition and hence any error value (E* values)
that are not defined as "-E*" is likely to be an mistake....

I'll be spending the next couple of days finishing this all off, so
once it is done I can focus on review and bug fixes for the rest of
the 3.17 dev cycle. That allows me to  concentrate on a xfsprogs
3.2.1 release, subsequent userspace libxfs resync with the new
kernel structure, and starting to work on some of the smart block
device concepts I've been talking about recently....

These are not concrete plans - just what I'd *like* to do in the
next couple of months. Reality is bound to mess up any plans I have,
so I figure I mays as well mess them up straight away....

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