Re: Patch queue concern - Mailing list pgsql-hackers

Gregory Stark wrote:
> "Bruce Momjian" <bruce@momjian.us> writes:
> 
> > Right now, all the patches I think are ready for review are in the patch
> > queue:
> >
> >     http://momjian.postgresql.org/cgi-bin/pgpatches
> >
> > However, with feature freeze coming on Sunday, I am worried because
> > there are a significant number of patches that have are not ready for
> > review because they have not been completed by their authors.
> 
> That seems like a bit of a whacky criterion to use before reviewing a patch.

"wacky"?

> It favours people who are short-sighted and don't see what possible
> improvements their code has. No code in an ongoing project like this is ever
> "completed" anyways.

It favors those who do not wait until the last minute, but complete them
well before the freeze date.

> It's also an artifact of the working model we have where patches are sent in
> big chunks and reviewed much later during a feature freeze. If we were
> committing directly into a CVS repository we would have wanted to commit these
> changes as soon as they were ready for committing, not wait until they're
> "completed". Then continue working and commit further changes. It's only

This would have CVS containing uncomplete features --- and before beta,
we would either have to beg the authors to complete them, or rip them
out, neither of which we want to do.

> because there's a two step process and the reviews are mainly happening during
> the feature freeze that there's any sense that some of them are "completed".
> In fact they're not of course, there will be further changes in the same area
> once the freeze is lifted.
> 
> I think you should be asking people whether they think the code is in a state
> where it can be committed, not whether they've finished working on it. Just
> because they see further work that can be done is no reason not to commit
> useful patches that are functional as they are.

OK, but we don't want something that is ready to be committed, we need
it complete.

> In fact Postgres historically has had an even looser standard. If the code is
> ready to be committed modulo bugs then it's been included in the feature
> freeze in the past.

Well, if we know something has bugs, we fix them.  Things are committed
with bugs only because we don't know it has bugs when it was committed.

--  Bruce Momjian  <bruce@momjian.us>          http://momjian.us EnterpriseDB
http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +