On 1/19/26 12:19 AM, Thomas Huth wrote:
On 16/01/2026 19.31, Pierrick Bouvier wrote:
On 1/15/26 11:17 PM, Thomas Huth wrote:
On 15/01/2026 21.35, Pierrick Bouvier wrote:
I would like to help maintaining qemu documentation and I've been
invited by Alex to apply as maintainer.
Files in docs/ that are already maintained will continue to be under
their respective maintainer. The goal here is to have someone that can
help on all other files that don't have an official maintainer.
Signed-off-by: Pierrick Bouvier <[email protected]>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4ddbfba9f01..786f3b3a456 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4505,6 +4505,11 @@ Incompatible changes
R: [email protected]
F: docs/about/deprecated.rst
+General Documentation
+M: Pierrick Bouvier <[email protected]>
+S: Maintained
+F: docs/
You might trigger a lot of traffic to your inbox that way ... but if you
don't mind:
Acked-by: Thomas Huth <[email protected]>
Reading about your answer, I was thinking it would be nice one day to
organize a BoF about everyone personal email workflow.
I feel like every dev has a different way to deal with this, and even though
it seems basic ("Who would seriously ask advice about how to deal with
emails?"), it's much more complex than what you can expect in the beginning.
Hopefully, my workflow and my email client are ready to take it now.
Since you've asked for it, here are some of my thoughts:
I don't think it is e.g. hard to filter for e-mails that have "docs/" in the
subject, so that's certainly not a problem. It's getting tricky for huge
series that e.g. have just one little change to the docs folder in between.
Some people will CC: the whole big series to you for that little change in
one of the patches - how do you filter for such series?
Having maintained a generic subsystem with a catch-all entry in the past (I
used to be the maintainer of the qtests, and we had a "F: tests/qtest/"
entry in MAINTAINERS for this), I often got CC:-ed on big patch series that
should rather go through the architecture maintainer's tree, and since only
single patches affected the qtest subsystem, this was hard to filter, so I
always got lots of unrelated patches in my Inbox in which I was not really
interested in.
My mitigation was to add some "X:" lines to the qtest section in MAINTAINERS
... but if someone has some better ideas how to deal with such situations
(e.g. if there are some clever ways to filter such series out of your
Inbox), I'd be grateful to hear about them!
FWIW, for the functional testing framework, I organized the entry in
MAINTAINERS differently, there is no generic "F: tests/functional/" line in
the section, but rather only coverage for the shared files of the framework
... the tests themselves should be covered by the individual maintainers
instead. This works much better for me there.
So I'm interested to know how the generic "F: docs/" entry will work out for
you once this patch got merged and some weeks have passed. Having a BoF at
the next KVM forum about this email workflow topic might be a good idea, indeed.
Thomas
I really appreciate you took the time to share that and your experience
on the topic. The "exclusion" based approach you use is definitely a
good option in case I get notified with too many series.
I tend to see series as an atomic change, expecting them to be pulled as
a whole. Thus, I expect, maybe wrongly, that isolated doc patches will
be pulled with the concerned series.
For my workflow, I use a single qemu-devel folder, with a few additional
mechanics to follow threads:
- emails where I'm a direct cc/to are starred (Imap \Flagged keyword)
- use tags (imap keywords) for series: to review, personal, to follow up
- keep cover letter unread as long as there is an action to do on this
thread
- mark as read all the rest so it can disappear quickly
Order of series in my client are:
[tag - to review]
[tag - personal (my series)]
[tag - follow up (was reviewed or is interesting)]
[untagged series where I'm a direct cc/to]
[all the rest]
This way, top series are the one followed, and all the bottom ones are
the new ones, and I can focus on the "starred" ones to identify quickly
content that concerns me.
From this, I just expect to see more starred threads, and I can easily
see what concerns me (doc oriented series) or not (partial doc as part
of the series), and tag the series accordingly.
We'll see in two months how this opinion changed :)
Thanks,
Pierrick
