LWN: Comments on "Reducing kernel-maintainer burnout"

Reducing kernel-maintainer burnout

alx.manpages — Thu, 26 Dec 2024 12:00:41 +0000

> Save the email in question into a (local) mailblox, then git am -s mailbox_file_name and you are done.

Actually, you can optimize that a little bit:

In neomutt(1)/mutt(1), you can press '|' within a message to pipe it to a command, which can be 'git am -s'. So, when reviewing patches for a project, I cd(1) into the worktree where I apply patches from contributors, then read mail, and from mail directly `|git am -s`, omitting the "save" step. You can even do that with encrypted mail (with a configuration line to tell it to decrypt while piping).

I expect other MUAs should have similar abilities.

BTW, another advantage of email:

You can use PGP to sign and/or encrypt the email.

Reducing kernel-maintainer burnout

ceplm — Tue, 09 Jan 2024 22:48:56 +0000

https://youtu.be/L8OOzaqS37s

Reducing kernel-maintainer burnout

sammythesnake — Sun, 10 Dec 2023 11:01:07 +0000

What works well for one person is certainly a good thought to consider, sharing wisdom and experience is invaluable and we all have our own blind spots that can be illuminated by another's perspective.

On the other hand, what works for one person is certainly not guaranteed to work for another. I know I find being "off work" (in a very *very* different role (!)) takes really quite some effort and adaptation - I get bored of not having something to do! Perhaps that's the case for some maintainers (and people like rsidd)... I suspect that the nature of the maintainer role probably needs complete breaks from time to time to actually *feel* off the hook, though.

As a practical matter, there needs to be somebody who can take on some of the role during those breaks for things that can't wait for one reason or another, as well as making good calls about whether the break needs interrupting. Getting a proper break from the responsibility is somewhat undermined by having to worry about what's waiting upon return!

Reducing kernel-maintainer burnout

lacos — Wed, 06 Dec 2023 16:42:18 +0000

"textern" for firefox <https://github.com/jlebon/textern>.

"external editor revived" <https://github.com/Frederick888/external-editor-revived> and "toggle line wrap" <https://git.kiszka.org/togglelinewrap.git> for thunderbird.

Reducing kernel-maintainer burnout

Hattifnattar — Mon, 04 Dec 2023 14:02:22 +0000

I would hate to get a review that just said "this line is wrong" without giving any reason, or "this function can be made more efficient" without any suggestion. Do you expect me to read your mind?

And a reason or a suggestion often involve, surprise-surprise, code.

Reviewing is just a conversation on a specific topic. The topic being code, it's entirely reasonable that the conversation will include code fragments...

Reducing kernel-maintainer burnout

mchapman — Sat, 02 Dec 2023 09:22:29 +0000

I have been very happy with Textern.

Reducing kernel-maintainer burnout

jschrod — Sat, 02 Dec 2023 00:15:44 +0000

Could you please point me to a plug-in that does this for Firefox and Emacs?

I'm using Emacs server already, that part is covered.

I didn't find such a plug-in - but maybe my search foo is not good enough and I used the wrong search terms.

Reducing kernel-maintainer burnout

Cyberax — Fri, 01 Dec 2023 06:13:24 +0000

Yes, that's actually a pretty good solution. And it would work perfectly with something like VIM integration.

Reducing kernel-maintainer burnout

comex — Thu, 30 Nov 2023 21:35:55 +0000

Since we are talking about browser extensions, can’t you just use the native messaging API? In short, the user installs a JSON file into a specific directory containing an arbitrary path to an executable and the ID of a browser extension which is allowed to talk to it. The browser launches that binary, unsandboxed, and it can communicate with the extension over stdin/stdout. No local HTTP server needed. The main drawback is that for security reasons, the user has to install the JSON file themselves rather than having it be built into the browser extension. But that’s not a big deal.

https://developer.chrome.com/docs/extensions/mv3/nativeMe...

Reducing kernel-maintainer burnout

geert — Thu, 30 Nov 2023 16:51:03 +0000

Oh, sounds soo familiar...

Reducing kernel-maintainer burnout

andy_shev — Thu, 30 Nov 2023 16:04:15 +0000

Practical experience: When off (really off) for a full week, upstream or pending (via subsystems) got a handful of code that has a lot of room to improve. Then it becomes too much to comment or fix yourself ==> degrading quality of code in the upstream over the years.

Reducing kernel-maintainer burnout

farnz — Thu, 30 Nov 2023 11:48:31 +0000

I often find myself wanting to quickly confirm that a suggestion I have is workable before I make it - I'm not infallible, but I can quickly write a small amount of code (ignoring error checking, ripple effects outside the area I'm changing, good style etc) to see what my suggestion will do to the code I'm reviewing. If I like what I see, I'll make the suggestion, while if I see that it's actually obfuscating the code, I'll not suggest it.

Reducing kernel-maintainer burnout

nevets — Thu, 30 Nov 2023 00:48:14 +0000

Yes, the maintainers summit is basically just like any other business meeting. Things go off on tangents all the time. We highly appreciate Jon trying his best to jot down all the happenings that is going on. It is not easy at all.

Reducing kernel-maintainer burnout

viro — Wed, 29 Nov 2023 20:34:02 +0000

Alas, some of us just can't aspire to such heights of managerial Tao and feel an occasional urge to explain things, even at the expense of sullying the proper forms with actual details. Or believe that Lao Tzu had been taking the piss and those who take his teachings too seriously are utter wankers....

Reducing kernel-maintainer burnout

wtarreau — Wed, 29 Nov 2023 14:42:39 +0000

> Reviewing for me does not involve writing any code, the idea is to provide the submitter enough information to fix it themselves and resubmit.

It's often much more efficient (and friendly) to write "I think maybe a better approach could be something around this:" and give the start of an example, than "no, still not what I'm expecting, try again". Look at reviews done on LKML, a non-negligible number of them suggest code snippets to discuss around. This is particularly true for bug fixes, where it's often a tradeoff and multiple approaches need to be explorated. That's precisely one of the reasons some tools are quite bad at this, when they don't allow the reviewer to express what they're thinking about, and cause many round trips.

Reducing kernel-maintainer burnout

kleptog — Wed, 29 Nov 2023 12:26:59 +0000

> You start by suggesting something and you change your mind in the middle for something better, so you just want to s/foo/bar/g to replace all the variables prefixes.

I guess we mean different things by reviewing. Reviewing for me does not involve writing any code, the idea is to provide the submitter enough information to fix it themselves and resubmit.

Reducing kernel-maintainer burnout

sramkrishna — Tue, 28 Nov 2023 22:45:27 +0000

I've been thinking about burn out from the app ecosystem context - projects like GNOME also suffer from burn out. I've been thinking putting together a sustainability and community health team - where we are trying to figure out how we can help with how we can help with working on things that will reduce maintainer load, and create systems that will allow more volunteers to help and feel rewarded for it.

Also Ted Tso looks burned out in that photo. :)

Darrick needs to come for beers. :-)

Reducing kernel-maintainer burnout

mb — Tue, 28 Nov 2023 19:29:15 +0000

>the majority of young people are useless for mankind,
>but there are still enough bright people who may still do many great things.

Half of the population has an IQ less than 100.
Has always been like that.
You are just getting old and grumpy.

Reducing kernel-maintainer burnout

ghodgkins — Tue, 28 Nov 2023 19:01:58 +0000

Alternately, some adults just like to complain about kids being kids, and this is unrelated to geopolitics. For instance, consider this quote from an American in 1906:

"There is a great tendency among the children of today to rebel against restraint, not only that placed upon them by the will of the parent. But against any restraint or limitation of what they consider their rights [...] this fact has filled well minded people with great apprehensions for the future." - Rev Henry Hussmann

No "failing former hegemon state" or "irreversible decline" to see here. Despite Fr. Hussmann's great apprehensions, America made out alright in the 20th century. Indeed, by my math, the children he was complaining about here led America through a period of unprecedented prosperity, technological advancement, and hegemonic power post-WW2.

Reducing kernel-maintainer burnout

wtarreau — Tue, 28 Nov 2023 16:17:07 +0000

For the kernel, I remember about 4 of them over the last 25 years, with the last one being the freshest one in my memory. Each time it's being the same: may (lack of) availability was the bottleneck and I was hindering more than I was helping. For some time it's acceptable, but at one point when you're figuring the same contributor gets it right all the time and even corrects you because by lack of time you say rubish, it's time to offer them to become a co-maintainer or even the only maintainer. Last time it was clearly much welcome and helped a lot.

