On Wed, Jan 20, 2016 at 06:58:24PM +0000, Simon Riggs wrote: > The main problem is the length of the integration phase, which is mostly > where nothing happens.
The open items wiki page saw steady change from 30 April to 28 December[1]; the two longest quiet periods were an eleven-day gap from 21 August and a nine-day gap from 16 December. Nineteen distinct contributors were finding, fixing or otherwise editing data about 9.5 defects. The integration work is too slow, yes, but this persistent myth of a dead period is false.
For my part, I spent 1 July to 11 December reviewing 9.5 commits and reporting or fixing defective 9.5 work. (I did spoil myself with a few breaks fixing pre-9.5 bugs.) I doubt the 9.5 new bugs would have run dry within the next five months, either, but the release team picked a fair juncture to give up and call it dot-zero.
Thanks for explaining that, and thanks for that work. Had I known you were doing that I wouldn't have said "nothing happens".
What I do observe is that we have N developers writing patches, C committers committing patches and R people reviewing things during the integration phase.
N > C > R so that N >> R
Meaning that during the integration phase our parallel efficiency drops significantly, but as you say, not to zero. Given that the integration phase is frequently at least as long as the development phase we end up operating at about 0.5-0.6 of maximum efficiency. I would like to improve on that, if possible.
I'll do what I can to shorten the integration phase, including the prioritization/triage step I volunteered for, applied to the last CF.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
