Re: damage control mode - Mailing list pgsql-hackers

Peter,

> Just to clarify: I am for sticking to the agreed dates.  If some things
> are not ready by the necessary date plus/minus one, they won't make the
> release.  If it's obvious earlier that something won't make the date, it
> shouldn't be committed, and maybe put on the backburner right now.  But
> AFAICT, that's independent of when it was submitted.  Some things that
> were submitted just the other day might be almost ready, some things
> that were first submitted many months ago are still not ready.

In that case, Robert's comments about patches to bounce on Day 1 of the
commitfest are still valid, regardless of "patch size".  That is, if
we're getting patches which seem very unlikely to make the cut by
Feburary 15 (like KNNGiST, which currently doesn't even apply), then it
makes sense for the CFM to notify those authors as soon as possible that
their patch is probably last in line to get reviewed.

(btw, I'd have prefered the "no large patches" rule, but it did not get
a firm consensus)

In any case, the CFM has sole authority for allocating the efforts of
reviewers who volunteer for assingment (the RRR).  So the CFM can
certainly assign people to review only on patches they think will make
it, and leave high-risk patches for last.

For example, if I were Robert, I probably wouldn't assign any RRR to
KNNGiST until all patches with a high chance of commit were clear.  Of
course, if the PostGIS community got motivated and put Paul and others
on reviewing it to get it through, then great.  Not every reviewer cares
about all patches equally.

That's completely aside from the concept of "owing" anyone a review.
The last commitfest is really about, "what can we get committed for
8.5?"  This would be the main difference between the last commitfest and
the other 3; during the other commitfests we can afford to devote
resources to reviewing patches just because someone has been a "good
hacker"; in CF4, we really have to be pragmatic about what's going to
make it in, or not.

I'll also say: if we can't make time-based releases work, we're probably
dead as a project.  MySQL and Ingres both tried feature-based releases,
and look where they are now.

--Josh Berkus