On 16.10.2020 21:57, Tom Lane wrote:
Anastasia Lubennikova <a.lubennik...@postgrespro.ru> writes:
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?
Yeah, that's a perennial problem.  Part of the issue is just a shortage
of people --- there are always more patches than we can review and
commit in one month.  IMO, another cause is that we have a hard time
saying "no".  If a particular patch isn't too well liked, we tend to
just let it slide to the next CF rather than making the uncomfortable
decision to reject it.  If you've got thoughts about that, or any other
ways to improve the process, for sure speak up.


From a CFM perspective, we can try the following things:

- Write recaps for long-running threads, listing open questions and TODOs.
This one is my personal pain. Some threads do look scary and it is less likely that someone will even start a review if they have to catch up with a year-long discussion of 10 people.

- Mark patches from first-time contributors with some tag.
Probably, these entries are simple/dummy enough to handle them faster. And also it will be a good reminder to be a bit less demanding with beginners. See Dmitry's statistic about how many people have sent patch only once [1].

- Proactively ask committers, if they are going to work on the upcoming CF and will they need any specific help. Maybe we can also ask about their preferred code areas and check what is left uncovered. It's really bad if there is no one, who is working with let's say WAL internals during the CF. TBH, I have no idea, what are we going to do with this knowledge, but I think it's better to know.

- From time to time call a council of several committers and make tough decisions about patches that are in discussion for too long (let's say 4 commitfests). Hopefully, it will be easier to reach a consensus in a "real-time" discussion, or we can toss a coin. This problem was raised in previous discussions too [2].

[1] https://www.postgresql.org/message-id/CA+q6zcXtg7cFwX-c+BoOwk65+jtR-sQGZ=1mqg-vgmvzuh8...@mail.gmail.com [2] https://www.postgresql.org/message-id/flat/CAA8%3DA7-owFLugBVZ0JjehTZJue7brEs2qTjVyZFRDq-B%3D%2BNwNg%40mail.gmail.com


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



Reply via email to