Accepting a co-maintainer is nice for everyone. Less stress for both, particularly for the person, knowing that you're still there for complicated stuff, and it allows that person to start to take some liberties they wouldn't otherwise have attempted to take. *this* factor is important because there is not a single way to do things, and your way might have been good in the past and no more suitable. A fresh mind can come with a different approach, and being a maintainer, feel a bit more legitimate (or at least feel like there's less risk their work gets rejected).

If I had to do it again, I would definitely do it. The most stressful for me is to know I'm on a critical path and slowing someone else down. This is negative participation and is not acceptable. Sometimes it's better to have other people with a bit less experience of certain points and more availability than just rely on experts that are never available. Then experts can say in the background and appear only when needed.

Reducing kernel-maintainer burnout

Cyberax — Tue, 28 Nov 2023 05:48:59 +0000

> Used to exist; these days it seems that chromium, at least, considers running an external program as a security hole.

Well, it kinda is.

Your only solution right now is to use a localhost-bound HTTP server, which is not such a bad idea. Chrome might also gain support for UNIX domain sockets, WHATWG has approved an RFC for it last year.

You also can try to create a fake service using Chrome debug API, but it's even _worse_.

Reducing kernel-maintainer burnout

viro — Mon, 27 Nov 2023 23:42:56 +0000

Used to exist; these days it seems that chromium, at least, considers running an external program as a security hole. The best I'd been able to find had been along the lines of "well, you can run a local httpd with something magical plugged into it", which is... considerably more fishy-looking wrt security.

If anyone could share pointers towards a working setup that would allow e.g. to launch an xterm with vi in it, the contents of the area copied there and copied back after you are done editing it, I would be really grateful.

Reducing kernel-maintainer burnout

pj — Mon, 27 Nov 2023 23:12:25 +0000

>Having to suggest code examples in text areas which do not even support vertical selection, indent, text replace etc, the difficulty to get the patch locally and apply it to a tree etc, all of this is totally deterring.

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.

Reducing kernel-maintainer burnout

wtarreau — Mon, 27 Nov 2023 18:43:00 +0000

> Why on earth would you want search/replace while entering a comment?

This question is funny! This happens to be all the time: just because your ideas develop as you review while you're commenting. You start by suggesting something and you change your mind in the middle for something better, so you just want to s/foo/bar/g to replace all the variables prefixes. And similarly, wanting to just indent a block to put an "if" clause around is super frequent when reviewing. All things that browsers make impossible to do without having to press space 100 times (since tab will get you out of the box and if you're unlucky you'll even press "Post" while touching the space bar). I, too, despise every single minute I type in a browser. These tools are entirely designed to make you consume contents, not produce them.

Reducing kernel-maintainer burnout

paulj — Mon, 27 Nov 2023 17:43:59 +0000

It would be good actually to define a standard for sharing a) code reviews b) bug reports for git projects, such that the data can be commited to the git repo (as notes, or in some other namespace). That could then allow a plethora of tooling to come along and build on it.

Like how 'ledger' format became a de facto standard for "plain text accounting".

Perhaps the git 'appraise' and 'bug' tools should be the basis for that?

Reducing kernel-maintainer burnout

paulj — Mon, 27 Nov 2023 17:40:24 +0000

I'd love to see a good distributed code review tool. Ideally one that can store its state in the git repo of the project itself (a branch [or set of] in a different namespace, or git notes itself). One with good CLI tooling and a web UI - ideally importers/exporters

The only example I know of is "git appraise" - https://github.com/google/git-appraise . Perhaps it's the only one cause it's good enough, and we all should get behind it?

In a similar vein, distributed bug tracking in git. "git bug" - https://github.com/MichaelMure/git-bug - seems one of the best developed tools in this space?

Reducing kernel-maintainer burnout

khim — Mon, 27 Nov 2023 16:30:58 +0000

I suspect that you both are right. Take a look on quote from Aristotle just above your message. People also like to boring earlier Socrates: The children now love luxury; they have bad manners, contempt for authority; they show disrespect for elders and love chatter in place of exercise.

I don't know why mb brought that quote but it makes me queasy: does he understand context for these quotes or not? Does he want to read and laugh “oh, yeah, wise people told the same thousands of years ago… humanity is still around, everything would be fine… just relax”. Or maybe he wants to support johannbg? It's really hard without him saying anything.

Let me remind you something. Both Socrates and, later, Aristotle lived in a failing former hegemon state: state that had rich history, which was, many years before, a full-blown hegemon of Ancient Greece… but was clearly past it's zenith of power and on the road of the irreversible decline!

Do they forget about that or just simply don't know? Note that Athen's greatest achievements in the philosophy and culture happened after that period which wouldn't have been possible if all young people were awful. Some were quite bright, indeed, but most of the great people in that period weren't born in Athens anymore.

I think what we are observing now is similar phenomena: Western Civilization is collapsing, the majority of young people are useless for mankind, but there are still enough bright people who may still do many great things.

