Re: ideas for auto-processing patches - Mailing list pgsql-hackers
From | markwkm@gmail.com |
---|---|
Subject | Re: ideas for auto-processing patches |
Date | |
Msg-id | 70c01d1d0701171835q282146dei1b5bcb7d2b85220d@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/17/07, Andrew Dunstan <andrew@dunslane.net> wrote: > markwkm@gmail.com wrote: > > On 1/12/07, Andrew Dunstan <andrew@dunslane.net> wrote: > >> markwkm@gmail.com wrote: > >> > 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. > >> > >> We can do this, but the utility will be somewhat limited. The submitters > >> will still have to be known and authenticated on the patch server. I > >> think you're also overlooking one of the virtues of the buildfarm, > >> namely that it does its thing unattended. If there is a preconfigured > >> set of submitters/vetters then we can rely on them all to do their > >> stuff. If it's more ad hoc, then when Joe Bloggs submits a spiffy new > >> patch every buildfarm owner that wanted to test it would need to go and > >> add him to their configured list of patch submitters. This doesn't seem > >> too workable. > > > > Ok so it really wasn't much work to put together a SOAP call that'll > > return patches from everyone, a trusted group, or a specified > > individual. I put together a short perl example that illustrates some > > of this: > > http://folio.dyndns.org/example.pl.txt > > > > How does that look? > > > > Looks OK in general, although I would need to know a little more of the > semantics. I get back a structure that looks like what's below. There probably isn't a need to return all that data. I was being lazy and returning the entire object. I'll annotate below. > One thing: the patch server will have to run over HTTPS - that way we > can know that it is who it says it is. Right, I'm not sure if the computer I'm proofing it on is the best place for it so I didn't bother with the HTTPS, but should be trivial to have it. > cheers > > andrew > > > $VAR1 = [ > bless( { > 'repository_id' => '1', ID of the repository the patch applies to. > 'created_on' => '2007-01-15T19:40:09-08:00', Timestamp of when the record was created. > 'diff' => 'dummied out', Actual patch, in plain text. > 'name' => 'copy_nowal.v1.patch', Name of the patch file. > 'owner_id' => '1', ID of the owner of the patch. > 'id' => '1', ID of the patch. > 'updated_on' => '2007-01-15T11:40:10-08:00' Timestamp of when patch was updated. > }, 'Patch' ), > bless( { > 'repository_id' => '1', > 'created_on' => '2007-01-15T19:40:09-08:00', > 'diff' => 'dummied out', > 'name' => 'pgsql-bitmap-09-17.patch', > 'owner_id' => '1', > 'id' => '2', > 'updated_on' => '2007-01-15T11:40:29-08:00' > }, 'Patch' ) > ]; Regards, Mark
pgsql-hackers by date: