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/ ) It seems like the XFS development community might benefit from a group maintainer model.