Reducing kernel-maintainer burnout

Nikratio — Mon, 27 Nov 2023 15:02:00 +0000

This article reads like a very long list of "<foo> said think A, <bar> said unrelated thing B, <com> said unrelated thing C" over and over again, with no dialogues at all.

Not the fault of the writer if this was indeed how the session ran, but if so it must have been rather frustrating.

Reducing kernel-maintainer burnout

karim — Mon, 27 Nov 2023 13:01:51 +0000

I vehemently disagree with this. I work with a new cohort of 3-5 university-level interns every 4 months and they're all born after 2000. This picture you paint has no correlation to what I see. I see very bright people who are coming of age with different reference points than the ones I saw at their age. It's fascinating to see how they decode things and I find myself learning from them.

Reducing kernel-maintainer burnout

mfuzzey — Mon, 27 Nov 2023 12:43:20 +0000

I think people being paid to work on Linux is good. It allows those people to spend large blocks of time on it (that's very difficult for most people if it's not part of their job and they can only do odd bits on evenings and weekends) and spending large blocks of time is necessary for most things if you want to advance reasonably quickly.

But while most kernel developers are now paid Linux hasn't fallen into the trap of giving their employers too much technical say and becoming a corporate project. No manager of a kernel developper can say "I know it's half baked but merge it now beacuse marketing wants it" and Linux largely maintains the "it'll ship when it's ready" and "longterm maintability is important" mindsets that are missing in most commercial projects.

