Re: 8.5 development schedule

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I agree. On the other hand, I think all of the proposed schedules are
> somewhat optimistic about how long the final release will take. We
> started the final CommitFest for 8.4 on November 1st and are set to
> release July 1st. The proposed schedule for next time involves
> starting the final CommitFest three months later and releasing two
> months earlier. I'd like to think that with a little more discipline
> around CommitFests we can tighten things up a little, but it seems
> excessively optimistic to think that we're going to cut down from
> seven months to two.

Yeah. What I think the 8.4 cycle taught us is that commitfests are a
good thing but they won't magically eliminate the need to say "no" at
the end. If we are willing to be sufficiently hardnosed about saying
"no", we can make the final commitfest short. Otherwise it's going to
drag on just like this one did.

Keeping the final-CF-to-release period short is desirable for the
reasons already mentioned --- we don't want to shut down development
for a long period. So even if it's optimistic, I think we should
write the schedule that way. We can be certain that the period won't
last *less* time than scheduled :-(

> I would propose to start CommitFests July 15th, September 15th,
> November 15th, and January 15th, planning all but the last to be one
> month long. The last CommitFest I would plan on closing up by March
> 1st, with release hopefully by June 1st.

Hmm. If we drop the notion that CFs have to start on month boundaries,
that's actually not a bad schedule --- in particular, it keeps us away
from expecting much of anything to get done in the last half of
December. I'd suggest setting the target release date to May 15
(pre-PGCon), as long as we're working with ides-of-whichever dates.

> As for thresholds, I'd propose that we measure the size of patches
> using "diff -u | diffstat". If the number of insertions plus the
> number of deletions is >= 1000, then the patch is not eligible for the
> final CommitFest unless it was submitted for the penultimate
> CommitFest. This obvious discriminates against patches with a large
> footprint that are not very invasive and in favor of those with a
> small footprint that are more destabilizing, but it's a clean line in
> the sand, and I think having such a line is better than trying to
> apply human judgment to every case.

Well, in the end it will come down to committers' judgements anyway;
if someone thinks a patch is ready it will probably go in, regardless
of size. But this gives us another tool for saying "no", so I'm
agreeable ;-)

regards, tom lane