Re: Commit fest 2017-11 - Mailing list pgsql-hackers

From Alexander Korotkov
Subject Re: Commit fest 2017-11
Date
Msg-id CAPpHfdtO63RhSZj0uL9uLUFLfN2D2_ZWiVVpj0Moyf2GNcT4NQ@mail.gmail.com
Whole thread Raw
In response to Re: Commit fest 2017-11  (Magnus Hagander <magnus@hagander.net>)
Responses Re: Commit fest 2017-11  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
On Thu, Mar 29, 2018 at 11:19 AM, Magnus Hagander <magnus@hagander.net> wrote:
On Thu, Mar 29, 2018 at 10:06 AM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
Hi, Fabien!

On Fri, Dec 1, 2017 at 9:10 AM, Fabien COELHO <coelho@cri.ensmp.fr> wrote:
And the last 21 patches have been classified as well. Here is the
final score for this time:
Committed: 55.
Moved to next CF: 103.
Rejected: 1.
Returned with Feedback: 47.
Total: 206.

Thanks to all the contributors for this session! The CF is now closed.

Thanks for the CF management.

Attached a small graph of the end status of patch at the end of each CF.

Thank you for the graph!
It would be interesting to see statistics not by patches count, but by their complexity.
For rough measure of complexity we can use number of affected lines.  I expect that
statistics would be even more distressing: small patches can be committed faster,
while large patches are traversing from one CF to another during long time.  Interesting
to check whether it's true...


I think that's very hard to do given that we simply don't have the data today. It's not that simple to analyze the patches in the archives, because some are single file, some are spread across multiple etc. I fear that anything trying to work off that would actually make the stats even more inaccurate. This is the pattern I've seen whenever I've treid tha tbefore.

I wonder if we should consider adding a field to the CF app *specifically* to track things like this. What I'm thinking is a field that's set (or at least verified) by the person who flags a patch as committed with choices like Trivial/Simple/Medium/Complex (trivial being things like typo fixes etc, which today can hugely skew the stats).

Would people who update the CF app be willing to put in that effort (however small it is, it has to be done consistently to be of any value) in order to be able to track such statistics?

It would only help for the future of course, unless somebody wants to go back and backfill existing patches with such information (which they might be). 

We have http://commitfest.cputube.org/ which automatically applies patches and runs
regression tests.  This tool is probably not handle all the cases.  In particular
it doesn't work when patchset in one thread is depending on patchset in another
thread.  But it would be definitely enough for statistics.

I also think we should eventually integrate functionality of http://commitfest.cputube.org/
into our commitfest application..

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company 

pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: [HACKERS] path toward faster partition pruning
Next
From: Simon Riggs
Date:
Subject: Re: Commit fest 2017-11