Re: compile/install of git

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Mark Wong <markwkm(at)gmail(dot)com>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Dave Page <dpage(at)pgadmin(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: compile/install of git
Date: 2010-09-20 17:35:27
Message-ID: 4C979B5F.8040405@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 09/20/2010 01:16 PM, Mark Wong wrote:
> On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan<andrew(at)dunslane(dot)net> wrote:
>>
>> On 09/20/2010 12:24 PM, Mark Wong wrote:
>>> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian<bruce(at)momjian(dot)us> wrote:
>>>> Well, I can run tests for folks before they apply a patch and "red" the
>>>> build farm. I can also research fixes easier because I am using the OS,
>>>> rather than running blind tests. I am just telling you what people told
>>>> me.
>>> I've been slowly trying to rebuild something that was in use at the
>>> OSDL to test patches. I just proofed something that I think works
>>> with the git repository:
>>>
>>> http://207.173.203.223:5000/patch/show/48
>>>
>>> If you click on the PASS or FAIL text, it will display the SHA1,
>>> author and commit message that the patch was applied to. Think this
>>> will be useful?
>>
>> The issue has always been how much we want to ask people to trust code that
>> is not committed. My answer is "not at all." Reviewers and committers will
>> presumably eyeball the code before trying to compile/run it, but any
>> automated system of code testing for uncommitted code is way too risky,
>> IMNSHO.
> I was hoping this would be more of a reviewing tool, not something
> that would be an excuse for someone to not try running with a patch.
> For example, if patch doesn't apply, configure, or build the output is
> captured and can be referenced. Also specifically in Bruce's example
> if there is enough concern about making the buildfarm red I thought
> this could help in these few specific aspects. But maybe I don't
> understand the scope of testing Bruce is referring to. :)

The whole point of the buildfarm is to identify quickly any
platform-dependent problems. Committers can't be expected to have access
to the whole range of platforms we support, so as long as they make sure
that things are working well on their systems they should be able to
rely on the buildfarm to cover the others. But that also means that the
buildfarm should contain instances of all the supported platforms. I
don't think we should be afraid of sending the buildfarm red. If we do
it's an indication that it's doing its job. If you're a committer and
you haven't made it go red a few times you're either very lucky or not
very active. Making it go red isn't a problem. Leaving it red is, but
we've really been pretty darn good about that.

Having someone act in effect as an informal buildfarm member is less
than satisfactory, IMNSHO. For one thing, it is likely to be less timely
about notifying us of problems than the automated system. And it's also
much less likely to catch problems on the back branches. So if you want
platform X supported (even BSD/OS, regardless of the fact that it's way
out of date), the first thing you should do is set up a buildfarm member
for it.

cheers

andrew

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-09-20 17:43:38 Re: Git conversion status
Previous Message Tom Lane 2010-09-20 17:34:36 Re: Git conversion status