Producing community binaries for OpenJDK

Fri May 5 15:09:41 UTC 2017

Hi Stuart,

Responses inline.

On 5 May 2017 at 14:52, Stuart Monteith <stuart.monteith at linaro.org> wrote:

> 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.
>

Thank you!  We'll get that fixed. -
https://github.com/AdoptOpenJDK/openjdk-build/issues/90

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".
>

OK, I think I understand - Added as
https://github.com/AdoptOpenJDK/openjdk-build/issues/91

>
> Please let me know if you would like any help.
>

That would be most welcome!  Are you able to join us on Slack?  I can send
you an invite.

Cheers,
MArtijn

>
> 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
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>