Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s7ivo-00734v-Tz for pgsql-hackers@arkaria.postgresql.org; Thu, 16 May 2024 21:46:34 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1s7ivo-00Gm1A-Od for pgsql-hackers@arkaria.postgresql.org; Thu, 16 May 2024 21:46:32 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s7ivo-00Gm11-FM for pgsql-hackers@lists.postgresql.org; Thu, 16 May 2024 21:46:32 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1s7ivm-000Ypa-2r for pgsql-hackers@postgresql.org; Thu, 16 May 2024 21:46:31 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 44GLkRJt2186209; Thu, 16 May 2024 17:46:27 -0400 From: Tom Lane To: Peter Eisentraut cc: Melanie Plageman , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: commitfest.postgresql.org is no longer fit for purpose In-reply-to: <45faf826-42b7-4ce9-a081-0903d033f411@eisentraut.org> References: <45faf826-42b7-4ce9-a081-0903d033f411@eisentraut.org> Comments: In-reply-to Peter Eisentraut message dated "Thu, 16 May 2024 23:35:45 +0200" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2186207.1715895987.1@sss.pgh.pa.us> Date: Thu, 16 May 2024 17:46:27 -0400 Message-ID: <2186208.1715895987@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Eisentraut writes: > The problem is if we have 180 patches in Needs Review, and only 20 are > really actually ready to be reviewed. And a second-order problem is > that if you already know that this will be the case, you give up before > even looking. Right, so what can we do about that? Does Needs Review state need to be subdivided, and if so how? If it's just that a patch should be in some other state altogether, we should simply encourage people to change the state as soon as they discover that. I think the problem is not so much "90% are in the wrong state" as "each potential reviewer has to rediscover that". At this point it seems like there's consensus to have a "parking" section of the CF app, separate from the time-boxed CFs, and I hope somebody will go make that happen. But I don't think that's our only issue, so we need to keep thinking about what should be improved. regards, tom lane