Reducing kernel-maintainer burnout

This is also one of my major pain points with web-based UIs *for reviews*. They are all terrible compared to real text editors.

When discussing e-mail vs. web-based UIs, two separate discussions seem to always be mixed together. I believe the vast majority of developers, including kernel developers and maintainers, don't claim that mail clients are good for *tracking* the status of patches. That why we have patchwork and other similar tools, and git forges do a reasonable job there too compared to mail clients. When it comes to *reviewing* code, however, web-based UIs are just terrible.

> it's not surprising to see the abysmal quality of commit messages on projects mostly developed through browsers like many of those hosted on github/gitlab for example

I'm appalled that after so many years neither github nor gitlab has implemented the ability to comment on a commit message. I agree this is likely one of the factors that explain why so many projects have terrible commit message hygiene. Surely this can't be that complex to implement compared to the zillions of features that those forges provide, which makes me wonder if they have consciously decided not to provide the feature, have never tried their own dog good, or if github/gitlab are also developed with bad commit message hygiene.

I still maintan a number of open source software projects these days within the osmocom (open source mobile communications) project. Given my kernel background, we've originally started with a email + patch based system in 2008, added patchwork slightly later and have migated over to gerrit a number of years ago.

I have to say to me as a maintainer, reviewing and processing patches in gerrit is making my life much easier than an e-mail based workflow. Don't get me wrong, I am an e-mail person, I dislike GUIs, work all day on command line interfaces and I do read/write my e-mail in mutt. But still, gerrit is in my opinion a big benefit for the maintainer, unlike it was claimed earlier that it is a benefit for the patch submitter. I'd actually argue the other way around: For a random developer it's much easier to send a patch by e-mail than to install the git hooks for inserting the Change-ID and learning how to push stuff to gerrit.

I also don't get the comments made about "comments not being in-line with the code" or "linear comments". In gerrit, you are placing your comments right at the specific line[s] of code that you are commenting on, and the entire thread of comments is attached to that line of code.

I think a lot of the opinions against code review tools comes from the fact that most people have only seen github/gitlab/gitea style pull requests, which I as a maintainer consider a significantly inferiror tool the way how gerrit works. Gerrit doesn't know "pull requests", it knows individual patches. It tracks a single patch over any number of revisions. It can show you easily not just the current version of the patch, but the changes compared to any of the previous versions of it. It keeps code review at the specific location within the code. It allows you to track if a given comment raised in review is considered resolved or not. It warns you if you try to apply a patch that still has unresolved comments, etc.

For people who want to review / comment from the command line, there's a command line tool called "gerrit review" (see https://gerrit-documentation.storage.googleapis.com/Documentation/2.8/cmd-review.html) so you don't have to open your browser if you don't want to. I'm personaly not using it, but several of the osmocom developers do use it.

Github PRs exist as branches you can pull, which makes applying them to a tree very easy. The branch is named right at the top of the PR! On the other hand, it is not obvious how to apply patches from a pile of email messages to a tree, although I take your word for it that those "in the know" have some way to do it.

Likewise, most people's email clients make very poor code editors, but I take your word for it that those "in the know" have all developed email-based workflows that do incorporate good code editors for when you want to include code in review comments.

It makes sense to prioritize maintainer needs over contributor needs in a project like the kernel, where many people *have* to contribute to the kernel to get their work done so there's little downside to making that process arbitrarily difficult to get started with. And therefore it makes sense that you would never want to change processes that all the maintainers already know. But the gap between what most people use and how the kernel process works keeps growing.

Well you first have to become a contributor prior to becoming a maintainer, which is often the path which existing maintainers use to evaluate contributors and then later if approved offer/ack them as fellow maintainers right so my question to you is...

During your career as a kernel maintainer how many contributors have you approached and asked if they want to become a maintainer? When doing so what did you use as an incentive for that person to become a maintainer and what was the contributors response to that?

The thing is either existing maintainers aren't reaching out to prospects and offer them to become maintainers or existing contributors see no value in becoming maintainers in the first place.

If there is no value in the role of a maintainer then that role is effectively becoming obsolete ( some sort of structural change is needed ).

Have you considered finding an external editor plugin for your browser? I'm fairly sure they're available for most browsers, and generally let you right-click on a textarea and send it to an editor... and then replace the existing text when you save from the editor.