On 3/9/26 4:44 PM, BALATON Zoltan wrote:
On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
On 3/9/26 11:50 AM, BALATON Zoltan wrote:
Every N months, you can run a manual "archive" command (i.e. move to
another
INBOX subfolder) on messages older than N months and your qemu-devel INBOX
will keep a constant size.
Glad that it works for you but I have a limited mail quota so I have to
delete read messages.
Let me update my suggestion with something that would work in your case.
Every N *weeks*, you can run a manual "delete" command on messages older than
N weeks and your qemu-devel INBOX will keep a constant size under your quota.
The key is to not delete thread as soon as you receive them, but keep context
for a few weeks, similar to keeping your git clone to a constant -depth=N
because your disk space could be limited.
It's a win-win: you keep semantic context *and* your quota stays under
control.
You complained why I want to tell you what you should do but you keep
telling me what should I do instead. I say again, please let me decide how
I read the list. I'm fine with the way I do it now. I don't want to keep
context for months or weeks (there are tools like patchew or list archives
for that already where I can look it up if needed) so I only keep locally
what I need in the short term. This is fine as long as the related
messages come threaded at once but with these mails it would come some
indefinite time after the pull request and I'd end up with as many
separate mails as many patches were in a pull request. That can be many
and the only way to thread them would be to keep at least the covers of
all pull requests for who knows how long.
I simply suggested a solution for the problem you had, and you are
totally free to take it or leave it. It's not a "you should", but a "if
you want, you could".
Now, if you leave it and want to read the mailing list in your own way,
feel free to do it, but you're on your own to find a solution for issues
that are related to it.
I'm politely repeating that asking anyone to not send a specific message
on a public mailing list because it breaks your personal workflow is not
a realistic demand, you need to find on your side a way to ignore the
content you don't want to see. That's how a shared space work.
I'm arguing about if it's useful to send these messages to the list. My
workflow is an example but just ignore that for now to avoid
misunderstandings. If you say that you need to send these messages because
those people won't follow the list then I think it's not useful to spam
the list where nobody would read these messages just in case somebody
might read them. I don't care if you send them off list or not and if
others think that it's useful on the list I'm also OK with that but I
don't see what this would add to the already sent pull requests and pull
applied messages already sent to the list for those who follow the list.
They might not be in pull request messages recipients, or didn't configure ad
hoc filters for that, so they might have missed that.
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.
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?
Regards,
BALATON Zoltan
Regards,
Pierrick
