Re: 8.5 development schedule

On Tue, Jun 30, 2009 at 11:18 PM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
> Tom Lane wrote:
>> > As for thresholds, I'd propose that we measure the size of patches
>> > using "diff -u | diffstat".  If the number of insertions plus the
>> > number of deletions is >= 1000, then the patch is not eligible for the
>> > final CommitFest unless it was submitted for the penultimate
>> > CommitFest.  This obvious discriminates against patches with a large
>> > footprint that are not very invasive and in favor of those with a
>> > small footprint that are more destabilizing, but it's a clean line in
>> > the sand, and I think having such a line is better than trying to
>> > apply human judgment to every case.
>>
>> Well, in the end it will come down to committers' judgements anyway;
>> if someone thinks a patch is ready it will probably go in, regardless
>> of size.  But this gives us another tool for saying "no", so I'm
>> agreeable ;-)
>
> 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.

I don't believe it. :-)

If the large patches had been rejected earlier, the reviewers and
committers who were spending time on them could have started spending
time on other things sooner.

I also believe, although I cannot prove it, that it would have
increased the pressure to get the remaining items dealt with. When
there are 100 patches, everyone can say "oh, well it doesn't matter
whether I get this taken care of today, because there will still be 99
other patches". When there are 3 patches, that argument doesn't hold
water.

Another thing I'd like to improve for the next CommitFest is the
communication between reviewers and committers. In the November
CommitFest, I, and I think others, assumed that the committers were
reading all of the review threads in detail throughout the process and
that they would jump in when things got close to being done, or maybe
when things got marked as Ready for Committer on the Wiki. That
worked OK, but there were rough patches where things bogged down. As
much as we may express opinions on the merits of certain patches, I
think all of us non-committers are (certainly I am) loathe to avoid
the perception that we're telling the committers what to do. But, I
think it would be helpful to have periodic updates on what the
different committers are currently focused on, how long they intend to
be focused on that, and what they intend to focus on next; and I think
it would be helpful for the CF mgmt team to make suggestions as to
what patches we think are the closest to being ready to go or most in
need of committer-level input.

...Robert