[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Cc'ing emails [
From: |
Markus Armbruster |
Subject: |
Re: [Qemu-devel] Cc'ing emails [ |
Date: |
Tue, 05 Aug 2014 11:41:37 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) |
Michael Tokarev <address@hidden> writes:
> 05.08.2014 08:41, Chen Gang wrote:
>>
>> Every members have their own tastes, and one working flow may be not
>> suitable for all members. I can understand, and hope other members
>> understand too.
>>
>> At least for me, next, I shall send patch to the members which I can get
>> from 'get_maintainers.pl' and only Cc to qemu-devel. And shall skip
>> qemu-trivial and Michael Tokarev.
>
> Why skip both? It's your call, but I'm curious.
>
> What I _think_ wrong is that get_maintainers.pl lists many random
> "patchers" for a given file by default.
>
> Besides, we should probably review role of Anthony Ligory, because
> he is returned as a sole contact for manu files, but apparently he
> does not reply to emails anymore.
>
> []
>>>> I'm not sure how people treat these cases or deal with them.
>>>> We are subscribed to, in particular, qemu-devel@, and active
>>>> maintainers look there too, so receive more than one copy of
>>>> many emails.
>>>
>>> I believe fighting the established convention to copy is futile. I
>>> embrace it instead, and make it help me prioritize my reading. Copy me,
>>> and I'll at least skim cover letters and other thread-starters to
>>> determine whether I need to follow this thread. Don't copy me, and I'll
>>> at best glance at the subject in passing.
>
> We created some separate mailinglists - for example -trivial@ - especially
> to get such attention. This is what I'm talking about, in most part,
> because main qemu mailinglist traffic become quite a bit high to follow
> it closely, and it is a good idea indeed to Cc someone when sending mail
> to address@hidden But even there, Cc'ing random "patchers" as
> get_maintainer.pl
> often suggests is _not_ a good idea. I think.
I don't disagree with you there. I take get_maintainer.pl as advice,
not gospel.
Note that because --git is *off* by default, you get "random patchers"
only when MAINTAINERS comes up empty. Which it does far too often,
because its coverage is lousy: some 1300 out of >3600 files.
We could default --git-fallback to off to suppress "random patchers"
unless you ask for them.
>>> Automatic filing into folders and marking copies so I don't have to mark
>>> them read twice helps.
>>>
>>> The additional traffic is a drop in a bucket.
>
> Which traffic you refer to as "additional"? The personal emails?
The personal copies compared to the full list traffic.
I count some 1200 messages to qemu-devel for the past week. 32 contain
the string "address@hidden", which I take as a crude upper bound for you
getting a copy. I don't mean to say that's not annoying or a drain on
your time (who am I to judge?), just that the additional network traffic
over full qemu-devel delivery is negligible.
> At least in my case it is quite significant because of qemu, and qemu
> is _far_ from a single project where I actively contributed. For example,
> I contributed many things to postfix, but I don't have to worry about
> it in any way, and I don't receive random personal emails - if something
> is being Cc'ed to me it really is something important. Ditto for linux
> kernel and other areas.
I recommend to set up filters to file away list traffic and copies of
list traffic separately from your private e-mail.
> In case of qemu, see -- for example, Anthony, who apparently stepped
> out from qemu. Almost every email on qemu-devel@ is being Cc'ed to
> him nowadays, so he receives _whole_ qemu-devel@ in his personal
> mailbox.
I'd be surprised if he received copies in his personal inbox. I expect
him to file them smartly.
> Is it also a drop in (his) bucket?
I guess it is: 125 of last week's messages contain "aliguori@".
- Re: [Qemu-devel] [PATCH] dump.c: Fix memory leak issue in cleanup processing for dump_init(), (continued)
Re: [Qemu-devel] [PATCH] dump.c: Fix memory leak issue in cleanup processing for dump_init(), Laszlo Ersek, 2014/08/12
Re: [Qemu-devel] [PATCH] dump.c: Fix memory leak issue in cleanup processing for dump_init(), Luiz Capitulino, 2014/08/14