On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
As well, for people reading the thread afterward from lore.kernel.org, it
confirms the series was merged and the topic is closed, without needing to
check manually in git log, parse pull requests, or check on patchew status
of
series. You'll notice that I always send an update email when posting a
new
version to link to new version also, to "close" a given version, in a
similar
way. See it as an email ladder version -> version -> version ->
notify_merged.
OK at least this gives a reason why sending to the list might be useful
for some to track a pull later on lore.kernel.org. There are already other
similar systems but some may prefer this.
I didn't invent any of this but simply mimic what GitHub and GitLab (and
But you started doing it on the QEMU list. Some other maintainers cc
patches in pull requests also to authors, some others don't and you
introduced yet another solution. So you kind of invented it here as we did
without it for quite a while and nobody complained. That does not mean
this can't be useful for some but could you at least consider doing it in
a way that works for everybody?
In this case, feel free to start a topic and forbid this "officially" for
everyone, including maintainers that sometimes report that code was merged,
or that they pulled it in their own tree, as it's the same kind of semantic
message. I would be very happy to obey to any new rule of conduct that would
be added for the whole community.
In that case maybe you should start a topic and agree on an official way.
I don't want to forbid anything, just noted there's an inconsistency here
and your way just added to that inconsistency besides making my life more
difficult. I was questioning if it's useful to send such messages to the
list as the reasoning for them was that people who don't follow the list
might miss their patches were merged. That to me does not imply the list
also needs these messages. Above you gave a reason to archive it in the
list too so a lifecycle of a patch can be followed. OK that answers why
the list might need these too.
other forges) do. They notify you on new versions, on final merge, and
you're
free to unsubscribe from a PR if you're not interested.
That's exactly the issue. With those forges I could subscribe or
unsubscribe to/from these but here you decided I should be subscribed and
left not much way to unsibscribe.
There is a way to do it, by keeping threads context in your mailbox.
If you don't want, your need to invent another ad-hoc solution.
Once again, I totally respect you don't find it useful, feel free to
delete
and ignore those messages.
Could you at least make it easy to filter and delete them? Like sending
them with a cover letter threaded at once or adding [MERGED] to the
subject or something similar so they are easily filtered and not just tell
me to deal with it if I don't like it?
The message body will always be the same, as I use a template in my email
client.
```
This was merged into master (.*).
Thank you for your contribution!
Regards,
Pierrick
```
Second line is optional because I don't thank myself when sending my own
series.
So a simple email filter could be:
from: [email protected]
contains: 'This was merged into master (.*)'
Does that sound good to you?
That helps as long as you're the only one sending these otherwise "from"
is not the same. It would be even better it you could also change the
label in the subject to [MERGED] as it's easier to filter by headers
(faster than content search) and that may also help more easily tracking
the lifecycle later so you'd see [PATCH vXX] -> [PULL] -> [MERGED}. Or add
some header specific to these messages.
Regards,
BALATON Zoltan
