From: Luis Chamberlain <mcgrof@kernel.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: ksummit@lists.linux.dev, Jeff Layton <jlayton@kernel.org>,
Song Liu <song@kernel.org>
Subject: Re: [MAINTAINERS SUMMIT] Maintainer burnout
Date: Wed, 16 Aug 2023 13:14:46 -0700 [thread overview]
Message-ID: <ZN0uNrpD8JUtihQE@bombadil.infradead.org> (raw)
In-Reply-To: <20230816180808.GB2919664@perftesting>
On Wed, Aug 16, 2023 at 02:08:08PM -0400, Josef Bacik wrote:
> 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.
<-- snip -->
> 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,
I have been thinking about *many* of these things *for years*, but also *doing*.
In the *doing* part at the last LSFMM this year I described challenges I have
faced in this *doing*, but I think it is useful to itemize a few of them
so they are reminders:
a) hardware resources
b) push button people / reporting / etc
Today a) is resolved typically by either companies interested and
keeping things private (legal or whatnot) or sharing hardware resources
with community members (Samsung has let me share a big baremetal server
for community testing), and lately we also now have Oracle offering OCI
instances. I have *yet* to hear back from any other cloud provider.
The economic downturn makes a) harder today, whereas a few years before
I was hinted this was *not* a problem. And so we must take anything we
can get for it.
Jeff Layton has also hinted that developers tend prefer for resources to
be independent of just one company, ie, we can't just have one sole
provider. I believe this is the right approach. Loosing my test rig
after I switched an employer once made upkeeping XFS stable backporting
work just not possible long ago and, fortunately, today we have a team of
good folks with hw resources from 3 different companies to succeed. This
wasn't planned. It just happened.
So to help with automation to help with the burnout, there is a "meta"
aspect of a) then: proactive planning to get enough public resources for
community developers to step up to help, whether that be to backport /
test stable fixes, or resources for future automation of tests.
If your subsystem is not ready to discuss a) yet, that likely might be
because different companies / folks use different things to test subsystems /
regressions / new patches. And there in lies another "meta" issue.
In the *worst* case there are simply no tests, *or* maintainers suggesting
there is no way to automate *cough*.
There are also those that believe testing is super awesome, but seem to
shy away from the idea that our community is not ready for *requiring*
tests for kernel development / new patches / features / etc. IMHO evidence
of burnouts is a strong suggestion we should *strive* for it. The issue
is that typically this last part is an afterthought in the worst case,
and even with best intentions, can sometimes be a resource constrain
whether that be physical hardware or the b) part mentioned above.
What does this tell us, if we care about this? *If* automation is to be
a serious consideration it *must* be just as good as the kernel code we
write. And so I think it would help for those that *do* care about this
to start thinking about all these things proactively in this sense.
As for b) feedback from LSFMM was let's just automate it too. While
sensible, without resource consideration its a slow steep slope. But
I think we're getting better at that with time. Not only do we need
to think about writing test coverage but also the other parts of b).
In so far as making it possible to get b) to help, my current excitement
surrounds around what Song Liu mentioned to me at LSFMM and then
quickly demonstrated that the eBPF folks are doing with patchwork.
Get the patches to be tested automatically, and *immediately*
patch reviewers and maintainers can get feedback if something is not even
worth reviewing.
There are some other R&D type of ideas out there I have shared with some
peers and some have shared with me too, which could probably help long
term too, but one step at a time.
To help with b) my goal was to leverage and learn what eBPF folks have
done, allow kdevops to use it, and then start integrating with patchwork
for either the stuff I maintain or for the subsystems that are
interested in leverating the automation framework behind kdevops.
A boring but perhaps fitting way to think about what we do is to start
thinking about what we do with kernel development as a public utlity and
service and we just need to automate testing of this public utility.
I'd be very interested in talking about this if invited but my current
flight departs in the afternoon, but I could perhaps see to fly the next day if
this topic is chosen / I get an invite.
Luis
next prev parent reply other threads:[~2023-08-16 20:14 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-16 18:08 [MAINTAINERS SUMMIT] Maintainer burnout Josef Bacik
2023-08-16 20:14 ` Luis Chamberlain [this message]
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=ZN0uNrpD8JUtihQE@bombadil.infradead.org \
--to=mcgrof@kernel.org \
--cc=jlayton@kernel.org \
--cc=josef@toxicpanda.com \
--cc=ksummit@lists.linux.dev \
--cc=song@kernel.org \
/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).