On Thu, 2023-10-26 at 08:10 -1000, Linus Torvalds wrote: > On Wed, 25 Oct 2023 at 17:13, Darrick J. Wong <djwong@xxxxxxxxxx> wrote: > > > > Similar to what we just did with XFS, I propose breaking up the iomap > > Maintainer role into pieces that are more manageable by a single person. > > As RM, all you'd have to do is integrate reviewed patches and pull > > requests into one of your work branches. That gives you final say over > > what goes in and how it goes in, instead of letting branches collide in > > for-next without warning. > > I _think_ what you are saying is that you'd like to avoid being both a > maintainer and a developer. > > Now, I'm probably hugely biased and going by personal experience, but > I do think that doing double duty is the worst of both worlds, and > pointlessly stressful. > > As a maintainer, you have to worry about the big picture (things like > release timing, even if it's just a "is this a fix for this release, > or should it get queued for the next one") but also code-related > things like "we have two different things going on, let's sort them > out separately". Christian had that kind of issue just a couple of > days ago with the btrfs tree. > > But then, as a developer, those are distractions and just add stress > and worry, and distract from whatever you're working on. As a > developer, the last thing you want to worry about is something else > than the actual technical issue you're trying to solve. > > And obviously, there's a lot of overlap. A maintainer needs to be > _able_ to be a developer just to make good choices. And the whole > "maintainer vs developer" doesn't have to be two different people, > somebody might shift from one to the other simply because maybe they > enjoy both roles. Just not at the same time, all the time, having both > things putting different stress on you. > > You can *kind* of see the difference in our git tree if you do > > git rev-list --count --author=XYZ --no-merges --since=1.year HEAD > > to see "code authorship" (aka developer), vs > > git rev-list --count --committer=XYZ --since=1.year HEAD > > which shows some kind of approximation of "maintainership". Obviously > there is overlap (potentially a lot of it) and the above isn't some > absolute thing, but you can see some patterns. > > I personally wish we had more people who are maintainers _without_ > having to worry too much about developing new code. One of the issues > that keeps coming up is that companies don't always seem to appreciate > maintainership (which is a bit strange - the same companies may then > _love_ appreciateing managers, which is something very different but > has some of the same flavour to it). > > And btw, I don't want to make that "I wish we had more maintainers" be > a value judgement. It's not that maintainers are somehow more > important than developers. I just think they are two fairly different > roles, and I think one person doing both puts unnecessary stress on > that person. > Personally, I wouldn't want to give up doing development work altogether. I don't mind doing some maintainership duties, and helping out other maintainers where I can, but maintainership takes a lot more time than most people realize. You're sort of obligated to review everything that comes across your plate. I know Trond and Anna have been successful alternating the handling of pull requests and linux-next. I think it makes a lot of sense to have maintainership teams, at least for larger subsystems. We sort of have them informally now, but maybe we should be aiming to have a group of people who are all nominally maintainers on larger subsystems. They can then rotate between themselves on some schedule (every year? or every 5 releases? Whatever works...). That provides some extra incentive for other team members to help out with reviews, and it may make it simpler for someone else to step in when the current maintainer needs to step away. It does rely on a high degree of trust between team members, but most of us seem to get along. -- Jeff Layton <jlayton@xxxxxxxxxx>
