Hi Goetz, A few FOSDEM's ago a group of us came up with a *optional* (i.e. No one should be forced to it) patch pipeline architecture where each vendor who had specific platforms could pull patches from a queue, build them on their specialised platform and return a result. This of course would require a little bit of common infrastructure which the London Java Community (as a non-profit entity) was willing to own/host on behalf of OpenJDK.
At the time there wasn't unanimous support for this idea (I imagine for cost/resource reasons) from the major vendors involved in OpenJDK, but if folks think this is a good time to revisit the discussion then perhaps we could have a session on this at the upcoming 2017 FOSDEM. Cheers, Martijn On 15 December 2016 at 07:18, Lindenmaier, Goetz <goetz.lindenma...@sap.com> wrote: > > well. Testing is embarrassingly parallel in principle so with enough > > hardware (or one of those "clouds" everyone is selling these days) one > > should be able to run arbitrarily many tests. No one seems to deal well > > Hmm, is there a cloud containing all the different platforms? > solarisx86_64? aixppc64? linuxs390x? linuxarm32? > I also think pre-submit testing is really helpful, but supplying the > compute power on all these platforms to do this to an extend > that you don't need any further testing is out of scope. > > Best regards, > Goetz. > > > > > > > -----Original Message----- > > From: jdk10-dev [mailto:jdk10-dev-boun...@openjdk.java.net] On Behalf Of > > Martin Buchholz > > Sent: Thursday, December 15, 2016 5:26 AM > > To: joe darcy <joe.da...@oracle.com> > > Cc: jdk10-...@openjdk.java.net; quality-discuss@openjdk.java.net > > Subject: Re: Repository? -- How many lines of development? > > > > On Wed, Dec 14, 2016 at 5:05 PM, joe darcy <joe.da...@oracle.com> wrote: > > > > > > > > The tiered testing efforts made earlier in JDK 9 [1] are necessary > > > preconditions for a JDK-wide pre-push/pre-submit system. In > particular, if > > > you don't have a a set of meaningful tests that runs quickly enough and > > > passes reliably enough then a pre-push system can cause more harm than > > good > > > in introducing bottlenecks and causing changes to be spuriously > rejected, > > > say by an existing intermittent failure unrelated to the change. > > > > > > > It's a hard problem, but I think with sufficient effort presubmit can > work > > well. Testing is embarrassingly parallel in principle so with enough > > hardware (or one of those "clouds" everyone is selling these days) one > > should be able to run arbitrarily many tests. No one seems to deal well > > with flaky tests, but flakiness can be measured, and a failing test can > be > > rerun arbitrarily, so deflaking should be automatable. > > > > At Google we are starting to experiment with running jtreg tests with > > massive parallelism. > > > > Automation, presubmit testing and never-ever-broken master remain my > > goals > > for any software project. >
