Re: [5.19 cycle] Planning and goals

[Dave Chinner <david@fromorbit.com>]

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@fromorbit.com