Producing community binaries for OpenJDK

Fri May 5 12:32:14 UTC 2017

Hi all,

Just a further update.  We've now got the Slackarchive
<https://adoptopenjdk.slackarchive.io/> working so you can view all of the
conversations right from the first day of the project.

We now have regular builds on a variety of platforms and the next step is
for the test pipeline to run for all environments as well.

The full website is now up at http://adoptopenjdk.net and the various
GitHub projects are here https://github.com/AdoptOpenJDK - some of the key
repos are:

* openjdk-build
* openjdk-test
* openjdk-api
* openjdk-website
* openjdk-jdk8u
* openjdk-jdk9

Cheers,
Martijn

On 5 April 2017 at 14:48, Martijn Verburg <martijnverburg at gmail.com> wrote:

> Hi all,
>
> Meeting minutes:
>
> --------------------
>
> Attendees
> ========
>
> * Tim Ellison
> * George Adams
> * Joe Brady
> * Adam Farley
> * Martijn Verburg
> * Mani Sarkar
>
> Progress
> =======
>
> Jtreg with jcov work progressing well, few script issues to sort out in
> terms of parsing the result to go.
>
> Transparency
> ==========
>
> * Google Hangouts on air / youtube channel to be used in future for calls
> * Slack channel traffic to be made public
>
> Git-Hg Job
> ========
>
> The Git-Hg (https://github.com/AdoptOpenJDK/openjdk-build/
> blob/master/git-hg/git-hg.sh) job gets run periodically by a Jenkins job (
> https://ci.adoptopenjdk.net/job/git-hg/configure) - would be good to get
> a further community review of this script to ensure that for the master
> branch there is the smallest diff possbile between the clone in GitHub and
> the forest in hg.  That diff should be published.
>
> Github OpenJDK Binary Release Team
> ==============================
>
> All of the scripts and documentation are open but as GitHub secrets etc
> are involved for the tagged releases we need to have a smaller, trusted
> release team that has access to the actual Jenkins job that kicks off
> tagged releases (e..g 1.8.0_xxx).  Will follow the Node JS community and
> start with one person who will then train and add further trusted folks.
>
> Nightly/Publish jobs
> ===============
>
> George covered how the backend code works to get around the GitHub API
> limitation
>
> New build platforms... Windows/x86-64 and Linux/ppc64le
> =============================================
>
> Windows build is failing towards the end, Martijn and Mani to investigate
>
> asmtools
> =======
>
> Mani to fix (it's fixed on cloudbees, just need to do the same on new CI
> server).
>
> Restarting jenkins
> ==============
>
> George will document / put into openjdk-build
>
> cloudflare
> ========
>
> * New cloudflare account (shared Adopt OpenJDK account) has been created
> for DNS and SSL management
> * Martijn has added an issue for website speed
> * George suggested a Puppet server to manage our infrastructure going
> forwards. +1'd by everyone.
>
> Funding
> ========
>
> Quick discussion of potentially crowdsourcing and/or just encouraging
> cloud providers and other orgs to donate machines (pretty successful so
> far).
>
> Port over other OpenJDK tools from Cloudbees
> ====================================
>
> Martijn and Mani to give a list of tools such as sigtest - to port over
>
> Security of infrastructure
> =========================
>
> * Martijn and John Oliver to start a doc and team to fix low hanging fruit
> * Then get in professional Pen testers from the LJC
> * Also discussion of keeping infra team small, including short expiry keys
> for those that need temporary access
>
> Cheers,
> Martijn
>
> On 5 April 2017 at 12:01, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
>
>> Hi all,
>>
>> This is starting now for those of you who can join us - will post rough
>> minutes afterwards.
>>
>> Cheers,
>> Martijn
>>
>> On 4 April 2017 at 12:23, Martijn Verburg <martijnverburg at gmail.com>
>> wrote:
>>
>>> Hi all,
>>>
>>> There will be a Google hangout
>>> <https://hangouts.google.com/hangouts/_/dnxdlutzf5echdtf456c6mxglae> tomorrow
>>> at 1200 UK time (GMT+1) for those who want a more detailed status update
>>> and a walkthrough on how some of the technical details work.
>>>
>>> Cheers,
>>> Martijn
>>>
>>> On 30 March 2017 at 20:35, Martijn Verburg <martijnverburg at gmail.com>
>>> wrote:
>>>
>>>> In terms of overall progress we now have builds running on several
>>>> platforms: Linux x64, zLinux, PPC Linux, Windows, MacOS X and hopefully
>>>> soon Solaris.
>>>>
>>>> We'd like to get the jtreg testsuite with jcov working before showing
>>>> this to a wider audience (we think that minimum level of test coverage is
>>>> important).  A personal next step goal for me would then be to integrate
>>>> the other various OpenJDK build efforts that are out there today (IcedTea,
>>>> David Lloyd's Git clones of forests, Henri Gomez's work and many more).
>>>>
>>>> All of the work is happening on GitHub (http://www.github.com/adoptop
>>>> enjdk) - feel free to ask any questions here, or submit issues over
>>>> there :-).
>>>>
>>>>
>>>>
>>>> Cheers,
>>>> Martijn
>>>>
>>>> On 30 March 2017 at 20:30, Martijn Verburg <martijnverburg at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> I've opened up https://github.com/AdoptOpenJDK/openjdk-build/issues/16
>>>>> to investigate this potential IP flow issue.  I'll stress that it may *not*
>>>>> actually end up being a goal to donate code to the OpenJDK project.  But if
>>>>> we can put a mechanism in place to ensure clean IP flow in case we do
>>>>> choose to donate the code, then that's worth looking into and it's better
>>>>> to do it earlier rather than later.
>>>>>
>>>>> I briefly toyed with the idea of proposing an openjdk project for
>>>>> this, but the OpenJDK project does simply not have the infrastructure in
>>>>> place to rapidly prototype the sort of common build infra and processes
>>>>> we're exploring.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Martijn
>>>>>
>>>>> On 29 March 2017 at 16:22, Ben Evans <benjamin.john.evans at gmail.com>
>>>>> wrote:
>>>>>
>>>>>> That's not at all what I mean, and well you know it.
>>>>>>
>>>>>> The industry has a clear, obvious example of a major corporation of
>>>>>> the same standing as Oracle (namely Microsoft) using a contribution
>>>>>> model which is quite literally:
>>>>>>
>>>>>> 1) I certify that I have the rights to contribute this code
>>>>>>
>>>>>> 2) I certify that I want to contribute this code under the given
>>>>>> license & accept the terms.
>>>>>>
>>>>>> How much more "real world" an example would you like?
>>>>>>
>>>>>> Now, if your stated reason was: "Oracle's lawyers do not believe that
>>>>>> the IP regime adopted by Microsoft is sound & do not wish to expose
>>>>>> themselves to liabilities that they believe exist with that model"
>>>>>> then that would be one thing.
>>>>>>
>>>>>> But please don't pretend that alternative models "make no sene in the
>>>>>> real world".
>>>>>>
>>>>>> Ben
>>>>>>
>>>>>> On Wed, Mar 29, 2017 at 5:13 PM, dalibor topic <
>>>>>> dalibor.topic at oracle.com> wrote:
>>>>>> > On 29.03.2017 16:51, Ben Evans wrote:
>>>>>> >>
>>>>>> >> Microsoft have a simple click-through arrangement, on Github,
>>>>>> where I
>>>>>> >> certify I have the right to make the contribution and that I agree
>>>>>> to
>>>>>> >> the relevant licensing terms. The first time I make a PR, I am
>>>>>> >> prompted to perform the clickthrough, and then it goes away.
>>>>>> >>
>>>>>> >> Why is the situation with OpenJDK any different at all to that?
>>>>>> >
>>>>>> >
>>>>>> > OpenJDK does not use GitHub. It's not owned by Microsoft. It uses
>>>>>> the OCA.
>>>>>> > You can find out more about it here: http://openjdk.java.net/contri
>>>>>> bute/ .
>>>>>> >
>>>>>> > If what you're asking here is why one can't just contribute other
>>>>>> people's
>>>>>> > random code off GitHub to OpenJDK, that's because one can only
>>>>>> contribute
>>>>>> > what's one's own. Other people's code is not.
>>>>>> >
>>>>>> > If there is a doubt whether something is one's own or not, it's
>>>>>> much better
>>>>>> > and simpler for OpenJDK developers to err on the side of caution,
>>>>>> and
>>>>>> > neither encourage nor accept such contributions at all.
>>>>>> >
>>>>>> > And that's ultimately why all the occasionally occurring ideas about
>>>>>> > alternative contribution flows are doomed from the start. They make
>>>>>> no sense
>>>>>> > in the real world.
>>>>>> >
>>>>>> > cheers,
>>>>>> > dalibor topic
>>>>>> >
>>>>>> >
>>>>>> >> Ben
>>>>>> >>
>>>>>> >> On Wed, Mar 29, 2017 at 4:00 PM, dalibor topic <
>>>>>> dalibor.topic at oracle.com>
>>>>>> >> wrote:
>>>>>> >>>
>>>>>> >>> On 29.03.2017 10:59, Martijn Verburg wrote:
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>     As long as we're talking about flow of ideas, that might
>>>>>> make sense.
>>>>>> >>>>
>>>>>> >>>>     If the expectation is that patches and build infra code
>>>>>> would get
>>>>>> >>>>     promoted
>>>>>> >>>>     into OpenJDK, I think that's very unlikely, as OpenJDK
>>>>>> requires an
>>>>>> >>>>     OCA for contributions, while GitHub does not. So over time,
>>>>>> the cost
>>>>>> >>>>     of untangling who did what in some random GitHub repo in
>>>>>> order to
>>>>>> >>>>     arrive at something that can be contributed tends to
>>>>>> overshadow any
>>>>>> >>>>     benefit from such accumulations of code.
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> Sure, that's actually a cycle I want to introduce (some sort of
>>>>>> CLA) but
>>>>>> >>>> appreciate the IP flow here.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> There is no need for any cycles.
>>>>>> >>>
>>>>>> >>> OpenJDK Projects can not take random code from GitHub (or any
>>>>>> other
>>>>>> >>> place).
>>>>>> >>> Regardless of the arrangement you arrive at for managing some
>>>>>> GitHub
>>>>>> >>> repo.
>>>>>> >>>
>>>>>> >>> As soon as you start having more than one contributor, you end up
>>>>>> with
>>>>>> >>> something none of them can go ahead and just contribute on their
>>>>>> own. At
>>>>>> >>> that point the conversation about contributions becomes
>>>>>> exponentially
>>>>>> >>> more
>>>>>> >>> complicated, and in the overwhelming majority of cases it's not
>>>>>> worth
>>>>>> >>> spending the time or effort on.
>>>>>> >>>
>>>>>> >>>> Which we might do if this thing has legs, but it has a long way
>>>>>> to go to
>>>>>> >>>> see if it's useful or desirable yet.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> Sure, but in that case you should not really expect to see any of
>>>>>> that
>>>>>> >>> code
>>>>>> >>> make its way back into OpenJDK. For example, you most likely
>>>>>> won't be
>>>>>> >>> able
>>>>>> >>> to take any such code back into OpenJDK once you do decide to
>>>>>> start a new
>>>>>> >>> Project.
>>>>>> >>>
>>>>>> >>> Basically, once you have a PoC of some random idea for the JDK
>>>>>> developed
>>>>>> >>> outside OpenJDK, you might have just enough code to prove some
>>>>>> idea
>>>>>> >>> works,
>>>>>> >>> but you may have too much code and history for it to be worth
>>>>>> putting any
>>>>>> >>> work into turning it into something that can be contributed back
>>>>>> to
>>>>>> >>> OpenJDK,
>>>>>> >>> if you have more than one contributor.
>>>>>> >>>
>>>>>> >>> So one can assume that such externally, 'socially' developed code
>>>>>> will be
>>>>>> >>> in
>>>>>> >>> the vast majority of cases undesirable for OpenJDK, regardless of
>>>>>> its
>>>>>> >>> utility. That means the best potential outcome for its authors is
>>>>>> to
>>>>>> >>> produce
>>>>>> >>> something useful but undesirable.
>>>>>> >>>
>>>>>> >>>
>>>>>> >>> cheers,
>>>>>> >>> dalibor topic
>>>>>> >>> --
>>>>>> >>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>>>> >>> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>>>>> >>> <tel:+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
>>>>>> >>>
>>>>>> >>> 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, Jan Schultheiss, Val Maher
>>>>>> >>>
>>>>>> >>> <http://www.oracle.com/commitment> Oracle is committed to
>>>>>> developing
>>>>>> >>> practices and products that help protect the environment
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>>>>>> > Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>>>>>> > <tel:+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
>>>>>> >
>>>>>> > 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, Jan Schultheiss, Val Maher
>>>>>> >
>>>>>> > <http://www.oracle.com/commitment> Oracle is committed to
>>>>>> developing
>>>>>> > practices and products that help protect the environment
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>