Re: next CommitFest - Mailing list pgsql-hackers

On Fri, 2009-11-13 at 10:26 +0000, Dave Page wrote:
> On Fri, Nov 13, 2009 at 8:50 AM, Simon Riggs <simon@2ndquadrant.com> wrote:
> >> What about people who contribute hours and hours of their time in
> >> other ways? Are they required to contribute even more of their time to
> >> review as well, just to help their own occasional code contributions
> >> get through the process?
> >
> > Yes, but the rule needs to be hard for a few reasons. If your employer
> > encourages you to write a patch then they need to be made aware that you
> > must also do all the other things too: write docs, supply tests, explain
> > it *and* include review time. Since reviewing your own patch isn't
> > possible, we must require patch review of other's patches. The rule is
> > deliberately hard on the contributor to ensure the sponsor understands
> > the rule and allows more time.
> 
> Which is fine for sponsored patches, but my employer doesn't sponsor
> me to hack on PostgreSQL directly - we have other staff that are far
> more capable of doing that :-). My annual submissions are for my own
> personal development/enjoyment/whatever, and are never chosen for my
> employer, but because they seem interesting, are common requests from
> users, or would help pgAdmin provide improved functionality for users.
> 
> The bottom line is, if I'm required to review patches, it will impact
> on other community work, which I am almost certainly more qualified to
> do and would be more productive at.
> 
> That said - in general I don't disagree with the idea of everyone
> chipping in, and I do try to do so myself on appropriate patches (for
> example, the recent Windows DACL bug fix which I spent a few hours
> reviewing and testing - and am still waiting for Magnus to commit
> :-p). I just think that *requiring* people to review will ultimately
> be counter productive.

Requiring people to write docs or any other patch submission rules has
never been counterproductive. People could easily say, "English is not
my first language, therefore I skip all comments and docs". But they
don't, because we require that, as a hard rule. Nobody has ever said
enforcing *those* rules is counter productive. I don't see why adding
new requirements would be a problem - especially since they aim to
address problems with the flow of patches. Change will always seem
strange, but just like commitfests themselves the new way of working has
been quickly adopted without much complaint. Bottom line is if we all
spend all of our time developing and no time reviewing, then we
shouldn't be surprised if there is a review bottleneck. Everybody wants
their patches to go through, and the *fastest* way is actually for
people to assist with review. We just need an easily understood way of
implementing that. The 1:1 suggestion is one way, there may be others.

-- Simon Riggs           www.2ndQuadrant.com