From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTP id D1C27847 for ; Sun, 1 Jun 2014 08:36:32 +0000 (UTC) Received: from mx2.suse.de (cantor2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 0E33C1FAB5 for ; Sun, 1 Jun 2014 08:36:31 +0000 (UTC) Date: Sun, 01 Jun 2014 10:36:28 +0200 Message-ID: From: Takashi Iwai To: Geert Uytterhoeven In-Reply-To: References: <20140528163902.GA5099@sirena.org.uk> <1401295862.13546.109.camel@dhcp-9-2-203-236.watson.ibm.com> <20140528173553.GE5099@sirena.org.uk> <3908561D78D1C84285E8C5FCA982C28F328205B1@ORSMSX114.amr.corp.intel.com> <20140528183825.GA21477@sirena.org.uk> <5386FDAB.3010106@huawei.com> <20140529174122.GC7889@kroah.com> <20140530172858.GA16343@linux.vnet.ibm.com> <20140530234003.GG25854@kroah.com> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: James Bottomley , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TOPIC] Encouraging more reviewers List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , At Sat, 31 May 2014 18:49:51 +0200, Geert Uytterhoeven wrote: > > On Wed, May 28, 2014 at 11:59 PM, Thomas Gleixner wrote: > > I really started to put breaks into this cycle of hell, where I get > > spammed with a 30+ patch series in the morning and after I spent some > > quality time looking at it and replying to a particular patch, I get > > another spam bomb within a few hours, which is not much better than > > the previous one. > > That's indeed an issue. Some large series are immediately reposted for every > single (sometimes trivial) change suggested by a commenter. > This also leads to inflated patch version numbers. I'm already getting nervous > when I have to send out a v3 or v4 myself, but from a quick search, v29 > seems to be the current record on lkml... > > Does git send-email remember when the previous version of a series was > sent out? > If yes, it could refuse to resend it too soon. The back off period would > depend on the size of the patch series (large patch series need more delay). IMO, it's dangerous to let a basic tool like git blocking the immediate resend, too. I agree that digesting a large patchset is one of most painful tasks as a maintainer. In such a case, however, I'd rather suggest to split the large patch series into multiple staged patchsets. Takashi