Hey Ric, On Wed, Jun 19, 2013 at 10:54:26AM -0400, Ric Wheeler wrote: > On 06/19/2013 10:44 AM, Christoph Hellwig wrote: > >On Wed, Jun 19, 2013 at 09:35:37AM -0500, Ben Myers wrote: > >>>On Wed, Jun 19, 2013 at 02:50:08PM +1000, Dave Chinner wrote: > >>>> >This is my patch queue for 3.11 as it stands right now. > >>> > >>>Getting all of this in for 3.11 does not strike me as being realistic. You > >>>need to think about how this can be split up. I see that you have rebased > >>>Jeff's log size validation patch set after your rearrangement. I'd rather > >>>you'd taken Jeff's series first and then made your changes. Now we can't pull > >>>in Jeff's work without pulling in a bunch of rearrangement that hasn't been > >>>fully discussed. You have also crowded out Chandra's quota work. We had an > >>>agreement with him to go for 3.11 with that work which you have broken. > > >I think 3.11 is a realistic target for all the code movearound, but > >maybe not as part of the normal pull request for -rc1. If we make sure > >it's really moving code around and not changing it I think a sending a > >second pull request to Linus saying this is just code movearounds we > >wanted to do when the churn causes least problems with actual code work > >he should be fine with it. > > Just to chime in here, we have a lot of resources focused on testing > these XFS updates both internally with our QA team and with a range > of other RH partners. This isn't about the size of your QA team or the number of other RH partners. We had an agreement with Chandra to work toward getting his quota work in 3.11 and it appears that Dave has crowded him out with a rearrangement of code which we had no agreement would go into 3.11. Further, Dave has taken Jeff's log size validation series hostage by rebasing it on top of this rearrangement of code. If there is a strategic reason that RH needs to have the kernel/libxfs code rearranged and separated in 3.11 I would have liked to have heard about it before now. I'm all for getting this work done, but not at the expense of crowding out other XFS contributors. -Ben _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
