Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nVvzD-0003OK-9o for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Mar 2022 13:52:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nVvzB-0006Te-So for pgsql-hackers@arkaria.postgresql.org; Sun, 20 Mar 2022 13:52:45 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nVvzB-0006TV-It for pgsql-hackers@lists.postgresql.org; Sun, 20 Mar 2022 13:52:45 +0000 Received: from relay4-d.mail.gandi.net ([2001:4b98:dc4:8::224]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nVvz4-0000UP-KH for pgsql-hackers@lists.postgresql.org; Sun, 20 Mar 2022 13:52:44 +0000 Received: (Authenticated sender: adsend@dunslane.net) by mail.gandi.net (Postfix) with ESMTPSA id C2FFFE0005; Sun, 20 Mar 2022 13:52:31 +0000 (UTC) Message-ID: <2f9b95b4-77e4-3036-9207-d4d497a87e62@dunslane.net> Date: Sun, 20 Mar 2022 09:52:29 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Problem with moderation of messages with patched attached. Content-Language: en-US To: Andres Freund , Dave Page Cc: Pavel Borisov , Postgres hackers References: <20220319184811.yblhyw6b6dswnx5o@alap3.anarazel.de> From: Andrew Dunstan In-Reply-To: <20220319184811.yblhyw6b6dswnx5o@alap3.anarazel.de> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 3/19/22 14:48, Andres Freund wrote: > Hi, > > On 2022-03-03 13:37:35 +0000, Dave Page wrote: >> On Thu, 3 Mar 2022 at 13:28, Pavel Borisov wrote: >> >>> The mail system doesn't have the capability to apply different moderation >>>> rules for people in that way I'm afraid. >>>> >>> Maybe then 2MB for everyone? Otherwise it's not so convenient. Lead to >>> answers before the questions in the thread [1], seems weird. >>> >> Then someone will complain if their patch is 2.1MB! How often are messages >> legitimately over 1MB anyway, even with a patch? I don't usually moderate >> -hackers, so I don't know if this is a common thing or not. > I don't think it's actually that rare. But most contributors writing that > large patchsets know about the limit and work around it - I gzip patches when > I see the email getting too large. But it's more annoying to work with for > reviewers. > > It's somewhat annoying. If you e.g. append a few graphs of performance changes > and a patch it's pretty easy to get into the range where compressing won't > help anymore. > > And sure, any limit may be hit by somebody. But 1MB across the whole email > seems pretty low these days. > Of course we could get complaints no matter what level we set the limit at. I think raising it to 2Mb would be a reasonable experiment. If no observable evil ensues then leave it that way. If it does then roll it back. I agree that plain uncompressed patches are easier to deal with in general. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com