Should you be a Linux kernel maintainer?

Yesterday I was teased :)

Okay. Not really. I was merely pulled from leg by a friend of mine. It's strange to say a 'friend' for someone you have never met. Still, I feel like he is a friend, after having a numerous chats with him. I've received advices, suggestions, support and plenty of good laughs. So many jokes and observations on a field of technology we both share a passion for. That is the power of the community work. You meet people all around the world - even if you may not meet them ;)

It was a regular(ish) day at work. I was gathering more information for a new Linux driver project. I had a good chat in IRC, learning a lot from the experiences of others who had done something similar to what I am about to start. But as anyone who has used IRC - AND visited northern Finland at autumn - is likely to know: Staying focused in IRC is like bicycling on a slippery icy streets at my age, it’s only a matter of minutes until you fall. You start discussing a critical technical detail and after a while find yourself engaged in a discussion of how the height of the saddle of your bike impacts to taxation rates in <apply your local settings for inserting a name of a distant place here>.

And again, it did not take a big hit to get sidetracked. It was loosely something like:

<me> ...I think someone here has experience on this type of project...

<chatter 1> … our first attempt ended up maintainer to …

<chatter 2> link to a floor maintainer product

<chatter 3> link to a commit one asking for being removed from a maintainer position

<me> I have not added myself as a maintainer for component’s I’ve authored

An anonymous, long-term kernel and u-Boot developer hit me with a thought provoking statement:

"mvaittin: to toss the code over the fence and run, and let all the others take the maintenance burden for you?"

I knew this was just a friendly challenge but it demanded me to respond. I sure as heck don’t toss over code and run. I’ve never voluntarily done that. I have authored a few pieces of code in the Linux kernel – and for sure I have introduced a few bugs too. I guess that is inevitable when you are developing something new. What I have done in order to not ‘toss over the code and run’ includes:

• Adding myself as a reviewer for components I’ve authored.
• Subscribing to relevant mailing lists and adding email filters to trigger when component I’ve authored gets mentioned in mail.
• Creating automated test framework which runs a few tests (using real hardware) for the new tags in linux-next, as well as tests for new releases in torvald’s tree.
• Actually trying to act on the triggers from above bullets.

The first two bullets are intended to provide me a notification when someone changes (or finds a bug from) the code I have authored. When this happens I do review the change or try to help spotting and fixing the problem (whether it eventually is in my code or not). The third bullet is intended to help spotting problems that may be introduced or surfaced by changes in the other areas of the kernel.

It takes persistence to be able to contribute in kernel components. It takes even more persistence to tease developers. :) So as can be expected I was pushed further.

“mvaittin: yup, offloading the work you don't like onto others :)”

and

“mvaittin: so many excuses to not help the precious upstream and let the poor maintainers suffer from overload”

I did dodge and jump, I did everything I could to evade these suggestions. The truth being I do dislike patch integration and messing with the git branches and dependencies. So yes, partially I do offload work I don't like - and hope to continue doing so :) Well, I even played the infamous ‘I would be lousy on that job’ -card.

"XXXX: I won't run. I am still here, and listed as a reviewer. But I'd do a poor job as maintainer. I'm not any kind of gate-keeper and I tend to create terrible mess with git.."

By the way, git is incredibly powerful tool - but it is also incredibly easy to mess things. Especially when you are maintaining a public tree and which to keep the history working for other users. In private use you can always take the approach explained by XKCD author here: git in xkcd ;)

At some point of the chatting I was even suggested to co-maintaining an entire subsystem.

“mvaittin: you could become a co-maintainer for example, I'm sure both XXX and YYY could use one”

Finally the chatter ended up with:

“mvaittin: go for it, become a maintainer working with people is a lot of fun”

...which finally shows how serious the discussion was ;) Well, many people at the kernel development are fun and sharp to chat with - but working with the people can unfortunately be far from fun at times. There are always clashes and taking criticism can be hard, giving it requires skills - and eventually someone is going to be very upset.

Yeah, as I said, the fellow kernel developers were probably just teasing me. Maybe they did not seriously expect me to start as a maintainer. Still that actually made me to think what would happen if I did become a maintainer. So, let’s play with this thought a bit.

I could ask to be maintaining the ROHM PMIC drivers I have authored, and possibly few other minor contributions. So, let’s further assume I did switch myself from being a reviewer to being a maintainer in the MAINTAINERS file, created a patch out of this and tossed it to the relevant subsystem maintainers. That would be at least maintainers of the MFD, clk, regulators, watchdog, power-supply, GPIO and RTC subsystems. Potentially also some others if I wished to also maintain the linear_ranges or co-maintain the regmap-irq or regulator_irq_helpers extensions (although the latter two are maintained by Mark who maintains the regulators).

I don’t think such a patch would ever go through. Subsystem maintainers are clever people. They probably saw the shortcomings I described in IRC. But for the sake of it - let’s further assume that the patch went in mainline and I really was listed as a maintainer. What next?

Well, in order to really maintain code, I would need to kick up a git repository which should closely follow the upstream kernel development cycles. Well, actually, it would probably not be required to follow so closely as the ROHM drivers and my other contributions are rarely updated. Next I should stay aware of the changes to stuff I maintain (exactly as I do now as I am a reviewer). I should also review the changes (exactly as I do now as I am a reviewer). Then I should apply the changes to my git tree (which I occasionally do now as I am a reviewer and sometimes reviewing requires a proper context) – and make this public. Then I should send a pull-request to the relevant subsystem maintainers – who would pull the changes from my tree – instead of getting the patches directly from original author.

My question is – who would this benefit? I have a feeling it would not benefit the subsystem maintainers. In the end of the day these maintainers would still need to pick up the changes – and as bad as I am with the doing accurate and steady work with the git – they might grow a few gray hairs more just because the errors I’ve done… The subsystem maintainers would also still need to review and acknowledge the changes, I don’t expect them to trust my review only. And if they do, then they can trust it even if my title in maintainers is just a reviewer.

How about the poor patch author? I am afraid he would not see the benefit either. I guess that me working as a ‘man in the middle’ would just show up as an additional step causing additional delay.

Me? Maybe. I probably had a chance to make all the mistakes with the git branches, merges and pull-requests. That would for sure learn me a thing or two. I would also have a really cool line on my linkedIn page saying I am a Linux kernel (driver) maintainer. How cool does that sound?

But as I see it, the only benefit from me being a maintainer would be coming for me. So my friends, a counter question to you (one which I did not have the time to formulate in IRC)

“Wouldn’t me being a maintainer be just plain selfish?”

I know there are plenty of maintainers in the MAINTAINERS file. Many of who are probably doing invaluable work, being trusted and helping others. I don’t really think kernel development could work out without multiple maintainers – but I wonder if adding a new one is always a good thing or if all the maintainers really should be maintainers? For me it looks like the Reviewer option is there for a reason.

Edit: I received an important note from a Geert in the comments of this article: And 'ack' from a maintainer allows upstream maintainer to just take in the acked patches and trust they are Ok. When problems emerge it is the downstream maintainer who is sacraficed to calm the Gods :) Reviewers are better protected against that ;) Additionally, not all maintainers do host their own git - which indeed makes it more appealing for me too. So yes, if you are ready to take the full responsibility of your ack, then you probably should be a maintainer. It still remains partially the same. You've got to ask yourself one question: 'Do I feel competent enough?' Well, do you, punk?