OpenJDK 8 adoption in Fedora and Debian Linux distributions

dalibor topic dalibor.topic at
Thu May 8 11:23:05 UTC 2014

I think that CI servers cover a slightly different use case - a binary 
indicator whether everything is fine, or if something somewhere somehow 
might be wrong. As long as everything is fine, everything is awesome and 
life is good.

But if something isn't fine, then someone needs to determine if that is 
an issue with the code in the project, the code in the JDK, the 
environment, the CI setup, etc. Depending on the size and scope of the 
project being tested, that can be a non-trivial effort for a person who 
is not an expert in the tested project.

So what we have done instead was to involve FOSS projects directly, and 
started to motivate a habit of early access build testing by making it 
easy to get notified that a new build is there, and having a person 
assist with getting across the initial hurdles of getting good feedback 
to the right place.

That eliminates a few potential sources of volatility and errors 
(environment, setup, 'you're building it wrong', 'we never tested that 
configuration', 'we only care about this particular release series', 'we 
want to build on this but run on that rather than the other way round', 
etc.) and allows experts in the tested projects to make the initial 
determination whether a potential issue is something that could and 
should be addressed in the corresponding project, or if it's something 
that might be a bug in the JDK.

Sometimes it turns out that it's not a bug in the JDK, either, but, for 
example, a misunderstanding of how to cross compile code for older 
platform versions. [0] Sometimes it's something else, and sometimes it's 
a real, high priority issue in the JDK itself.

I think that this approach delivers better results (i.e. high priority 
bug reports) faster than potentially relying on third party (i.e. 
neither OpenJDK nor tested project's developers) contributors to set up 
CI instances of FOSS projects and to monitor and analyze them.

That being said, such systems can be a good source of candidates to add 
to the pool of projects to find developers to reach out to, in the same 
way how we can use the build results (and interesting failures) from 
Linux distributions OpenJDK 8 adoption efforts to find projects, where 
the effort necessary to start testing early access builds would result 
in a rewarding experience, motivating further continuous testing down 
the road.

So if you want to analyze the list of projects on the CI server, and 
compare them against the list we already have on the wiki, and extract 
those that aren't present but have a known personal contact to make the 
introduction with, that would be a great start for a separate mailing 
list thread.

dalibor topic


On 07.05.2014 15:00, Mani Sarkar wrote:
> Would we be making use of the AdoptOpenJDK CloudeBees CI servers in
> anyway in the process?
> --
> @theNeomatrix369 <>*  | **Blog
> <>**  | *LJC Associate & LJC Advocate
> (@adoptopenjdk & @adoptajsr programs)
> *Meet-a-Project - *MutabilityDetector
> <>*  | **Bitbucket
> <>* * | **Github
> <>** | **LinkedIn
> <>*
> *Come to Devoxx UK 2014:*
> */Don't chase success, rather aim for "Excellence", and success will
> come chasing after you!/*

<> Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961

ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603
Geschäftsführer: Jürgen Kunz

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Astrid Kepper, Val Maher

<> Oracle is committed to developing
practices and products that help protect the environment

More information about the adoption-discuss mailing list