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.
Linus
