Re: small but useful patches for text search

On Mon, Mar 16, 2009 at 6:20 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> Robert Haas wrote:
>> On Mon, Mar 16, 2009 at 5:10 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>> > The earlier commitfests were not time-limited either. They lasted until all
>> > the patches were dealt with; either committed or bumped to next commit fest.
>> > It's just that when you know there still at least one more commitfest a
>> > couple of months ahead, everyone feels more happy to bump a patch and to
>> > have one's patch bumped to the next one. In the last one, it's a lot harder
>> > to do that because that means bumping to the next release, and you don't
>> > even know when the next commitfest is.
>> >
>> > The original plan was that anything not 100% ready to commit at the
>> > beginning of the last commit fest will be bumped to the next release, and
>> > beta would start right after the first commit fest, a week or two after the
>> > submission deadline. We failed to enforce that. In the next release cycle, I
>> > think we need to be more explicit about that policy throughout the release
>> > cycle and really enforce it.
>>
>> I mostly agree with this, but there is one fly in the ointment: if a
>> patch really hasn't been seriously looked at by a committer, bumping
>> it recreates one of the problems CommitFests were designed to avoid -
>> patch limbo.  I feel pretty good about the decisions to postpone Hot
>> Standby and SE-PostgreSQL (not that my personal opinion necessarily
>> counts for much, but that's how I feel); I would have felt less good
>> about it if the same decision had been made a month ago.  But on the
>> other hand that means 8.4 will be a month later.  If we could have
>> gone through the same process two months earlier, or if we could have
>> released 8.4beta and done those reviews on the side during the beta
>> period, that would have been best of all.
>
> Well, we have been working on stuff for the past month so it was not
> like we were waiting on SE-PG to move forward.

Stuff related to the CommitFest?

AFAICS, the only committer who has done any significant review or
committing of patches in the last month is Heikki, who extensively
reworked and then committed infrastructure changes for recovery on
February 18th (2 days shy of a month ago) and then extensively
reviewed Hot Standby and SE-PostgreSQL. It's really, really good that
those patches have finally received some extensive review, both
because now some version of each of them will likely make it into 8.5,
and because now we have only a handful of patches left that Tom has
said are pretty close to being committable. But I don't see how you
can say it didn't delay the release.

Frankly, if we'd rejected on January 1st all of the patches that (1)
were submitted on time, (2) had been reviewed in a timely fashion, and
(3) had not been resubmitted in largely committable form, we would
have bounced infrastructure changes for recovery, hot standby,
column-level privileges, autovacuum and reloptions, and probably
parallel restore. If the committers who subsequently worked to get
those changes into the tree had devoted an equal amount of effort to
what would have been left in the commitfest after so doing, we would
long since be done with this commitfest and into beta. But committers
are free to spend their time on the projects they think are most
interesting or which their employer is willing to pay them to work on,
so that didn't happen.

This is kind of understandable from the point of view of the
committers, and it's even sorta good for the project as a whole to the
extent that it prioritizes more interesting features over less
interesting ones, but it's pretty frustrating for non-committer
contributors. Any non-committer who pushes for a hard limit on the
length of the commitfest is taking the risk that next time the patch
that none of the committers are interested in will be theirs. So
nobody really wants to argue for that. But the alternative is to
argue that the commitfest should continue until all the patches have
gotten some reasonable minimum amount of review, and that means the
commitfest can continue for a very, very long time during which
non-committers can't expect to get any new patches looked at. That's
not very appealing either. The commitfest process really only works
if the committers review all of the patches submitted within some
reasonable period of time - if that isn't possible, there really isn't
going to be a satisfactory solution.

...Robert