On Thu, Apr 07, 2022 at 03:40:08PM -0700, Alli wrote: > On Thu, 2022-04-07 at 15:49 +1000, Dave Chinner wrote: > > On Wed, Apr 06, 2022 at 08:11:06PM -0700, Darrick J. Wong wrote: > > > On Tue, Apr 05, 2022 at 12:03:12PM +1000, Dave Chinner wrote: > > > > Hi folks, > > > > > > > > I'd really like to try getting the merge bottlenecks we've had > > > > recently unstuck, so there are a few patchsets I want to try to > > > > get > > > > reviewed, tested and merged for 5.19. Hopefully not too many > > > > surprises will get in the way and so some planning to try to > > > > minimises surprised might be a good thing. Hence I want to have > > > > a > > > > rough plan for the work I'd like to acheive during this 5.19 > > > > cycle, > > > > and so that everyone has an idea of what needs to be done to > > > > (maybe) > > > > achieve those goals over the next few weeks. > > > > > > > > First of all, a rough timeline that I'm working with: > > > > > > > > 5.18-rc1: where we are now > > > > 5.18-rc2: Update linux-xfs master branch to 5.19-rc2 > > > > > > Presumably you meant 5.18-rc2 here? > > > > > > > 5.18-rc4: At least 2 of the major pending works merged > > > > 5.18-rc6: Last point for new work to be merged > > > > 5.18-rc6+: Bug fixes only will be merged > > > > > > > > I'm assuming a -rc7 kernel will be released, hence this rough > > > > timeline gives us 2 weeks of testing/stabilisation time before > > > > 5.19 > > > > merge window opens. > > > > > > > > Patchsets for review should be based on either 5.17.0 or the > > > > linux-xfs master branch once it has been updated to 5.19-rc2. If > > > > > > ...and here? > > > > Yes, I meant 5.18-rc2. > > > > > > - Logged attributes V28 (Allison) > > > > - I haven't looked at this since V24, so I'm not sure what > > > > the current status is. I will do that discovery later in > > > > the week. > > > > - Merge criteria and status: > > > > - review complete: Not sure > So far each patch in v29 has at least 2 rvbs I think OK. > > > > - no regressions when not enabled: v24 was OK > > > > - no major regressions when enabled: v24 had issues > > > > - Open questions: > > > > - not sure what review will uncover > > > > - don't know what problems testing will show > > > > - what other log fixes does it depend on? > If it goes on top of whiteouts, it will need some modifications to > follow the new log item changes that the whiteout set makes. > > Alternately, if the white out set goes in after the larp set, then it > will need to apply the new log item changes to xfs_attr_item.c as well I figured as much, thanks for confirming! > Looking forward, once we get the kernel patches worked out, we should > probably port the corresponding patches to xfsprogs before enabling the > feature. I have a patch to print the new log item in a dump. You mean for xfs_logprint? > It's not > very complicated though, I don't think it will take too many reviews to > get through though. *nod* > > > > - Intent Whiteouts V3 > > > > - Merge criteria and status: > > > > - review complete: 0% > I think patch 2 of this set is the same as patch 2 of the larp set. If > you agree with the review results, you can just take patch 2 from the > larp series, and have 2 rvbs for this one OK. I'll duplicate the rvbs so whichever gets merged first contains them. > > > > - No regressions in testing: 100% > > > > - Open questions: > > > > - will it get reviewed in time? > > > > - what bits of the patchset does LARP depend on? > Just from glancing at the sets, I don't think they have merge conflicts > other than patch 2, which can simply be dropped from one of the sets. > > However, patches 3,4,6,7 of the whiteout set make a series of changes > to the xfs_*_item.c files. So similar changes need to be applied to > the new fs/xfs/xfs_attr_item.c that the larp set introduces *nod* Thanks for the update, Allison. -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
