On 3/9/26 10:35 AM, BALATON Zoltan wrote:
On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
On 3/9/26 9:38 AM, BALATON Zoltan wrote:
On Mon, 9 Mar 2026, Pierrick Bouvier wrote:
On 3/5/26 9:15 PM, Pierrick Bouvier wrote:
When using llvm-addr2line in replacement of addr2line, it will output
zero sized symbols, which can shadow other binaries depending on where
there location is (happens with arm-trusted-firmware and its different
binaries). Thus, those symbols.
Signed-off-by: Pierrick Bouvier <[email protected]>
---
contrib/plugins/uftrace_symbols.py | 2 ++
1 file changed, 2 insertions(+)
This was merged into master (a8ff516c2f5ec05fb8b8bf4bceb88f49701f80d6).
I doubt the usefulness of such messages. People will know when pulling
from git and this list already has high enough volume. If you think this
is useful for contributors could you please send such mails off list only
to involved parties?
From what I understand, since you were not directly CC on this series, your
problem is not especially with the message in itself, but with the fact that
"this list already has high enough volume". I personally don't suffer from
that, even though being CC on all patches touching docs/, because my email
workflow allows me to follow threads I have specific interest with, and
ignore the rest.
In general, a mailing list is not something you are supposed to read
exhaustively. Instead, you're supposed to track your personal interests out
of it. For an analogy: When you go to your local supermarket, will you try to
follow every conversation happening there?
If you feel it's too much for you, then maybe there is something to look into
how you track the mailing list, and my advice would be to use a threaded
view, with tags and mail filters to reduce the high volume you seem to
receive on a daily basis. If you're interested, I can share my (simple)
setup, and maybe you can get inspiration from it for your personal usage.
Threaded view does not help because the thread is already deleted when the
separate "this patch was merged with commit hash" message arrives so it
will show up at top level again. Ignoring everyting not cc'd to me would
make me miss useful info about where the project goes or being able to
review a few patches because I would not see them.
So, that's the issue, deleting existing threads breaks the context
indeed. It's like working with git repositories at -depth 1 and trying
to use 'git log' on a specific file.
Personally, I mark messages as read instead of deleting them and use
"View -> Threads -> Threads with Unread". It has the added benefit that
you can search efficiently through past conversations also.
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.
If you email client gets in the way, switch to another one.
To be honest, I was thinking to organize a small BoF on next KVM Forum to
allow people to share their personal tips with handling emails.
It seems to be a common issue, and some maintainers even missed some series
they were supposed to review, or to pull them. For myself as well, it took
quite some time before having a correct workflow. I even went through the
idea of "reading everything" and quickly dropped it as it was unbearable.
This also suggests maybe there's too much traffic on the list so it would
be useful to think about how to reduce it. However maintainers are
supposed to be cc'd on series they should care about so they should not
miss them but maybe the problem here is more that there are a lot of areas
without maintainers listed or those in the MAINTAINERS file don't respond
even if cc'd. Just email workflow may not help with that.
That's true, some series fall through the cracks. That's why I applied
to maintain docs/ to collect series/patches that might have been missed
there. If you care about some specific subsystems, I encourage you to
apply for becoming maintainer on the concerned top folder, so you can
collect what is not by other maintainers.
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.
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.
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.
It's totally right for you to mention you don't like it, feel free to ignore
the message. However, I feel it's a bit beyond your rights to decide what
people can or can't send on mailing list when you are not in CC on the
concerned thread, don't you think?
And that's what I did. Mentioned that I don't like it and asked if this is
really something others want or think it's useful to get these messages on
the list or could it be done without increasing list traffic. How did you
get the impression I told you not to send such messages at all? Just asked
if it's really necessary for everybody on the list? The same way don't you
think it's beyond your right to decide how I choose to read the list? I
think this is a misunderstanding and I don't want to tell you what to do
but wanted to discuss if there's a better way to do this and tell you my
opinion. Don't know why you felt offended.
> How did you get the impression I told you not to send such messages
at all?
From: If you think this is useful for contributors could you please send
such mails off list only to involved parties?
Reading it again, you are right, it can be seen as a polite suggestion,
even though I read it as a mandatory request first.
I didn't feel offended, but felt like you were trying to control what
someone can or can't send on mailing list, which is a big NO for me. I
would react the same way on any other thread where I would read the same
kind of message.
On the same note, I didn't try to control how you read the list, but to
suggest a better workflow, because I sincerely think deleting threads
and reading all new messages is not a good workflow.
It personally doesn't affect me, as long as you don't come to ask here
how to reduce number of emails sent.
Regards,
Pierrick
