All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: David Miller <davem@davemloft.net>
Cc: rostedt@goodmis.org, mingo@kernel.org, henrik@austad.us,
	linux-kernel@vger.kernel.org, laijs@cn.fujitsu.com,
	dipankar@in.ibm.com, akpm@linux-foundation.org,
	mathieu.desnoyers@efficios.com, josh@joshtriplett.org,
	niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org,
	dhowells@redhat.com, edumazet@google.com, darren@dvhart.com,
	fweisbec@gmail.com, sbw@mit.edu
Subject: Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
Date: Thu, 5 Dec 2013 10:18:34 -0800	[thread overview]
Message-ID: <20131205181834.GV15492@linux.vnet.ibm.com> (raw)
In-Reply-To: <20131205.130524.997340443429884333.davem@davemloft.net>

On Thu, Dec 05, 2013 at 01:05:24PM -0500, David Miller wrote:
> From: Steven Rostedt <rostedt@goodmis.org>
> Date: Thu, 5 Dec 2013 08:51:46 -0500
> 
> > I wish vger wouldn't do that. I wonder how much spam is really flagged
> > by this one characteristic alone. That is, spam that would have made it
> > otherwise, but because of the Cc list, it was rejected.
> 
> 10 to 20 spam posts per day are prevented by this rule.
> 
> And frankly it's totally rediculous to have such a huge CC: list
> in the first place, even if the vger spam filter didn't exist.
> 
> If you CC: something to netdev, it's going to reach me, you don't need
> to CC: me.  If just makes for a dup that I have to delete in my inbox,
> so you're actually making more work for me in the end.
> 
> That's just one example.

Hello, David,

The situation that leads me to use a large CC list is when I am doing
something that affects all architectures.  I could imagine keeping a
smallish CC list, then forwarding or bouncing the email to the remaining
maintainers  Would that work reasonably, or is there some better approach?

							Thanx, Paul


  reply	other threads:[~2013-12-05 18:18 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-04 22:46 [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates Paul E. McKenney
2013-12-04 22:46 ` [PATCH tip/core/locking 1/4] Documentation/memory-barriers.txt: Add needed ACCESS_ONCE() calls to memory-barriers.txt Paul E. McKenney
2013-12-04 22:46   ` [PATCH tip/core/locking 2/4] Documentation/memory-barriers.txt: Add long atomic examples " Paul E. McKenney
2013-12-04 22:46   ` [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE() Paul E. McKenney
2013-12-05  9:33     ` Ingo Molnar
2013-12-05  9:52       ` Mathieu Desnoyers
2013-12-05 10:11         ` Ingo Molnar
2013-12-05 18:02       ` Paul E. McKenney
2013-12-10 13:24         ` Ingo Molnar
2013-12-10 17:36           ` Paul E. McKenney
2013-12-05  9:50     ` Ingo Molnar
2013-12-05 18:05       ` Paul E. McKenney
2013-12-05 22:47         ` Paul E. McKenney
2013-12-10 15:10           ` Ingo Molnar
2013-12-10 17:37             ` Paul E. McKenney
2013-12-05 20:21     ` Jonathan Corbet
2013-12-05 21:44       ` Paul E. McKenney
2013-12-10 15:20         ` Ingo Molnar
2013-12-10 17:44           ` Paul E. McKenney
2013-12-10 18:28             ` Ingo Molnar
2013-12-10 19:01               ` Paul E. McKenney
2013-12-10 19:46                 ` Ingo Molnar
2013-12-10 20:09                   ` Paul E. McKenney
2013-12-05  0:10 ` [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates Josh Triplett
2013-12-05 10:59 ` Henrik Austad
2013-12-05 12:28   ` Ingo Molnar
2013-12-05 13:51     ` Steven Rostedt
2013-12-05 18:05       ` David Miller
2013-12-05 18:18         ` Paul E. McKenney [this message]
2013-12-05 18:44           ` David Miller
2013-12-05 19:01             ` Paul E. McKenney
2013-12-10 15:24         ` Ingo Molnar
2013-12-05 12:29   ` [PATCH v4 tip/core/locking 3/4] Documentation/memory-barriers.txt: Prohibit speculative writes Ingo Molnar

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=20131205181834.GV15492@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=darren@dvhart.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@gmail.com \
    --cc=henrik@austad.us \
    --cc=josh@joshtriplett.org \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mingo@kernel.org \
    --cc=niv@us.ibm.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=sbw@mit.edu \
    --cc=tglx@linutronix.de \
    /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.