All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Tokarev <mjt@tls.msk.ru>
To: Chen Gang <gang.chen.5i5j@gmail.com>,
	 Markus Armbruster <armbru@redhat.com>
Cc: qemu-trivial@nongnu.org, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-trivial] [Qemu-devel] Cc'ing emails [
Date: Tue, 05 Aug 2014 11:08:31 +0400	[thread overview]
Message-ID: <53E082EF.9090007@msgid.tls.msk.ru> (raw)
In-Reply-To: <53E06083.7080909@gmail.com>

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 qemu-devel@.  But even there, Cc'ing random "patchers" as get_maintainer.pl
often suggests is _not_ a good idea.  I think.

>> 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?

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.

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.  Is it also a drop in (his) bucket?

Thanks,

/mjt


WARNING: multiple messages have this Message-ID (diff)
From: Michael Tokarev <mjt@tls.msk.ru>
To: Chen Gang <gang.chen.5i5j@gmail.com>,
	Markus Armbruster <armbru@redhat.com>
Cc: qemu-trivial@nongnu.org, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Cc'ing emails [
Date: Tue, 05 Aug 2014 11:08:31 +0400	[thread overview]
Message-ID: <53E082EF.9090007@msgid.tls.msk.ru> (raw)
In-Reply-To: <53E06083.7080909@gmail.com>

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 qemu-devel@.  But even there, Cc'ing random "patchers" as get_maintainer.pl
often suggests is _not_ a good idea.  I think.

>> 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?

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.

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.  Is it also a drop in (his) bucket?

Thanks,

/mjt

  reply	other threads:[~2014-08-05  7:08 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-03 15:28 [Qemu-trivial] [PATCH] dump.c: Fix memory leak issue in cleanup processing for dump_init() Chen Gang
2014-08-03 15:28 ` [Qemu-devel] " Chen Gang
2014-08-03 15:56 ` [Qemu-trivial] " Laszlo Ersek
2014-08-03 15:56   ` [Qemu-devel] " Laszlo Ersek
2014-08-04 13:51   ` [Qemu-trivial] " Chen Gang
2014-08-04 13:51     ` [Qemu-devel] " Chen Gang
2014-08-11 19:47     ` [Qemu-trivial] " Chen Gang
2014-08-11 19:47       ` [Qemu-devel] " Chen Gang
2014-08-04  7:59 ` [Qemu-trivial] Cc'ing emails [was: [PATCH] dump.c: Fix memory leak issue in cleanup processing for dump_init()] Michael Tokarev
2014-08-04  7:59   ` [Qemu-devel] " Michael Tokarev
2014-08-04 14:13   ` [Qemu-trivial] " Chen Gang
2014-08-04 14:13     ` [Qemu-devel] " Chen Gang
2014-08-04 15:43   ` [Qemu-trivial] [Qemu-devel] Cc'ing emails [ Markus Armbruster
2014-08-04 15:43     ` Markus Armbruster
2014-08-05  4:41     ` [Qemu-trivial] " Chen Gang
2014-08-05  4:41       ` Chen Gang
2014-08-05  7:08       ` Michael Tokarev [this message]
2014-08-05  7:08         ` Michael Tokarev
2014-08-05  8:07         ` [Qemu-trivial] " Peter Maydell
2014-08-05  8:07           ` Peter Maydell
2014-08-05 12:20           ` [Qemu-trivial] " Chen Gang
2014-08-05 12:20             ` Chen Gang
2014-08-05  9:41         ` [Qemu-trivial] " Markus Armbruster
2014-08-05  9:41           ` Markus Armbruster
2014-08-05 13:25           ` [Qemu-trivial] " Anthony Liguori
2014-08-05 13:25             ` Anthony Liguori
2014-08-12 15:43 ` [Qemu-trivial] [PATCH] dump.c: Fix memory leak issue in cleanup processing for dump_init() Laszlo Ersek
2014-08-12 15:43   ` [Qemu-devel] " Laszlo Ersek
2014-08-12 22:19   ` [Qemu-trivial] " Chen Gang
2014-08-12 22:19     ` [Qemu-devel] " Chen Gang
2014-08-14 20:49 ` [Qemu-trivial] " Luiz Capitulino
2014-08-14 20:49   ` [Qemu-devel] " Luiz Capitulino
2014-08-14 22:03   ` [Qemu-trivial] " Chen Gang
2014-08-14 22:03     ` [Qemu-devel] " Chen Gang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53E082EF.9090007@msgid.tls.msk.ru \
    --to=mjt@tls.msk.ru \
    --cc=armbru@redhat.com \
    --cc=gang.chen.5i5j@gmail.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-trivial@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.