Re: [Lsf-pc] [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale

["Darrick J. Wong" <darrick.wong@oracle.com>]

On Fri, Jan 31, 2020 at 09:30:02AM +0200, Amir Goldstein wrote:
> On Fri, Jan 31, 2020 at 7:25 AM Darrick J. Wong <darrick.wong@oracle.com> wrote:
> >
> > Hi everyone,
> >
> > I would like to discuss how to improve the process of shepherding code
> > into the kernel to make it more enjoyable for maintainers, reviewers,
> > and code authors.  Here is a brief summary of how we got here:
> >
> > Years ago, XFS had one maintainer tending to all four key git repos
> > (kernel, userspace, documentation, testing).  Like most subsystems, the
> > maintainer did a lot of review and porting code between the kernel and
> > userspace, though with help from others.
> >
> > It turns out that this didn't scale very well, so we split the
> > responsibilities into three maintainers.  Like most subsystems, the
> > maintainers still did a lot of review and porting work, though with help
> > from others.
> >
> > It turns out that this system doesn't scale very well either.  Even with
> > three maintainers sharing access to the git trees and working together
> > to get reviews done, mailing list traffic has been trending upwards for
> > years, and we still can't keep up.  I fear that many maintainers are
> > burning out.  For XFS, the biggest pain point (AFAICT) is not assembly and
> > testing of the git trees, but keeping up with the mail and the reviews.
> >
> > So what do we do about this?  I think we (the XFS project, anyway)
> > should increase the amount of organizing in our review process.  For
> > large patchsets, I would like to improve informal communication about
> > who the author might like to have conduct a review, who might be
> > interested in conducting a review, estimates of how much time a reviewer
> > has to spend on a patchset, and of course, feedback about how it went.
> > This of course is to lay the groundwork for making a case to our bosses
> > for growing our community, allocating time for reviews and for growing
> > our skills as reviewers.
> >
> 
> Interesting.
> 
> Eryu usually posts a weekly status of xfstests review queue, often with
> a call for reviewers, sometimes with specific patch series mentioned.
> That helps me as a developer to monitor the status of my own work
> and it helps me as a reviewer to put the efforts where the maintainer
> needs me the most.

I wasn't aware of that, I'll ask him to put me on the list.

> For xfs kernel patches, I can represent the voice of "new blood".
> Getting new people to join the review effort is quite a hard barrier.
> I have taken a few stabs at doing review for xfs patch series over the
> year, but it mostly ends up feeling like it helped me (get to know xfs code
> better) more than it helped the maintainer, because the chances of a
> new reviewer to catch meaningful bugs are very low and if another reviewer
> is going to go over the same patch series, the chances of new reviewer to
> catch bugs that novice reviewer will not catch are extremely low.

Probably not, I miss small things too. :)

Especially if one has to twist through a bunch of different functions to
figure out if there's really a bug there.

> However, there are quite a few cleanup and refactoring patch series,
> especially on the xfs list, where a review from an "outsider" could still
> be of value to the xfs community. OTOH, for xfs maintainer, those are
> the easy patches to review, so is there a gain in offloading those reviews?

Yes, because there's still a ton of things I suck at -- running sparse
and smatch on the git trees, figuring out how a given patch will affect
xfsprogs, etc.

> Bottom line - a report of the subsystem review queue status, call for
> reviewers and highlighting specific areas in need of review is a good idea.
> Developers responding to that report publicly with availability for review,
> intention and expected time frame for taking on a review would be helpful
> for both maintainers and potential reviewers.

<nod>

--D

> Thanks,
> Amir.
> 
> > ---
> >
> > I want to spend the time between right now and whenever this discussion
> > happens to make a list of everything that works and that could be made
> > better about our development process.
> >
> > I want to spend five minutes at the start of the discussion to
> > acknowledge everyone's feelings around that list that we will have
> > compiled.
> >
> > Then I want to spend the rest of the session breaking up the problems
> > into small enough pieces to solve, discussing solutions to those
> > problems, and (ideally) pushing towards a consensus on what series of
> > small adjustments we can make to arrive at something that works better
> > for everyone.
> >
> > --D
> > _______________________________________________
> > Lsf-pc mailing list
> > Lsf-pc@lists.linux-foundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc