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.
Getting messages about patches being queued is useful for other
maintainers and contributors to know the patches are picked up and then
they will also see the pull request on the list and when the pull request
got merged. Getting separate messages for each patch in a pull request
does not add more info to that for people already following the list.
Except that some maintainers, including me, don't cc original authors when
sending a PR (that's a deliberate decision). As well, some top maintainers
don't always send back a message once the PR is done. Or they don't
include
all authors on individual patches.
I don't think that's a problem. If somebody is interested they could
follow the list or filter it e.g. for their S-o-b or simliar to get those
messages or pull requests even without being cc'd.
In the case of TCG plugins, a lot of contributors are new comers and are not
used to all this. I personally don't want to put the pressure on them to
configure this kind of complicated setup, but prefer to offer them a
GitHub/GitLab like experience. The series is a PR/MR, and when it's merged,
the forge notify them it is.
Sending email patches is already a pain in itself for newcomers, no need to
ask them to configure email filters on top of that.
But you have no problem putting that pressure on me :-). Yes I know it can
be a pain for newcomers and did not say these messages can't be useful to
them. But I can't follow your logic about sending these to the list. You
say that they won't see if their patch were merged because they won't
follow the list because it gets too many messages. So you need to cc them
but you also send that to the list where they won't read it anyway so it
just increases the volume of the list even more with messages that those
on the list will just have to ignore. Wouldn't it be simpler to not send
these messages to the list if those interested are already cc'd because
they are not expected to read the list?
Answering below.
So for consistency and the series I personnally track, yes, I believe
there
is a value in notifiying original series and author.
I'm OK with that, what I doubted is that it is useful to send this to the
list too. Wouldn't it be enough to only send it to the people involved off
list?
It does not notify only original author, but other maintainers or reviewers
also. As a concrete example, I'm sure you already went through a thread where
someone was reviewing code already merged. With such notification, it would
not have happened.
I'm not sure about that. If they are not on cc they would miss this
message on the list the same way they missed the pull request. If they are
on cc they would see this message without it being sent to the list too.
If you started arguing about the message itself, it would be an interesting
debate. But your point is "My email workflow is A, and I don't like B, please
change B". So my polite answer is "Your email workflow is A, and you don't
like B, so change A". We can run in circles for hours I guess.
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.
I didn't invent any of this but simply mimic what GitHub and GitLab (and
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.
Once again, I totally respect you don't find it useful, feel free to
delete and ignore those messages.
Regards,
Pierrick
