From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Commitfest 2024-01 first week update |
Date: | 2024-02-04 09:02:12 |
Message-ID: | 202402040902.lnr5si5zdegg@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2024-Jan-10, Daniel Gustafsson wrote:
> > On 9 Jan 2024, at 23:18, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> > I think we need to be more aggressive about marking things returned
> > with feedback when they don't get updated.
>
> I very much agree. Having marked quite a lot of patches as RwF when being CFM
> I can attest that it gets very little off-list pushback or angry emails. While
> it does happen, the overwhelming majority of responses are understanding and
> positive, so no CFM should be worried about "being the bad guy".
I like this idea very much -- return patches when the author does not
respond AFTER receiving feedback or the patch rotting.
However, this time around I saw that a bunch of patches were returned or
threatened to be returned JUST BECAUSE nobody had replied to the thread,
with a justification like "you need to generate more interest in your
patch". This is a TERRIBLE idea, and there's one reason why creating a
new commitfest entry in the following commitfest is no good:
At the FOSDEM developer meeting, we do a run of CF patch triage, where
we check the topmost patches in order of number-of-commitfests. If you
return an old patch and a new CF entry is created, this number is reset,
and we could quite possibly fail to detect some very old patch because
of this. At times, the attention a patch gets during the CF triage is
sufficient to get the patch moving forward after long inactivity, so
this is not academic. Case in point: [1].
So by all means let's return patches that rot or fail to get updated per
feedback. But DO NOT return patches because of inactivity.
[1] https://postgr.es/m/202402011550.sfszd46247zi@alvherre.pgsql
--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"Las cosas son buenas o malas segun las hace nuestra opinión" (Lisias)
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2024-02-04 13:38:38 | Re: SLRU optimization - configurable buffer pool and partitioning the SLRU lock |
Previous Message | Alvaro Herrera | 2024-02-04 08:18:18 | Re: Where can I find the doxyfile? |