Companies paying kernel developpers do get some say in the "what" (ie if they're interested in some particular area of the kernel, say power management or networking, they can hire specialists in those areas and ask them to work on that rather than other parts of then kernel) but they don't get a say on the "how" (ie what implementation is acceptable, that lies with the maintainers and, ultimately, Linus).

Of course what works for Linux (by virtue of being a "commons" on which most higher level stuff is now built) probably doesn't work for a lot of other OSS projects which still struggle to find developpers.

Reducing kernel-maintainer burnout

farnz — Mon, 27 Nov 2023 12:19:21 +0000

FWIW, I use local branches for review all the time with web-based review systems like Gerrit and GitHub PRs. It's just convenient to have the full power of my local setup available for reviewing the code, looking at what things outside the change are doing (which in turn allows me to suggest helpful follow-ups). git makes it trivial to check out a branch or commit and look at it, to try out changes I'm going to suggest (complete with building and/or testing them).

And git worktree add makes it trivial to create a new working copy for the duration of one review, which I can then delete after I'm done.

Reducing kernel-maintainer burnout

taladar — Mon, 27 Nov 2023 11:56:12 +0000

I think the discussion in the article and here in the comments shows that there are various concerns about tooling and processes and for each of those people's opinions seem to vary wildly what the appropriate process and/or tool is.

Maybe there needs to be a systematic approach to this problem first, list all the requirements in a process- and tool-agnostic way first (e.g. "make sure contributions to the subsystem are free of obvious bugs, free of intentional security holes, match the coding style, are documented, have tests, use the new and not the deprecated API for x,...", "test integration of all contributions within the subsystem/with contributions to other subsystems/...", "see later who reviewed a particular contribution", "allow contributors to see if their contribution is making progress/needs a new revision/...") and then discuss appropriate options to achieve the goal via processes, tools, manually by a specific role or automation,...

The kernel has created new tools in the past, perhaps this or adapting existing tools more heavily than the typical user might be appropriate here again.

Reducing kernel-maintainer burnout

mb — Mon, 27 Nov 2023 11:03:47 +0000

They [Young People] have exalted notions, because they have not been humbled by life or learned its necessary limitations; moreover, their hopeful disposition makes them think themselves equal to great things -- and that means having exalted notions. They would always rather do noble deeds than useful ones: Their lives are regulated more by moral feeling than by reasoning -- all their mistakes are in the direction of doing things excessively and vehemently. They overdo everything -- they love too much, hate too much, and the same with everything else.
(Aristotle)

Reducing kernel-maintainer burnout

johannbg — Mon, 27 Nov 2023 10:22:33 +0000

Well there is one competitor and that competitor is called life and majority of individuals that are born around 2000 and later are useless for mankind, they dont know who they are, what they are or what they want out of life, expect everyone to cater to their every whims and everything to be delivered to them on silver platter while being glued to their phone all the time.

So if by some stroke of luck *any* employer in *any* field finds an employee born 2000 or later that can just think for itself, is not glued to the phone all the time and shows up on right time. That employer found a keeper.

That translates to in the F/OSS world, if he did not stumble to your project by accident, made a PR, he's a keeper.

The point being the need is there regardless if the kernel community admits needing it or not because that contributor pool is not growing bigger by any means, nor any smarter thus is nowhere near the expectation or standards existing maintainers have and expect.

Everyone is fighting for those contributors/people that have the smarts that finds it's way all the way down to the keyboard ( from head to hands ) because that resource is becoming scarce, fast...

Reducing kernel-maintainer burnout

fschrempf — Mon, 27 Nov 2023 10:13:01 +0000

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

GitLab being an open-source project one could argue that simply no one ever cared enough to step up and implement the feature. The same argument kernel maintainers would use for some kernel related feature requests. Looking at the 6-year-old issue at https://gitlab.com/gitlab-org/gitlab/-/issues/19691 it looks like there has been some interest over the years but not enough for someone to actually do the necessary work.

And yes, a lot of projects developed on GitLab/GitHub suffer from bad commit message hygiene which is a pity in most cases, but some project development workflows are designed a lot differently than the kernel one and don't even really allow (or care?) to have a clean Git history (e. g. due to a lot of merge commit and bot commit noise).

Reducing kernel-maintainer burnout

taladar — Mon, 27 Nov 2023 08:42:11 +0000

I think time off completely for at least a week, better two, is needed to get those constant job-related background thoughts to go away for a while.

Reducing kernel-maintainer burnout

roc — Mon, 27 Nov 2023 06:30:57 +0000

As far as I can tell, the kernel community doesn't feel a need to attract more contributors. And that seems right to me! Linux is dominant, so lots of people have to contribute to the kernel to get their job done, so there's no need to attract more.

If there was a genuine competitor that Linux had to compete with for contributors, things would be very different.

Reducing kernel-maintainer burnout

viro — Mon, 27 Nov 2023 05:08:04 +0000

Cut'n'paste of more than a screenful tends to be unpleasant, and there's whitespace/tab/etc. damage to deal with. It's all survivable, of course, but really unpleasant.

Reducing kernel-maintainer burnout

viro — Mon, 27 Nov 2023 04:58:48 +0000

git am is when you are sent patches over email; if you are given a branch + repo (in the same email) - use git pull.

If patches are trivial and don't need me to look outside of context diff, sure, I can reply directly to email. What's the benefit of web-based anything in that respect, anyway? For anything more involved I very much prefer to be able to do it in a real editor, where I can poke around the tree, etc. Can you do the same in browser? As in, something in the patch gets me to look for the places where this field of this structure is ever accessed, to verify that their locking is, indeed, sufficient. Or something like "their change seems to remove a bunch of calls of that primitive; how many are left afterwards? If there's none, this and that could've been done much simpler and cut down the complexity of patch series big way... <greps> Umm... only two callers left; let's look around and see if they can be massaged out of existence as a preliminary step - looks like that might be a serious win overall". Or writing an explanation that would be longer than a few lines, with e.g. pseudo-code snippets in it. Or any number of other things, really...

As for rebase failures - huh? If I don't know which version the series is based on, how the hell could I review it in the first place, not to mention pulling it in? If the patches do not apply, you ask the submitter what are they supposed to be against; if they can't tell that, you don't want to deal with the series anyway. Oh, and throwaway branches are not a problem to remove, you know...

Reducing kernel-maintainer burnout

rra — Sun, 26 Nov 2023 21:05:43 +0000

(I think this is a long-winded way of saying that I agree with your point, but I'm not 100% sure I understood your point correctly.)

There are approximately 100x more projects that I want to volunteer my time towards than I have available time. I suspect this is true of everyone who has the ability to volunteer time with no compensation, which is itself a tiny fraction of humanity. Free software and open source have expanded far beyond the scale that is supportable with volunteer labor without some sort of vast change to our surrounding societies that gives people far more leisure time.

The "it's a noble cause and people should volunteer their time for free to support it" model also looks very different when you're in your twenties than when you're in your forties or fifties, particularly if you have kids.

I don't think that original model can be fixed, absent some sort of hard-to-imagine change where we all only work four hours a week for our existing salaries. I don't think it *should* be fixed absent such a post-scarcity SF scenario. We need something new, or at least new to this type of work.

We have followed a path that has been followed by many other technologies and developments in history: something that was sustainable through the leisure activities of relatively rich people has now expanded into something large enough that it needs to be prioritized by society as a whole. That means people need to be supported by society in some way while they work on it (through salary or whatever other mechanism). The problem is not going to shrink in the future back to a scale supportable by leisure activity.