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 1pdd8f-0006g9-Or for pgsql-hackers@arkaria.postgresql.org; Sat, 18 Mar 2023 20:26:54 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pdd8e-0004VC-77 for pgsql-hackers@arkaria.postgresql.org; Sat, 18 Mar 2023 20:26:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdd8d-0004V2-Tm for pgsql-hackers@lists.postgresql.org; Sat, 18 Mar 2023 20:26:51 +0000 Received: from out4-smtp.messagingengine.com ([66.111.4.28]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pdd8b-0001NX-3Z for pgsql-hackers@postgresql.org; Sat, 18 Mar 2023 20:26:51 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id B86B85C00D5; Sat, 18 Mar 2023 16:26:47 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sat, 18 Mar 2023 16:26:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1679171207; x= 1679257607; bh=YTCzx7ONy/EtVrUkjSGauZX6ic3lOS9FUj8A96RcyOE=; b=J HEil8CDcs3P79DvrEf9Zbd/1aY5tELs4ti2PkIHfaHkAuWR1C93zk4br61mHknSz Mh9sN45lRo78/YcgwtXjgmfND6kWLOXwODCqJtDok0moX/vaVQuVKgCwGdBGAdxa plVYTPsEy51v3S9h0FgLd0+IhfciO1TbKWP9x8ZV+NNvynf5vQ6z+n1y+aRa+7kl Qt0br8vejikJuoLQ/I4K2ih5F1SJlzyrHgFxiG5+KBC9Dszam7Fzp4iKzBJQBE1x eYr/fABAGl6FQODHBWpy4D+BNEF/fVgWcpj/RVxwUbIigEwA0M1q4EusonPepvyj 154ZR3gtkUz0XyI2nD7KQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrvdefgedgudefiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhv rghrohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorh hgqeenucggtffrrghtthgvrhhnpedvkedtffduffdtffffheffhfejjefhgfeiueeukeej keffgfdufffhudffffeuveenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtoh hmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprghl vhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 18 Mar 2023 16:26:47 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id F2F85A6; Sat, 18 Mar 2023 21:26:42 +0100 (CET) Date: Sat, 18 Mar 2023 21:26:42 +0100 From: Alvaro Herrera To: Greg Stark Cc: "Gregory Stark (as CFM)" , Michael Paquier , PostgreSQL-development Subject: Re: Commitfest 2023-03 starting tomorrow! Message-ID: <20230318202642.uzfkystsyqevn6fl@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2023-Mar-17, Greg Stark wrote: > I'm going to go ahead and do this today. Any of these patches that are > "Waiting on Author" and haven't received any emails or status changes > since March 1 I'm going to move out of the commitfest(*). So I've come around to thinking that booting patches out of commitfest is not really such a great idea. It turns out that the number of active patch submitters seems to have reached a peak during the Postgres 12 timeframe, and has been steadily decreasing since then; and I think this is partly due to frustration caused by our patch process. It turns out that we expect that contributors will keep the patches the submit up to date, rebasing over and over for months on end, with no actual review occurring, and if this rebasing activity stops for a few weeks, we boot these patches out. This is demotivating: people went great lengths to introduce themselves to our admittedly antiquated process (no pull requests, remember), we gave them no feedback, and then we reject their patches with no further effort? I think this is not good. At this point, I'm going to suggest that reviewers should be open to the idea of applying a submitted patch to some older Git commit in order to review it. If we have given feedback, then it's OK to put a patch as "waiting on author" and eventually boot it; but if we have not given feedback, and there is no reason to think that the merge conflicts some how make the patch fundamentally obsolete, then we should *not* set it Waiting on Author. After all, it is quite easy to "git checkout" a slightly older tree to get the patch to apply cleanly and review it there. Authors should, of course, be encouraged to keep patches conflict-free, but this should not be a hard requirement. -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/