Re: Buildfarm "master-next" branch? (was: Dynamic Shared Memory stuff)

On Wed, Apr 16, 2014 at 8:24 PM, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote:
> On 04/17/2014 12:08 AM, Robert Haas wrote:
>> On Tue, Apr 15, 2014 at 10:46 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>> On Wed, Apr 16, 2014 at 3:01 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>> On Tue, Apr 15, 2014 at 12:33 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>>>>> On Mon, Apr 14, 2014 at 10:03 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>>>> For the create case, I'm wondering if we should put the block that
>>>>>> tests for !hmap *before* the _dosmaperr() and check for EEXIST. What
>>>>>> is your opinion?
>>>>>
>>>>> Either way is okay, but I think the way you are suggesting is better as it
>>>>> will make code consistent with other place (PGSharedMemoryCreate()).
>>>>
>>>> OK, can you prepare a patch?
>>>
>>> Please find attached patch to address this issue.
>>> One minor point to note is that now we have to call GetLastError() twice,
>>> once inside error path and once to check EEXIST, but I think that is okay
>>> as existing code in PGSharedMemoryCreate() does it that way.
>>
>> OK. I committed this blindly, but I don't have a Windows dev
>> environment, so please keep an eye on the Windows buildfarm members
>> and provide follow-on patches if any of them get unhappy about this.
>
> Given that we're doing this a fair bit, is it reasonable to define a
> "master-next" branch in git and have the buildfarm (or at least the
> Windows members) build that?
>
> Permit master-next to be rebased and reset.
>
> That way it's possible to fire stuff off and see what happens on the
> buildfarm without introducing broken commits unnecessarily.
>
> Thoughts?

In this particular case, I have a lot of confidence that Amit tested
this on his own machine before sending in the patch; and moreover, he
wrote that code in the first place. So it's no worse than it would
have been if that change had been in the originally committed version,
which I didn't personally test on Windows, either, but which has
nevertheless mostly passed buildfarm testing. Arguably, if I'm going
to be hacking on platform-dependent things very often, I should get my
own Windows build environment set up so that I can test it myself, but
it hasn't quite been worth it to me thus far, and Amit has proven to
be pretty reliable in terms of getting things right.

In terms of improving the buildfarm infrastructure, the thing I would
most like to have is more frequent runs. It would be great if pushing
a commit to the master repository triggered an immediate build on
every buildfarm animal so that you could see all of the failures in a
short period of time. But that would require more resources for the
buildfarm machines, which are provided on a strictly volunteer basis,
so it's hard to see how to arrange that.

But the ability to easily spin up temporary branches for testing would
also be great. Unfortunately, I suspect that only a minority of the
buildfarm owners would choose to participate, which would make it less
useful, but if we could solve that problem I'd be all in favor of it.
I'm not volunteering to do the work, though.

Honestly, I don't think we have a huge problem here today. Yeah, the
buildfarm turns pretty colors on a fairly regular basis, but those
issues are also generally fixed very quickly. With the unfortunate
exception of the seemingly never-ending stream multixact-related bugs,
a user who took a snapshot of our master branch at a randomly selected
point during the 9.4 development cycle would likely have gotten code
reliable enough to be run in production.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company