+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 <mbr...@pivotal.io> 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 >
