Re: CommitFest 2009-07: Closing Soon - Mailing list pgsql-hackers

From Robert Haas
Subject Re: CommitFest 2009-07: Closing Soon
Date
Msg-id 603c8f070908051202m5b0f004el21916cd51a8142bd@mail.gmail.com
Whole thread Raw
In response to Re: CommitFest 2009-07: Closing Soon  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Aug 5, 2009 at 1:43 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> Between now and then, I'm going to be working on identifying which
>> patches are not marked as "Waiting on Author" but should be, or which
>> are marked as "Waiting on Author" but shouldn't be.
>
> Er, shouldn't you first work on finishing your own patches?  The EXPLAIN
> output patch is still "Waiting on Author" ...

Well, I'm hoping those are not mutually exclusive.  Figuring out what
is waiting on author shouldn't take more than about a half hour each
of the next two nights, and the EXPLAIN output patch doesn't need more
than another hour or two of work to address the feedback given thus
far.

However, hypothetically speaking, if I *don't* manage to finish that
patch up in the next two nights, I don't see why it should be treated
any differently than any other patch that isn't ready to go.  Unless
you think that patch is so important that it's worth holding up the
entire CommitFest for?  But I'm assuming that isn't the case.

It's important to me not to create the impression that I am giving
special treatment to my own patches.  I am trying to handle them in
the same way that I would handle any other patches (well, except that
I nag myself internally, rather than sending myself an email and
copying -hackers).  Of course, being me, it's hard for me to be
absolutely certain that I'm actually doing that, but for the record,
that's what I'm attempting to do.

One problem that I've run into during this process is that I submitted
a LOT of patches - I believe 11 of 71 patches in this CommitFest are
mine, and I'm also trying to do high-level management of the entire
CommitFest.  That's made it really hard for me to do anything like the
amount of reviewing I did for the last CommitFest.  It doesn't seem
quite fair that I'm submitting more patches and reviewing fewer of
other people's, but I don't know what to do about it.  Not working on
the patches that I've submitted slows down the CommitFest just as much
as working on them does, only for different reasons.  Fortunately, we
had enough reviewers anyway: I think that nearly every patch that
wasn't already claimed by a committer got a review pretty quickly.

Still, I'd welcome any suggestions on how to balance this better.  At
some point, maybe after this CommitFest is done, it might be good to
have a postmortem on what people thought worked well/poorly and
suggestions for improvement next time around.

> I'm going to go ahead and commit the dict_xsyn patch.  There isn't
> anything obviously wrong with it, and although I'd have preferred to
> get Teodor's input, he's evidently too busy with other work to comment
> on it.

Works for me.

...Robert


pgsql-hackers by date:

Previous
From: Leonardo Cezar
Date:
Subject: log shipping and nextval sequences
Next
From: Robert Haas
Date:
Subject: Re: GRANT ON ALL IN schema