Jim C. Nasby wrote:
> There's been talk in the past of having some kind of system that
> automatically attempts to build things that are in the patch queue, both
> as an initial sanity-check and as a means to detect when something
> bit-rots... perhaps it's becoming worthwhile to set that up.
After writing the enum patch, I hacked the buildfarm client code to
apply a patch to the checked out code before building. You could then
run it thusly:
./run_build.pl --nosend --nostatus --verbose \ --patch=/home/tom/src/enums-v1.patch --patch-level=1
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.
Note that it was intended for patch authors to run themselves rather
than any kind of central mechanism to test the patch queue. 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.
I had thoughts of hacking the buildfarm server to allow the posting of a
patch along with results, so that authors could report results for their
own patches, but ran out of time. Is there interest in doing that?
Obviously it'd be a different server to the existing buildfarm.
Cheers
Tom
