Re: Commitfest statistics

On 2020-Dec-07, Tom Lane wrote:

> Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> writes:

> > Firstly, we use it to track patches that we want to see in the nearest
> > releases and concentrate our efforts on. And current CFM guideline [1]
> > reflects this idea. It suggests, that after the commitfest closure date
> > we relentlessly throw to RWF patches that got at least some feedback. To
> > be honest, I was reluctant to return semi-ready patches, because it
> > means that they will get lost somewhere in mailing lists. And it seems
> > like other CFMs did the same.
>
> Yeah, the aggressive policy suggested in "Sudden Death Overtime" is
> certainly not what's been followed lately. I agree that that's
> probably too draconic. On the other hand, if a patch sits in the
> queue for several CFs without getting committed, that suggests that
> maybe we ought to reject it on the grounds of "apparently nobody but
> the author cares about this". That argument is easier to make for
> features than bug fixes of course, so maybe the policy needs to
> distinguish what kind of change is being considered.

Note that this checklist was written in 2013 and has never been updated
since then. I think there is nothing in that policy that we do use.
I'm thinking that rather than try to fine-tune that document, we ought
to rewrite one from scratch.

For one thing, "a beer or three" only at end of CF is surely not
sufficient.