Skip site navigation (1) Skip section navigation (2)

Re: CommitFest status/management

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CommitFest status/management
Date: 2009-12-01 03:16:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Bruce Momjian wrote:
> So, if someone writes a patch, and it is reviewed, and the patch author
> updates the patch and replies, it still should be reviewed again before
> being committed?
That's generally how things were expected to happen--to at least 
double-check that the proposed fixes match what was expected.  I don't 
think it was spelled out very well in the past though.

> Also, we are two weeks into the commit fest and we have more unapplied
> patches than applied ones.
Considering that one of those was a holiday week with a lot of schedule 
disruption proceeding it, I don't know how much faster things could have 
moved.  There were large chunks of the reviewer volunteers who wanted 
only jobs they could finish before the holiday, and others who weren't 
available at all until afterwards.  And I don't know about every else, 
but I took all four days off and started today behind by several hundred 
list messages.  I was planning to start nagging again tomorrow, hoping 
that most would be caught up from any holiday time off too by then.

Right now, of the 16 patches listed in "Needs Review" besides the ECPG 
ones Michael is working through, the breakdown is like this:

Not reviewed at all yet:  6
Reviewed once, updated, waiting for re-review:  10

So the bulk of the problem for keeping the pipeline moving is in these 
re-reviews holding up transitions to "Ready for committer".  I've had 
some discussion with Robert about how to better distinguish in the 
management app when the reviewer has work they're expected to do vs. 
when they think they're done with things.  We're converging toward a 
more clear set of written guidelines to provide for managing future 
CommitFests as part of that, right now there's a few too many fuzzy 
parts for my liking.

If the need here is to speed up how fast things are fed to committers, 
we can certainly do that.  The current process still favors having 
reviewers do as much as possible first, as shown by all the stuff 
sitting in the re-review queue.  The work we're waiting on them for 
could be done by the committers instead if we want to shorten the whole 
process a bit.  I don't think that's really what you want though.

Greg Smith    2ndQuadrant   Baltimore, MD
PostgreSQL Training, Services and Support

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2009-12-01 04:03:00
Subject: Re: CommitFest status/management
Previous:From: Tom LaneDate: 2009-12-01 03:13:10
Subject: Re: A thought about regex versus multibyte character sets

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group