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
Views: Raw Message | Whole Thread | Download mbox
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>

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message August Zajonc 2007-03-29 17:49:06 Re: Patch queue concern
Previous Message Bruce Momjian 2007-03-29 17:40:13 Re: Patch queue concern