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@xxxxxxxxxxxxx
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
