From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from cgf.cx (external.cgf.cx [107.170.62.102]) by sourceware.org (Postfix) with ESMTP id 9B8B3398D03C for ; Fri, 17 Jul 2020 19:48:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 9B8B3398D03C X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 cgf.cx 613CD4008C X-Spam-Level: X-Spam-CGF-Status: No, score=-1.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, TXREP autolearn=ham autolearn_force=no version=3.4.4 spammy=grown, waste, H*r:unknown, 13000 Received: by cgf.cx (sSMTP sendmail emulation); Fri, 17 Jul 2020 15:48:16 -0400 Date: Fri, 17 Jul 2020 15:48:16 -0400 From: Christopher Faylor To: Overseers mailing list Cc: overseers@gcc.gnu.org, gcc@gcc.gnu.org Subject: Re: Separate commit mailing lists for trunk/branches possible? Message-ID: <20200717194816.GA13274@cgf.cx> Mail-Followup-To: Overseers mailing list , overseers@gcc.gnu.org, gcc@gcc.gnu.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_00, FORGED_SPF_HELO, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, KHOP_HELO_FCRDNS, SPF_HELO_PASS, SPF_NEUTRAL, TXREP autolearn=no autolearn_force=no version=3.4.2 X-BeenThere: overseers@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Overseers mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2020 19:48:19 -0000 On Fri, Jul 17, 2020 at 07:05:48PM +0100, Maciej W. Rozycki wrote: > As you have probably been well-aware the amount of traffic sent to the > mailing list has grown dramatically since the switch >to GIT. Last month alone I received over 13000 messages, which accounted >for ~18.5% of all my incoming traffic. And right now another mailbomb has >been in progress; since midnight I have received over 3700 messages so >far. > > Most of this stuff is vendor branch stuff I find completely uninteresting >to me and which from my point of view is a waste of resources. I could >filter it to /dev/null via `procmail', but that would still be a waste. Actually, it seems like a procmail rule would solve your problem.