Producing community binaries for OpenJDK

Fri May 5 13:52:18 UTC 2017

Hi,
   I've just had a look and I have some comments on the ARM builds:

According to:
    https://ci.adoptopenjdk.net/job/openjdk_build_arm64_linux/11/consoleFull

You are building against:
   http://hg.openjdk.java.net/aarch64-port/jdk8

This should be:
  http://hg.openjdk.java.net/aarch64-port/jdk8u

which is the currently maintained tree.

Also, the build has been named
"OpenJDK8_arm64_Linux_201725040754.tar.gz". The "arm64" part should be
"aarch64". While the "arm64" terminology isn't encouraged, and the VM
identifies itself as os.arch="aarch64", it also conflicts with the two
64-bit ARM backends that exist in JDK9. The Unified Oracle backend
identifies itself as "arm64", while the original OpenJDK 64-bit ARM
port is "aarch64".

Please let me know if you would like any help.

BR,
    Stuart

On 5 May 2017 at 13:32, Martijn Verburg <martijnverburg at gmail.com> wrote:
> 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
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>