Tom Dunstan wrote:
> The idea was that patch authors could either run it manually or stick it
> in a cron so they could get emailed when the patch no longer cleanly
> applied, or when the patched source failed in make, make check etc.
> Obviously my motivation was to keep the enum patch up to date until we
> hit 8.3 and someone looks at it. To that end it might also be useful for
> it to die if duplicate_oids finds anything.
>
> I submitted a patch to Andrew, but it needed a couple of tweaks
> (disabling patching on vpath builds, for example) and I don't think I
> ever got around to resubmitting it, but if there's more general interest
> I'll do so.
Huh, why would you disable patching on vpath builds?
> Note that it was intended for patch authors to run themselves rather
> than any kind of central mechanism to test the patch queue.
Well, I'd think that one important benefit of passing patches through
the buildfarm is detecting possible portability problems in it.
> While it would obviously be nice to know what the current status of
> any given patch in the queue is, the thing about the patch queue is
> that it contains patches that we haven't had time to review yet. It'll
> only take one patch to get into the queue containing a security
> vulnerability, or worse, a trojan, for it to seem unfortunate.
We could have a register of developers allowed to upload patches to the
"patched build queue", and have a policy that says that you should only
upload a patch if it has already passed some review.
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.