Producing community binaries for OpenJDK

Fri May 26 13:11:09 UTC 2017

Hi all,

There's been a hive of activity, so I thought I'd post the minutes from the
last meeting so folks have an idea of the status of the project:

https://docs.google.com/document/d/1ybcu37V9Z7fXHhtC6eLkwt8sqqqVRVhy0Z5vpJ2rDIk/edit?usp=sharing

Cheers,
Martijn

On 5 May 2017 at 16:09, Martijn Verburg <martijnverburg at gmail.com> wrote:

> 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/AdoptOpenJD
>> K/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
>> >>>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>>
>
>