On 22 January 2016 at 05:07, Noah Misch <n...@leadboat.com> wrote:

> 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.
> nm
> [1]
> https://wiki.postgresql.org/index.php?title=PostgreSQL_9.5_Open_Items&limit=500&action=history

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

Reply via email to