Re: ideas for auto-processing patches

Поиск
Список
Период
Сортировка
От markwkm@gmail.com
Тема Re: ideas for auto-processing patches
Дата
Msg-id 70c01d1d0701171835q282146dei1b5bcb7d2b85220d@mail.gmail.com
обсуждение исходный текст
Ответ на Re: ideas for auto-processing patches  (Andrew Dunstan <andrew@dunslane.net>)
Ответы Re: ideas for auto-processing patches  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [COMMITTERS] pgsql: Fix failure due to accessing an
Следующее
От: "Takayuki Tsunakawa"
Дата:
Сообщение: Re: What is the motivation of include directive and