On 1/31/20 12:30 AM, Amir Goldstein wrote:
On Fri, Jan 31, 2020 at 7:25 AM Darrick J. Wong <darrick.wong@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx
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=
