Re: Feature freeze progress report

From: Naz Gassiep <naz(at)mira(dot)net>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Marc Munro <marc(at)bloodnok(dot)com>, heikki(at)enterprisedb(dot)com, pgsql-hackers(at)postgresql(dot)org, tgl(at)sss(dot)pgh(dot)pa(dot)us, dpage(at)postgresql(dot)org, simon(at)2ndquadrant(dot)com, bruce(at)momjian(dot)us
Subject: Re: Feature freeze progress report
Date: 2007-05-01 01:33:40
Message-ID: 463698F4.4060301@mira.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I believe the suggestion was to have an automated process that only ran
on known, sane patches. I don't think he was suggesting a mechanism for
the great unwashed masses to dump arbitrary code into and have it
applied in the buildfarm. You'd have an inventory of patches (you could
use a hash to ensure they hadn't changed just before they ar
automatically applied) that were verified as good, and the system would
apply them to HEAD periodically.

Even if the patch inventory wasn't kept right up to date, this system
could potentially help many regression issues or bugs to surface sooner,
and as it would require zero work once set up besides system maintenance
(which should be low if it is implemented in a reasonably intelligent
manner) I feel that it is a great idea. Generally, I am all for
automating mundane tasks as much as possible.

Regards,
- Naz.

Andrew Dunstan wrote:
> Marc Munro wrote:
>> On Mon, 2007-30-04 at 08:56 -0300, Heikki Linnakangaspgsql wrote:
>>
>>> Date: Mon, 30 Apr 2007 09:18:36 +0100
>>> From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
>>> To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>>> Cc: Dave Page <dpage(at)postgresql(dot)org>, Simon Riggs
>>> <simon(at)2ndquadrant(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>,
>>> PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
>>> Subject: Re: Feature freeze progress report
>>> Message-ID: <4635A65C(dot)70005(at)enterprisedb(dot)com>
>>>
>>
>>
>>> If we had a 1-2 lines status blurp attached to each patch in the
>>> queue, like "waiting for review", "author is fixing issue XX", etc.,
>>> that
>>> might help. Bruce would need to do that if we keep the current patch
>>> queue system unmodified otherwise, or we'd need to switch to
>>> something else.
>>>
>>
>> Would it be possible to also automatically determine some sort of
>> bit-rot status? What I had in mind was an automated process that would
>> apply each patch to HEAD on a daily basis and report whether the patch
>> still applies cleanly and still allows all regression tests to pass on
>> at least one platform. If and when the result of these tests changes
>> from pass to fail, the patch submitter would be automatically
>> notified.
>> The patch status could then also show the last time at which the patch
>> applied cleanly, and the last time that regression tests ran
>> successfully.
>>
>>
>>
>
> This or something similar has been discussed in the past w.r.t. the
> buildfarm. One major problem is that most sane system owners won't
> want to apply, compile and run an arbitrary patch. It could well have
> an intended or unintended trojan horse, for example. So you'd need
> some level of sanity checking to be done by some trusted person even
> to get it to this stage.
>
> cheers
>
> andrew
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
> http://www.postgresql.org/about/donate
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Gregory Stark 2007-05-01 01:54:28 Re: Feature freeze progress report
Previous Message Henry B. Hotz 2007-05-01 01:29:46 Re: Fwd: [PATCHES] Preliminary GSSAPI Patches