Re: Commitfest manager 2020-11 - Mailing list pgsql-hackers

From Anastasia Lubennikova
Subject Re: Commitfest manager 2020-11
Date
Msg-id 60284a7f-aad4-fc37-d74c-2055302eba06@postgrespro.ru
Whole thread Raw
In response to Commitfest manager 2020-11  (gkokolatos@pm.me)
Responses Re: Commitfest manager 2020-11  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Commitfest manager 2020-11  (gkokolatos@pm.me)
List pgsql-hackers
On 24.08.2020 16:08, gkokolatos@pm.me wrote:
> Hi all,
>
> Admittedly quite ahead of time, I would like to volunteer as Commitfest manager for 2020-11.
>
> If the role is not filled and there are no objections, I can reach out again in October for confirmation.
>
> //Georgios

Wow, that was well in advance) I am willing to assist if you need any help.

I was looking for this message, to find out who is the current CFM. 
Apparently, the November commitfest is not in progress yet.

Still, I have a question. Should we also maintain statuses of the 
patches in the "Open" commitfest? 21 patches were already committed 
during this CF, which shows that even "open" CF is quite active. I've 
updated a few patches, that were sent by my colleagues. If there are no 
objections, I can do that for other entries too.

On the other hand, I noticed a lot of stall threads, that weren't 
updated in months. Some of them seem to pass several CFs without any 
activity at all. I believe that it is wrong for many reasons, the major 
of which IMHO is a frustration of the authors. Can we come up with 
something to impove this situation?

P.S. I have a few more ideas about the CF management. I suppose, that 
they are usually being discussed at pgcon meetings, but those won't 
happen anytime soon. Is there a special place for such discussions, or I 
may continue this thread?

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Assertion failure with LEFT JOINs among >500 relations
Next
From: "Daniel Verite"
Date:
Subject: Re: speed up unicode decomposition and recomposition