Hi, hackers!
I want to share some stats and thoughts about 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.
***
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.
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.
I wonder if we can improve the workflow somehow? Todo list was recently
cleaned up, so maybe we can use it? Or we could add a special 'Backlog'
section to the commitfest application.
What do you think?
***
I am also planning to update the CommitFest Checklist:
- remove references to pgsql-rrreviewers;
- add info about cfbot;
- remove the 'Sudden Death Overtime' chapter as it no longer reflects
reality.
Thoughts?
[1]
https://wiki.postgresql.org/wiki/CommitFest_Checklist#Sudden_Death_Overtime
<https://wiki.postgresql.org/wiki/CommitFest_Checklist#Sudden_Death_Overtime>
--
Anastasia Lubennikova
Postgres Professional:http://www.postgrespro.com
The Russian Postgres Company
