Re: Last gasp - Mailing list pgsql-hackers

Tom Lane <tgl@sss.pgh.pa.us> writes:
> Andres Freund <andres@anarazel.de> writes:
>> They might have been half-baked. But several of those didn't get design-level
>> review for several weeks which makes it rather hard to fully bake them in 
>> time...
>
> But if they didn't already have design-level review, that means they
> were not seen in any previous CF, which means they were not following
> the expectation that nontrivial patches should be submitted earlier than
> the last CF.

That's not true, unfortunately.

I had several rounds of design review in the previous CF, then some more
in the last CF, then another one that basically meant baking another
patch: same feature but spelled out differently (renaming catalog, files
and APIs is no fun in a big patch) to be able to have a new way to
organize the code and docs. It's for the best, and it's better to do
that before commit, no question. I appreciate having had that review,
really.

The problem with the command trigger has been another one. First, if we
want the last CF to be only about commits and not about feedback, we
should simply bite the bullet and spell it out loud. Second, we should
have been talking about the hard decision rather than pretending we
could still do something in this release. That's mainly on me and I know
it, but not being a commiter I have no other power than influence, and
I've been optimistic (and playing by the rules).

> I think the key point here is that people have to expect that it's going
> to take more than one round of review to land most nontrivial patches.
> And we have to discourage the expectation that that can happen within
> the last CF of a release cycle.  If anything, the last CF has to be
> tighter not looser than others on what we will accept, because there is
> no time to recover if something proves wrong with a patch after a
> month or three.

The more I think about that, the more I think we should declare the last
CF to be about preparing a release, not providing another round of
feedback. That could well be all we need here.

> I keep coming back to the thought that we need more and shorter CFs,
> and/or ReviewFests that are meant to help push WIP patches further
> down the track.  We need to make it easier to get those early reviews
> done while there's still development time left.

Separating away commit fest made for commits and those meant for
feedback is a good idea too. I'm not sure how much benefit we would get
there for non-last CFs, though.

Regards,
-- 
Dimitri Fontaine
http://2ndQuadrant.fr     PostgreSQL : Expertise, Formation et Support