Alvaro Herrera wrote:
>> 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?
As I understand it, vpath builds only do a checkout to a single place,
and then build against that (from a different directory). Non-vpath
builds take a copy of the checked out source and build in the copy. If
we patched the source in vpath builds, the patch would stick around when
updating the source tree from CVS, and the next patch attempt would fail
etc. Non-vpath builds will get a clean copy to patch in subsequent runs.
I suppose I could have made vpath builds take a copy when doing a patch,
but it hardly seemed worth it.
> Well, I'd think that one important benefit of passing patches through
> the buildfarm is detecting possible portability problems in it.
Absolutely. As long as they're blessed as mention below...
> 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.
This was where I was originally heading when I first thought about this
functionality. I didn't go that far with my fairly modest patch since a)
it wasn't clear that there was manpower available to do the initial
review to bless the patches, and b) what I did do solved my immediate
problem.
If there is support for doing something like this, there are all kinds
of things that could be done. For example, you could check which patches
break which other ones. An even more way-out idea might be to have
performance patches run pgbench or some other set of benchmarks. You
have a performance related patch? Let's stick it in the queue and see if
it really improves things or not.
Note that the existing patch queue mechanism wouldn't suffice, since
there's no standard way to pull patches through via http or whatever.
We'd probably want to back it with a small database and webapp, which
might just be a hacked buildfarm server.
Cheers
Tom
