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

Re: [PATCH] Psql List Languages

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Psql List Languages
Date: 2009-07-23 02:11:00
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Wed, Jul 22, 2009 at 9:43 PM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jul 22, 2009 at 9:35 PM, Greg Stark<gsstark(at)mit(dot)edu> wrote:
>> On Thu, Jul 23, 2009 at 2:23 AM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>>> If you would like to have this change committed during this
>>> CommitFest, please submit an updated patch ASAP.  Otherwise, you can
>>> resubmit for the next CommitFest in September.
>> You know, I don't think we have any rules against people responding to
>> patches submitted outside commitfest periods...
> I never suggested otherwise.  In fact, I think it works much better
> when people DO respond to patches submitted outside CommitFests.
> What's your point?

To follow up on that thought a little more...

The patch author is certainly free to resubmit the patch at any time,
and Peter (or any other committer) can commit it at any time, and may
well do so.  However, as far as the CommitFest process is concerned,
we need to wrap things up within a finite time period that is not very
long, and that can only happen if both reviews and resubmits happen in
a timely fashion, so, since I've been tapped to manage this
CommitFest, I'm trying to do what I can to keep on top of that.

If my email struck you as rude, I certainly apologize for that.  I'm
trying really hard to be efficient about this without stepping on
anyone's feelings, but that's a fine line to walk and I'm not sure
I'll always be on the right side of it.

Also, as a practical matter, while patches CAN get committed at any
given time, one of the purposes of CommitFests, at least AIUI, is to
give reviewers and committers a break from dealing with other people's
patches.  In other words, when it is NOT time for a CommitFest, as Tom
put it, people shouldn't feel guilty about working on their own
patches rather than reviewing.  When it IS time for a CommitFest, they
should.  So the time when patches are *most likely* to be committed is
during a CommitFest, and that is why I think there would be a benefit
to the author of this patch in resubmitting it soon.

I am trying to introduce something of a procedural change from the
last CommitFest in that I think that the deadline for any particular
patch to be resubmitted should be based at least in part on when it
was reviewed, and not just on how many days we "have left" in the
CommitFest, to avoid a huge pile of resubmissions just before some
arbitrary cutoff, which then creates an unsupportable burden for
reviewers and committers, or else just makes the CommitFest drag on
and on.  I think that's pretty reasonable.  In fact, it's far MORE
reasonable than what we did last time, where patches that got reviewed
early sat around and were resubmitted at a very liesurely pace over a
period of months, while other patches that got reviewed late got
looked at once (or maybe twice) and then punted.

Hopefully that seems reasonable - if not, let's discuss (perhaps after
changing to a new thread).


In response to


pgsql-hackers by date

Next:From: Greg SmithDate: 2009-07-23 02:23:38
Subject: Re: multi-threaded pgbench
Previous:From: Andrew DunstanDate: 2009-07-23 02:02:34
Subject: Re: join regression failure on cygwin

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