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

Re: Patch queue concern

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(at)2ndquadrant(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch queue concern
Date: 2007-03-29 17:48:43
Message-ID: 200703291748.l2THmhb05475@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Gregory Stark wrote:
> 
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> 
> > "Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> >> My feeling is we should have more regular sync points where the patch
> >> queue is emptied and everything committed or rejected.
> >
> > No doubt, but the real problem here is that reviewing/committing other
> > people's patches is not fun, it's just work :-(.  So it's no surprise
> > that it tends to get put off.  Not sure what to do about that.
> 
> Obviously a big part of that is that we just don't have enough committers. I'm
> hopeful that in time that situation will improve but in the meantime we do
> have a problem and the burden falls unfairly on a few.
> 
> Is there anything others can do to help? If non-committers like Simon or I
> reviewed patches would it be easier for you to give a quick agreement to the
> comments or "that's not an issue" comment?

Just to clarify, the committing is the easy part.  I can do that all day
and not break a sweat.  It is making sure the patch is correct in all
aspects --- functionality, clarity, modularity, reliability, design,
etc. that takes lots of time, and really can be done by anyone in the
community.  We already have people commenting on other peoples patches,
and new versions appearing, and every new version makes the final job of
review/commit easier, because someone was going to have to make those
changes before the patch was applied.

> It seems like we do have a few committers who should be able to review code
> quality but are uncertain about making major design decisions. If, for
> example, Bruce or Jan reviewed patches more invasive than they usually do for
> code quality and checked with you on design questions would that be helpful?

I wish that would work, but the big trick is getting the entire problem
into your head, matching user behavior with our existing code, and
making those link up.  There is really no _stage_ nature of final patch
review.  People can still comment on the patch, and improve it, but the
final decision has to be a holistic one that makes sure the entire
patch is in harmony.  (I am sounding new-age here.  :-) )

You might remember during I think 8.1 I started pushing patches because
no one was objecting to the patches, and people complained because the
patches we not complete.  The patches had problems, but I was unable to
fully understand some of the patches, and the patches had to be backed
out.  Since then, I haven't applied anything I didn't fully understand,
so the patches not languish in the patch queue until an experienced
PostgreSQL developer who does fully understand them can give me a green
light on it.

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>          http://momjian.us
  EnterpriseDB                               http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

In response to

pgsql-hackers by date

Next:From: August ZajoncDate: 2007-03-29 17:49:06
Subject: Re: Patch queue concern
Previous:From: Bruce MomjianDate: 2007-03-29 17:40:13
Subject: Re: Patch queue concern

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