From: Wolfram Sang <wsa+renesas@sang-engineering.com>
To: Mark Brown <broonie@kernel.org>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Jiri Kosina <jikos@kernel.org>,
ksummit@lists.linux.dev
Subject: Re: [MAINTAINERS SUMMIT] Merge tree too flat?
Date: Fri, 14 Jun 2024 11:15:09 +0200 [thread overview]
Message-ID: <ia6eflrudxea7ndujrxytqcdvbv7kjwlcdnkel2hb5mdsboznt@edtpxkvf5xay> (raw)
In-Reply-To: <356ad539-3b37-4ada-8344-45ed938c02c5@sirena.org.uk>
[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]
> I don't think the mechanics of how patches get moved about has a huge
> impact on the effort involved
50:50, in my case.
> - trust and delegation make much more of a difference. I've got
> several areas where other people are reviewing large volumes of
> patches before I ever see them,
This is also true for me. When I called out for per-driver maintainers,
this made the flood of patches bearable. All of the driver maintainers
prefer to review only, though, and let me handle the rest. This is
totally fine with me. I'd likely lose some reviewers if I force to them
to provide me with separate branches.
The other part is: a few months ago Andi Shyti took over the maintenance
of the I2C controller patches. He updates patchwork, handles
dependencies, decides on for-current and for-next, writes pull
requests... That frees so much time that I have actually time left to
work on the core code again and give high-level guidance how to tackle
problems. So, this really helps as well.
That basically boils down to what I said last year at the Maintainer
Summit: In some parts of the Kernel, there is no flexibility to redesign
the hierarchy. The limited amount of people interested in maintaining
and their needs already shape the workflow. And for me, this is also the
primary reason why the merge-tree looks so flat.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-06-14 9:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-04 22:03 Jiri Kosina
2024-06-04 22:21 ` Steven Rostedt
2024-06-04 22:34 ` Jiri Kosina
2024-06-04 22:45 ` Steven Rostedt
2024-06-05 11:31 ` Mark Brown
2024-06-14 9:15 ` Wolfram Sang [this message]
2024-06-04 22:33 ` Sasha Levin
2024-06-04 22:38 ` Jiri Kosina
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=ia6eflrudxea7ndujrxytqcdvbv7kjwlcdnkel2hb5mdsboznt@edtpxkvf5xay \
--to=wsa+renesas@sang-engineering.com \
--cc=broonie@kernel.org \
--cc=jikos@kernel.org \
--cc=ksummit@lists.linux.dev \
--cc=rostedt@goodmis.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