Re: commitfest.postgresql.org is no longer fit for purpose
От | Peter Eisentraut |
---|---|
Тема | Re: commitfest.postgresql.org is no longer fit for purpose |
Дата | |
Msg-id | b2b47b25-dbca-4e67-80b2-ced08b6a5e08@eisentraut.org обсуждение исходный текст |
Ответ на | Re: commitfest.postgresql.org is no longer fit for purpose (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: commitfest.postgresql.org is no longer fit for purpose
Re: commitfest.postgresql.org is no longer fit for purpose |
Список | pgsql-hackers |
On 16.05.24 23:46, Tom Lane wrote: > Peter Eisentraut <peter@eisentraut.org> 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? Maybe a new state "Unclear". Then a commitfest manager, or someone like Robert just now, can more easily power through the list and set everything that's doubtful to Unclear, with the understanding that the author can set it back to Needs Review to signal that they actually think it's ready. Or, as a variant of what someone else was saying, just set all patches that carry over from March to July as Unclear. Or something like that. I think, if we consider the core mission of the commitfest app, we need to be more protective of the Needs Review state. I have been, from time to time, when I'm in commitfest management mode, aggressive in setting entries back to Waiting on Author, but that's not always optimal. So a third status that encompasses the various other situations like maybe forgotten by author, disagreements between author and reviewer, process difficulties, needs some senior developer intervention, etc. could be helpful. This could also help scale the commitfest manager role, because then the head CFM could have like three helpers and just tell them, look at all the "Unclear" ones and help resolve them.
В списке pgsql-hackers по дате отправления: