Producing community binaries for OpenJDK

Thu Mar 30 19:35:41 UTC 2017

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