Re: Commitfest statistics

Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> writes:
> I want to share some stats and thoughts about CF.

First, thanks again for managing this CF!

> The first is a graph with the numbers of committed, moved, returned, and
> rejected CF patches over time - [cf_items_status.png]. Credits to Dmitry
> Dolgov for sharing his scripts to gather this stat.

Yeah, that is a very interesting graph. It shows that our actual
throughput of resolving patches has held more or less steady, which
isn't very surprising because the available person-power has not
changed much in the last couple of years. But it looks like the
number of cans getting kicked down the road is progressively
increasing. That's not something we can sustain indefinitely.

> Besides, I noticed that we have a lot of long-living discussions. And I
> was curious what is the chance to get something committed after several
> CFs. The graph is in [num_commitfests.png]. So, most entries make it to
> release after just one or two commitfests.

It's hard to see anything in this graph about what happens after the
first couple of CFs. Maybe if you re-did it with a log Y axis, the
tail would be more readable?

> I think that the issue here is that the commitfest application now
> serves two different purposes:

> 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.
> On the other hand, we use Commitfest to track important entries that we
> want to remember at least once in a while. You can find many examples in
> the 'Bug Fixes' group of patches. They are too serious to move them to
> TODO list, yet too complex and/or rare to move on. And such entries
> simply move from one CF to another.

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.

regards, tom lane