Re: compile/install of git

Поиск
Список
Период
Сортировка
От Andrew Dunstan
Тема Re: compile/install of git
Дата
Msg-id 4C979B5F.8040405@dunslane.net
обсуждение исходный текст
Ответ на Re: compile/install of git  (Mark Wong <markwkm@gmail.com>)
Список pgsql-hackers

On 09/20/2010 01:16 PM, Mark Wong wrote:
> On Mon, Sep 20, 2010 at 9:42 AM, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>
>> On 09/20/2010 12:24 PM, Mark Wong wrote:
>>> On Sat, Sep 18, 2010 at 7:59 AM, Bruce Momjian<bruce@momjian.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Git conversion status
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Git conversion status