On Wed, Jul 1, 2009 at 6:55 PM, Bruce Momjian<bruce@momjian.us> wrote:
> bruce 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 early would not have significantly
>> moved the release date earlier.
>
> I see no one agrees with my analysis --- no matter; if I unreservedly
> agreed with others, I wouldn't be here. ;-)
>
> There has been discussion about how to be more hard-nosed about
> rejecting patches. I think it has to start with us being more
> hard-nosed about giving patches feedback --- the very idea we had to
> create commit-fests reflects that we historically have not done an
> organized job of processing patches.
Agreed.
> If we review patches as soon as they appear, and give rapid feedback, we
> can easily reject patches that take more than a few days for the patch
> author to resolve, and there would be little slippage; the same goes
> for dealing with known bugs. I know it can be done, but I don't promise
> it would be pleasant.
Also agreed. It's never pleasant to have a patch rejected/postponed,
but it's tolerable if you've gotten some feedback and understand the
reasons why. Of course there is no guarantee that you will agree with
those reasons, but that's life. Some day you may be the committer and
have your turn to irritate patch submitters. :-)
...Robert