<div dir="ltr">Hi Goetz,<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature">Cheers,<br>Martijn</div></div>
<br><div class="gmail_quote">On 15 December 2016 at 07:18, Lindenmaier, Goetz <span dir="ltr"><<a href="mailto:goetz.lindenmaier@sap.com" target="_blank">goetz.lindenmaier@sap.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> well.  Testing is embarrassingly parallel in principle so with enough<br>
> hardware (or one of those "clouds" everyone is selling these days) one<br>
> should be able to run arbitrarily many tests.  No one seems to deal well<br>
<br>
</span>Hmm, is there a cloud containing all the different platforms?<br>
solarisx86_64? aixppc64?  linuxs390x? linuxarm32?<br>
I also think pre-submit testing is really helpful, but supplying the<br>
compute power on all these platforms to do this to an extend<br>
that you don't need any further testing is out of scope.<br>
<br>
Best regards,<br>
  Goetz.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
<br>
> -----Original Message-----<br>
> From: jdk10-dev [mailto:<a href="mailto:jdk10-dev-bounces@openjdk.java.net">jdk10-dev-bounces@<wbr>openjdk.java.net</a>] On Behalf Of<br>
> Martin Buchholz<br>
> Sent: Thursday, December 15, 2016 5:26 AM<br>
> To: joe darcy <<a href="mailto:joe.darcy@oracle.com">joe.darcy@oracle.com</a>><br>
> Cc: <a href="mailto:jdk10-dev@openjdk.java.net">jdk10-dev@openjdk.java.net</a>; <a href="mailto:quality-discuss@openjdk.java.net">quality-discuss@openjdk.java.<wbr>net</a><br>
> Subject: Re: Repository? -- How many lines of development?<br>
><br>
> On Wed, Dec 14, 2016 at 5:05 PM, joe darcy <<a href="mailto:joe.darcy@oracle.com">joe.darcy@oracle.com</a>> wrote:<br>
><br>
> ><br>
> > The tiered testing efforts made earlier in JDK 9 [1] are necessary<br>
> > preconditions for a JDK-wide pre-push/pre-submit system. In particular, if<br>
> > you don't have a a set of meaningful tests that runs quickly enough and<br>
> > passes reliably enough then a pre-push system can cause more harm than<br>
> good<br>
> > in introducing bottlenecks and causing changes to be spuriously rejected,<br>
> > say by an existing intermittent failure unrelated to the change.<br>
> ><br>
><br>
> It's a hard problem, but I think with sufficient effort presubmit can work<br>
> well.  Testing is embarrassingly parallel in principle so with enough<br>
> hardware (or one of those "clouds" everyone is selling these days) one<br>
> should be able to run arbitrarily many tests.  No one seems to deal well<br>
> with flaky tests, but flakiness can be measured, and a failing test can be<br>
> rerun arbitrarily, so deflaking should be automatable.<br>
><br>
> At Google we are starting to experiment with running jtreg tests with<br>
> massive parallelism.<br>
><br>
> Automation, presubmit testing and never-ever-broken master remain my<br>
> goals<br>
> for any software project.<br>
</div></div></blockquote></div><br></div>