Re: Triaging the remaining open commitfest items

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Triaging the remaining open commitfest items
Date: 2015-05-15 19:32:58
Message-ID: 555649EA.9030600@agliodbs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 05/14/2015 03:58 PM, Bruce Momjian wrote:
> On Thu, May 14, 2015 at 06:57:24PM -0400, Tom Lane wrote:
>> Stephen Frost <sfrost(at)snowman(dot)net> writes:
>>> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
>>>> I will call for a vote that the freeze deadline be changed if this patch
>>>> is rejected to due to time. I might lose the vote, but I am going to
>>>> try because if we lose our reputation for fairness, we have lost a lot
>>>> more than a week/month of release time.
>>
>>> I'm guessing the vote is core-only, but +1 from me in any case. I fully
>>> agree that this patch has had a serious measure of effort put behind it
>>> from the author and is absolutely a capability we desire and need to
>>> have in core.
>>
>> I should think we'd have learned by now what happens when we delay a
>> release date to get in some extra feature. It hasn't worked well in
>> the past and I see no reason to believe the results would be any more
>> desirable this time.
>
> Right, the importance of the feature is not a reason to delay the
> feature freeze.

It has nothing to do with the importance of the feature. It has
everything to do with fairness.

Regardless of what Tom did or didn't do, what we have here is a major
feature patch which was submitted in a timely fashion, and then *not
reviewed* for multiple commitfests, and now in danger of being bounced
because it's "late". Considering that many other things have been
committed which were submitted significantly later than Grouping Sets,
including some which have been committed with the acknowledgement that
there is more work do do during beta, this would have the appearance of
being prejudicial against Gierth. Grouping Sets has been working, at
least in demo form, since November.

I really don't think we can, as a project, afford to have the appearance
of prejudice in the review process. Things are bad enough already; if
contributors feel that the review process is blatantly unfair, they will
resort to underhanded means to get their patches in, and things will
break down completely. We're only holding stuff together despite short
resources because contributors believe in the inherent fairness of the
process and the committers and that scarce resources will be allocated
evenly.

Note that I am not proposing a general delay in feature freeze. I am
specifically proposing an additional week for Grouping Sets and *only*
for Grouping Sets.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Berkus 2015-05-15 19:35:50 Re: PATCH: adaptive ndistinct estimator v4
Previous Message Tom Lane 2015-05-15 19:18:26 Re: Patch for bug #12845 (GB18030 encoding)