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 по дате отправления: