+1 Thanks!!!
> On Sep 4, 2015, at 3:17 PM, Anthony Baker <[email protected]> wrote:
>
> BTW, I modified the “Geode in 5 min” wiki page to include build instructions
> for skipping tests. I’ll do the same for README.md unless I hear any
> objections.
>
> Anthony
>
>
>> On Sep 4, 2015, at 12:33 PM, Anthony Baker <[email protected]> wrote:
>>
>> Another note: these timings are from server-class workstations. On a laptop
>> the overall test length (without the change) can run 18+ hours.
>>
>> Anthony
>>
>>
>>
>>> On Sep 4, 2015, at 12:21 PM, Kirk Lund <[email protected]> wrote:
>>>
>>> +1
>>>
>>> I like the idea of switching to fork=1 for a few months to focus on
>>> stabilizing any dunit tests that fail without potential test pollution
>>> causes. These failures are mostly like ones that involve race conditions.
>>> Once we fix these, then we could change back to fork=30.
>>>
>>>
>>> On Fri, Sep 4, 2015 at 11:16 AM, Mark Bretl <[email protected]> wrote:
>>>
>>>> I see that Kirk made an update to the issue and wanted to follow up on the
>>>> Dev list for discussion.
>>>>
>>>> I also ran a build on the open side with the dunit fork = 1. The total time
>>>> of the build was: 9 hrs 58 mins 33.662 secs. The last Geode build took: 6
>>>> hr 21 min <https://builds.apache.org/job/Geode-nightly/buildTimeTrend>.
>>>> It is an increase of about 3.5 hours, which matches the increase in time
>>>> that Kirk had.
>>>>
>>>> The question becomes: Do we want to make the change so we can increase the
>>>> quality of tests by isolating each one at the cost of increasing the total
>>>> build time?
>>>>
>>>> My thoughts would be to make the change to weed out the 'bad' tests and
>>>> increase the overall quality of the tests, so when a test fails there is no
>>>> questioning the result. Once we have them passing more consistently, then
>>>> we can increase the fork count again.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Mark Bretl
>>>> Software Build Engineer
>>>> Pivotal
>>>> 503-533-3869
>>>> www.pivotal.io
>>>>
>>
>
