Robert Haas <robertmhaas@gmail.com> writes:
>> I agree with trying to cut down the submission-to-commit delay, but
>
> It seems to me that the CommitFest process is pretty darn effective at
> reducing the submission-to-commit delay, except when you miss the last
> one for the release - then it sucks hard.
Too bad we can't have a release management team (with committers,
testers, advocacy, doc writers, etc) taking care of the beta to release
road while the first commit fest(s) for next release happen in parallel.
It would move the primary goal of a commit fest from committing patches
to reviewing them (return with feedback or stamp ready for a committer),
reducing the chances that anyone will have some time to handle the last
step.
But that would allow say 6 commit fests per year, even if 2 of them
would in fact be (almost) review-only fests.
You could say that those 2 extra fests will only pile up more work to do
for committers once they're back from release management, but actually
that's already what happens:
- the first 8.5 commit fest had a lot of patches never reviewed
- the 3rd commit fest for 9.1 would instead have plenty of ready to commit patches
- authors that happen to have the bad luck of only having time to devote to PostgreSQL between beta and release would
stillenjoy a timely patch review, if not commit.
Regards,
--
dim
