Repository? -- How many lines of development?

[Martijn Verburg]

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.lindenmaier at 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-bounces at openjdk.java.net] On Behalf Of
> > Martin Buchholz
> > Sent: Thursday, December 15, 2016 5:26 AM
> > To: joe darcy <joe.darcy at oracle.com>
> > Cc: jdk10-dev at openjdk.java.net; quality-discuss at openjdk.java.net
> > Subject: Re: Repository? -- How many lines of development?
> >
> > On Wed, Dec 14, 2016 at 5:05 PM, joe darcy <joe.darcy at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20161215/543b727d/attachment.html>