On Mon, Feb 17, 2020 at 08:55:56AM +1100, Dave Chinner wrote: > On Thu, Feb 13, 2020 at 07:46:32AM -0800, Matthew Wilcox wrote: > > On Thu, Feb 13, 2020 at 10:11:00AM -0500, Brian Foster wrote: > > > With regard to the burnout thing, ISTM the core functionality of the > > > maintainer is to maintain the integrity of the subtree. That involves > > > things like enforcing development process (i.e., requiring r-b tags on > > > all patches to merge), but not necessarily being obligated to resolve > > > conflicts or to review every patch that comes through in detail, or > > > guarantee that everything sent to the list makes it into the next > > > release, etc. If certain things aren't being reviewed in time or making > > > progress and that somehow results in additional pressure on the > > > maintainer, ISTM that something is wrong there..? > > > > > > On a more logistical note, didn't we (XFS) discuss the idea of a > > > rotating maintainership at one point? I know Dave had dealt with burnout > > > after doing this job for quite some time, Darrick stepped in and it > > > sounds like he is now feeling it as well (and maybe Eric, having to hold > > > down the xfsprogs fort). I'm not maintainer nor do I really want to be, > > > but I'd be willing to contribute to maintainer like duties on a limited > > > basis if there's a need. For example, if we had a per-release rotation > > > of 3+ people willing to contribute, perhaps that could spread the pain > > > around sufficiently..? Just a thought, and of course not being a > > > maintainer I have no idea how realistic something like that might be.. > > > > Not being an XFS person, I don't want to impose anything, but have > > you read/seen Dan Vetter's talk on this subject? > > https://blog.ffwll.ch/2017/01/maintainers-dont-scale.html (plenty of > > links to follow, including particularly https://lwn.net/Articles/705228/ ) > > Yes, and I've talked to Dan in great detail about it over several > past LCAs... :) > > > It seems like the XFS development community might benefit from a > > group maintainer model. > > Yes, it may well do. The problem is the pool of XFS developers is > *much smaller* than the graphics subsystem and so a "group > maintainership" if kinda what we do already. I mean, I do have > commit rights to the XFS trees kernel.org, even though I'm not a > maintainer. I'm essentially the backup at this point - if someone > needs to take time off, I'll take over. > > I think the biggest barrier to maintaining the XFS tree is the > amount of integration testing that the maintainer does on the merged > tree. That's non-trivial, especially with how long it takes to run > fstests these days. If you're not set up to run QA 24x7 across a > bunch of different configs, then you need to get that into place > before being able to do the job of maintaining the XFS kernel > tree... > > If everyone had that capability and resources at their disposal, then > rotating the tree maintenance responsibilities would be much > easier... I kinda wish the LF or someone would open such a program to the kernel maintainers. I never liked that old maxim, "The maintainer is [the stuckee] with the most testing resources" -- there shouldn't really have to be a djwong cloud and a dchinner cloud. :/ --D > Cheers, > > Dave. > -- > Dave Chinner > david@xxxxxxxxxxxxx
