Re: Releasing in September

On Wed, Jan 20, 2016 at 1:29 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> On 2016-01-20 13:13:29 -0500, Robert Haas wrote:
>> (3) Andres's multixact reworks landed quite late and IMHO were not
>> safe enough to back-patch, yet they needed to be in the release. In
>> my view, the last major fix for
>
> At least in that case I was, for a long while, basically hoping for more
> input, probably unwisely so. I think the 9.4 jsonb compressability thing
> essentially was in a somewhat similar state for months; the proposed
> patch was mostly there, but we didn't press ahead. I think deadlines
> and multiple people being blocked help tremendously with such issues.
> They're often too complex for an individual and/or delayed due to lack
> of concensus.

True.

>> But if we end up waiting just as long but with nothing substantial
>> getting committed in the meantime, that will be awful.
>
> That's true. Which I think means that we'll need to be agressive in
> threatening reverts in such cases. That wouldn't have worked for 3), but
> in the other two cases it'd have been doable.

Yes. One problem is that it's very hard to get a patch reverted. Tom
opined that too often patches roll along toward commit and that it's
too hard to say "no, we want that". But that's nothing compared to
how hard it is to get a patch reverted. It's true that, if Tom calls
for the revert, it more often than not happens, but nobody else can
really pull that off without a major war.

And, you know, I did my time fighting major wars to try to compress
the release schedule, and honestly, it wasn't that much fun. The
process we have now is imperfect in many ways, but I no longer have
abuse heaped on me for wanting to boot a patch out of a CommitFest.
That may be bad for the project, but it's spared me a lot of grief
personally. I think that many other people are in the same situation.
Everybody would like somebody else to be the schedule enforcer ...
unless they have something that they still want to get in, in which
case they would like nobody to do it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company