On 16.10.2020 21:57, Tom Lane wrote:
> Anastasia Lubennikova <a.lubennikova@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-VGMVZuH86sQ@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