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

From: Allison Collins <allison.henderson@oracle.com>
To: Amir Goldstein <amir73il@gmail.com>,
	"Darrick J. Wong" <darrick.wong@oracle.com>
Cc: lsf-pc@lists.linux-foundation.org,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	xfs <linux-xfs@vger.kernel.org>, Eryu Guan <guaneryu@gmail.com>,
	Eric Sandeen <sandeen@redhat.com>
Subject: Re: [Lsf-pc] [LSF/MM/BPF TOPIC] FS Maintainers Don't Scale
Date: Fri, 31 Jan 2020 20:20:37 -0700	[thread overview]
Message-ID: <8983ceaa-1fda-f9cc-73c9-8764d010d3e2@oracle.com> (raw)
In-Reply-To: <CAOQ4uxh=4DrH_dL3TULcFa+pGk0YhS=TobuGk_+Z0oRWvw63rg@mail.gmail.com>


On 1/31/20 12:30 AM, 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.
> 
> 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.
That sounds like a familiar experience.  Lots of times I'll start a 
review, but then someone else will finish it before I do, and catch more 
things along the way.  So I sort of feel like if it's not something I 
can get through quickly, then it's not a very good distribution of work 
effort and I should shift to something else. Most of the time, I'll 
study it until I feel like I understand what the person is trying to do, 
and I might catch stuff that appears like it may not align with that 
pursuit, but I don't necessarily feel I can deem it void of all 
unforeseen bugs.

> 
> 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?
> 
> 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.
I definitely think that would help delegate review efforts a little 
more.  That way it's clear what people are working on, and what still 
needs attention.

Allison
> 
> 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://urldefense.proofpoint.com/v2/url?u=https-3A__lists.linuxfoundation.org_mailman_listinfo_lsf-2Dpc&d=DwIBaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=LHZQ8fHvy6wDKXGTWcm97burZH5sQKHRDMaY1UthQxc&m=Ql7vKruZTArpiIL8k0b6mdoZIYyOEUFrtFysmO8BZl4&s=Se3_uV_gEF1-YsGVAlu6NVh1KqcEzWExsEy5PCH4BAM&e=