On Thu, Mar 29, 2018 at 10:37 AM, Alexander Korotkov < a.korot...@postgrespro.ru> wrote:
> On Thu, Mar 29, 2018 at 11:19 AM, Magnus Hagander <mag...@hagander.net> > wrote: > >> On Thu, Mar 29, 2018 at 10:06 AM, Alexander Korotkov < >> a.korot...@postgrespro.ru> wrote: >> >>> Hi, Fabien! >>> >>> On Fri, Dec 1, 2017 at 9:10 AM, Fabien COELHO <coe...@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.. > > Yes, there is (stalled, but still) work in progress on that one. I think that's a separate thing though. -- Magnus Hagander Me: https://www.hagander.net/ <http://www.hagander.net/> Work: https://www.redpill-linpro.com/ <http://www.redpill-linpro.com/>
