Re: 8.5 development schedule - Mailing list pgsql-hackers

On Wed, Jul 1, 2009 at 10:30 AM, Kevin
Grittner<Kevin.Grittner@wicourts.gov> wrote:
> Bruce Momjian <bruce@momjian.us> wrote:
>> I realize there is the perception that the large patches that were
>> eventually rejected held up the release, but for all the patches I
>> can think of, they were not rejected immediately _because_ we had
>> other valid patches to work on.  Once all valid patches were
>> applied, we were quickly able to reject the large unready patches.
>>
>> So, rejecting the large patches earily would not have significantly
>> moved the release date earlier.
>
> Like Robert, I'm extremely skeptical of this claim, for the same
> reasons.
>
> However, even the *possibility* that this could be true is pretty
> scary.  If we need to effectively shut down new development for seven
> months at the end of a release, in addition to the interim commit
> fests, we'd better get a handle on why, so that can change.  To what
> do you attribute the extended time needed to handle the final CF?
> How can that be made better?

Hear, hear!

Tom wrote upthread:
# If you find yourself with nothing else to do except review a new patch
# during beta, then sure, go do it.  But is there *really* nothing you
# could be doing to help expedite the beta?

My honest answer to this question is that I have no idea. It was
pretty clear to me what I was supposed to be doing during CommitFest
(reviewing patches) but a lot less clear to me what I should be doing
during beta.  I know that there was an open items list, but it was
never really clear to me how I should help with that.   A lot of the
open items were pretty mushy, subjective issues, or that was how they
seemed to me - not so much "How are we going to fix this?" but "Is
this worth fixing?" and "What kind of fix is appropriate?".  IOW, what
they needed before any useful technical work could be done was
consensus.

Of course, both committers and non-committers need consensus to make
changes, but committers need a lot less consensus.  If no one strongly
objects, they just apply.  Non-committers, on the other hand, need the
affirmative support of a committer to actually perform the commit.
It's a lot easier to get to "no one things this is a really bad idea"
than it is to get to "one of these six people thinks this is a good
idea and that person is willing to devote an hour of their day (or
more) to making it happen".

It seems to me that the solution to this problem is pretty simple.
Committers need to say exactly what kind of help they want; they need
to affirmatively tell other people what to do.  If Tom wants someone
to develop a patch for bug XYZ, he should say that he is prepared to
apply such a patch and ask for volunteers.  That helps path authors in
three ways:

1. Prospective patch authors know that Tom thinks this is important
and that it could hold up the release.
2. Prospective patch authors know that this isn't something that Tom
is already working on.
3. Prospective path authors know that they have a good chance of
getting something applied quickly, without waiting 1-7 months for the
next CommitFest.

I think committers are reluctant to do this for fear of being seen as
pushy, or for fear of being seen to use their status as committers as
way to throw their weight around.  In fact, I've heard more than one
committer make statements of the form, well, we don't really have any
more weight to throw around than anyone else.  The problem with this
is that it's blatantly false, and no non-committer who has taken the
time to write a patch is under any contrary illusion.  If a hamster
and an elephant are trying to sit on the same bench, the hamster does
not want the elephant to assert that he is a hamster; he wants the
elephant to announce his choice of seat prior to putting his bottom in
it.

...Robert