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@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. 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@xxxxxxxxxxxxxxxxxxxxxxxxxx > > https://lists.linuxfoundation.org/mailman/listinfo/lsf-pc
