Producing community binaries for OpenJDK

Tue Apr 4 11:23:42 UTC 2017

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/adoptopenjdk)
> - 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
>>>
>>
>>
>