From: Josef Bacik <josef@toxicpanda.com>
To: ksummit@lists.linux.dev
Subject: [MAINTAINERS SUMMIT] Maintainer burnout
Date: Wed, 16 Aug 2023 14:08:08 -0400 [thread overview]
Message-ID: <20230816180808.GB2919664@perftesting> (raw)
Hello,
This is a topic we're beating to death but haven't really made decent progress
on WRT real solutions. I know I have advocated for adding even more
responsibilties to maintainers plates, which isn't really helpful.
There is a lot in this email, so I suppose choose your own adventure when it
comes to what we think is relevant to discuss.
Maintainers/long time developers are burning out. At the same time there's
frustration from new comers who have trouble getting their patches accepted. We
have instances of arguments between longtime developers which leads to more
frustration because it drags on the development process.
I have argued for the last few years that maintainers should be taking a more
active role in the social side of our development process. Be the grownups in
the room and help mitigate these conflicts before they sour relationships.
But this just adds to the long list of things that maintainers already need to
do. Oftentimes they are the only reviewers, testers, and main developers rolled
into one. We have an increase of automated testing, which while is a net
positive, adds to the stress of maintainers who view these reports as their
personal responsibilty to address.
We all work differently, so having big sweeping solutions is a non-starter.
However I think there are things we can learn from eachother to encourage
different thinking and thus result in a smoother development experience for all
of us.
Patch review: Obviously more people the better, encouraging review by trading
reviews for having developers patches reviewed is a good method, but this only
works for sufficiently large communities.
Automated testing: This doesn't replace review, but it can help add confidence
when you're accepting patch reviews from less experienced members.
De-prioritize automated reports: Syzbot is great, but the failure cases can be
sporadic and difficult to reproduce. Things that are bisected to a specific
patch are obviously easy to tackle, but don't let yourself get overwhelmed by
syzbot, they're good things to hand to new developers to cut their teeth on.
Maintainer groups, not sole maintainers: We all have things going on, build up
people you trust and develop a way to spread the maintenance load.
Automate everything: I hate email, that is no secret, but even with email we can
automate a lot of things. The btrfs team built out the GH CI so developers can
drive their own testing, spreading the load. Eventually I hope to get to the
point where the merging of patches is automated away so we don't have to deal
with those mechanics.
Developing strategies to handle the more mundane tasks of managing our projects
will help free us to engage better with our communities, and guide people to be
better developers, feeding back into the ecosystem that will help reduce the
pain. Thanks,
Josef
next reply other threads:[~2023-08-16 18:08 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 18:08 Josef Bacik [this message]
2023-08-16 20:14 ` [MAINTAINERS SUMMIT] Maintainer burnout Luis Chamberlain
2023-08-17 9:39 ` Laurent Pinchart
2023-08-17 12:36 ` Andrew Lunn
2023-08-17 15:19 ` Jakub Kicinski
2023-08-17 23:54 ` Alexei Starovoitov
2023-08-18 13:55 ` Linus Walleij
2023-08-18 15:09 ` Jakub Kicinski
2023-08-18 17:07 ` Linus Torvalds
2023-08-19 6:45 ` Leon Romanovsky
2023-08-21 15:35 ` Laurent Pinchart
2023-08-22 7:41 ` Jiri Kosina
2023-08-22 9:05 ` Hannes Reinecke
2023-08-22 10:13 ` Leon Romanovsky
2023-08-22 11:25 ` Laurent Pinchart
2023-08-21 19:23 ` Vegard Nossum
2023-08-22 4:07 ` Dave Airlie
2023-08-22 9:46 ` Jan Kara
2023-08-22 10:10 ` Christian Brauner
2023-08-22 10:20 ` Jan Kara
2023-08-22 11:29 ` Laurent Pinchart
2023-08-22 11:05 ` Leon Romanovsky
2023-08-22 11:32 ` Laurent Pinchart
2023-08-22 13:47 ` Leon Romanovsky
2023-08-22 13:30 ` Jan Kara
2023-08-29 12:54 ` Steven Rostedt
2023-09-13 9:02 ` Dan Carpenter
2023-08-21 8:50 ` Daniel Vetter
2023-08-21 15:18 ` Jakub Kicinski
2023-08-22 4:12 ` Dave Airlie
2023-08-18 15:26 ` Laurent Pinchart
2023-08-18 15:40 ` Konrad Rzeszutek Wilk
2023-08-18 18:36 ` Mark Brown
2023-08-21 16:13 ` Laurent Pinchart
2023-08-18 16:10 ` Mark Brown
2023-08-21 16:04 ` Laurent Pinchart
2023-08-24 21:30 ` Jonathan Cameron
2023-08-25 7:05 ` Krzysztof Kozlowski
2023-08-17 12:00 ` Jani Nikula
2023-08-17 12:17 ` Mark Brown
2023-08-17 12:42 ` Laurent Pinchart
2023-08-17 13:56 ` Miguel Ojeda
2023-08-17 15:03 ` Laurent Pinchart
2023-08-17 17:41 ` Miguel Ojeda
2023-08-18 15:30 ` Laurent Pinchart
2023-08-18 16:23 ` Mark Brown
2023-08-18 17:17 ` Laurent Pinchart
2023-08-18 18:00 ` Mark Brown
2023-08-17 14:46 ` Mark Brown
2023-08-17 14:22 ` Steven Rostedt
2023-08-17 15:31 ` Jani Nikula
2023-08-17 14:46 ` Steven Rostedt
2023-08-17 15:33 ` Josef Bacik
2023-08-17 17:10 ` Rodrigo Vivi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230816180808.GB2919664@perftesting \
--to=josef@toxicpanda.com \
--cc=ksummit@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).