Re: ideas for auto-processing patches - Mailing list pgsql-hackers

From markwkm@gmail.com
Subject Re: ideas for auto-processing patches
Date
Msg-id 70c01d1d0701120853l506de559kb363a6be279d09eb@mail.gmail.com
Whole thread Raw
In response to Re: ideas for auto-processing patches  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: ideas for auto-processing patches
List pgsql-hackers
On 1/11/07, Andrew Dunstan <andrew@dunslane.net> wrote:
> markwkm@gmail.com wrote:
> >>
> >> I am not clear about what is being proposed. Currently buildfarm syncs
> >> against (or pulls a fresh copy from, depending on configuration) either
> >> the main anoncvs repo or a mirror (which you can get using cvsup or
> >> rsync,
> >> among other mechanisms). I can imagine a mechanism in which we pull
> >> certain patches from a patch server (maybe using an RSS feed, or a SOAP
> >> call?) which could be applied before the run. I wouldn't want to couple
> >> things much more closely than that.
> >
> > I'm thinking that a SOAP call might be easier to implement?  The RSS
> > feed seems like it would be more interesting as I am imagining that a
> > buildfarm system might be able to react to new patches being added to
> > the system.  But maybe that's a trivial thing for either SOAP or an
> > RSS feed.
>
> I'd be quite happy with SOAP. We can make SOAP::Lite an optional load
> module, so if you don't want to run patches you don't need to have the
> module available.
>
> >
> >> The patches would need to be vetted first, or no sane buildfarm owner
> >> will
> >> want to use them.
> >
> > Perhaps as a first go it can pull any patch that can be applied
> > without errors?  The list of patches to test can be eventually
> > restricted by name and who submitted them.
> >
> >
>
> This reasoning seems unsafe. I am not prepared to test arbitrary patches
> on my machine - that seems like a perfect recipe for a trojan horse. I
> want to know that they have been vetted by someone I trust. That means
> that in order to get into the feed in the first place there has to be a
> group of trusted submitters. Obviously, current postgres core committers
> should be in that group, and I can think of maybe 5 or 6 other people
> that could easily be on it. Perhaps we should leave the selection to the
> core team.

That's an excellent point; I didn't think of the trojan horse
scenario.  What do you think about setting up the buildfarm clients
with the users they are willing to test patches for, as opposed to
having the patch system track who is are trusted users?  My thoughts
are the former is easier to implement and that it allows anyone to use
the buildfarm to test a patch for anyone, well each buildfarm client
user permitting.

Regards,
Mark


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [pgsql-patches] [PATCHES] Patch to log usage of
Next
From: Andrew Dunstan
Date:
Subject: Re: ideas for auto-processing patches