From aph at redhat.com  Fri Jan  4 13:42:19 2019
From: aph at redhat.com (Andrew Haley)
Date: Fri, 4 Jan 2019 13:42:19 +0000
Subject: Workshop logistics?
In-Reply-To: <CA+3eh11Do-Z1sRK9ob2JXHX5H6c23LzK58N6evJJKvojBrW8UQ@mail.gmail.com>
References: <CA+3eh11Do-Z1sRK9ob2JXHX5H6c23LzK58N6evJJKvojBrW8UQ@mail.gmail.com>
Message-ID: <5fd51bc5-4e1f-0747-d24f-6bc601467b2a@redhat.com>

On 12/17/18 5:08 PM, Volker Simonis wrote:
> are there any updates regarding the workshop logistics?
> 
> I'm mainly interested in the time table of the meeting and the
> location of the workshop.

The day is February 4, 2019. The place is somewhere in Brussels. We'll
know the exact location by then. It's an unconference, so the
timetable is decided by consensus at the start of the day. I would
imagine that the start of the day will be 9am.

> Once that is clear, the registration procedure would be nice to know
> as well :)

Me too. I'm guessing that registration will be unnecessary.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

From openjdk at sunnychan.hk  Fri Jan  4 17:33:09 2019
From: openjdk at sunnychan.hk (Sunny Chan)
Date: Sat, 5 Jan 2019 01:33:09 +0800
Subject: Discussion proposal: OpenJDK build on Windows
Message-ID: <CAKSOMzQtfFRPfNWZOJUp-0_Qh=M6wdYRqESu1WannpQEo=EK=w@mail.gmail.com>

Windows is still one of the development platform that is used in the
enterprise environment, however building OpenJDK on Windows is pretty
difficult and often error prone. I would like to lead a session on how to
improve building OpenJDK on Windows

Topics to discuss:

1) Is cygwin still the right way forward to maintain compatibility with
*nix build? Or we should use alternatives like gnuwin32 or recent version
of Windows Subsystem for Linux

2) Another interesting steps that is more difficult on Windows is building
freetype. Is there anything we can do to make it easier

3) Any documentation we should include to guide new developer easier?

From volker.simonis at gmail.com  Fri Jan  4 17:57:22 2019
From: volker.simonis at gmail.com (Volker Simonis)
Date: Fri, 4 Jan 2019 18:57:22 +0100
Subject: Discussion proposal: OpenJDK build on Windows
In-Reply-To: <CAKSOMzQtfFRPfNWZOJUp-0_Qh=M6wdYRqESu1WannpQEo=EK=w@mail.gmail.com>
References: <CAKSOMzQtfFRPfNWZOJUp-0_Qh=M6wdYRqESu1WannpQEo=EK=w@mail.gmail.com>
Message-ID: <CA+3eh10f65x4sTR=hb_6DoXs19h3AYXcJGJFwaxBUATkB4bJRg@mail.gmail.com>

Hi Sunny,

that's definitely an interesting topic!

Do you know that OpenJDK can now be built on WSL by default since
https://bugs.openjdk.java.net/browse/JDK-8215445 ?

Also, the OpenJDK build can use the bundled version of freetype since
https://bugs.openjdk.java.net/browse/JDK-8193017 which makes the
dependency on FreeType much less of an problem on platforms which
don't have the freetype libs by default.

Best regards and looking forward seeing you at the Contributors Workshop,
Volker

On Fri, Jan 4, 2019 at 6:34 PM Sunny Chan <openjdk at sunnychan.hk> wrote:
>
> Windows is still one of the development platform that is used in the
> enterprise environment, however building OpenJDK on Windows is pretty
> difficult and often error prone. I would like to lead a session on how to
> improve building OpenJDK on Windows
>
> Topics to discuss:
>
> 1) Is cygwin still the right way forward to maintain compatibility with
> *nix build? Or we should use alternatives like gnuwin32 or recent version
> of Windows Subsystem for Linux
>
> 2) Another interesting steps that is more difficult on Windows is building
> freetype. Is there anything we can do to make it easier
>
> 3) Any documentation we should include to guide new developer easier?

From shade at redhat.com  Sat Jan  5 13:25:05 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Sat, 5 Jan 2019 14:25:05 +0100
Subject: Workshop proposal: hg.openjdk.java.net is infuriatingly slow
Message-ID: <d3f894d9-3e37-faa9-7add-4a92b2287943@redhat.com>

Hi!

There seem to be no better opportunity to discuss infrastructure!

TITLE: hg.openjdk.java.net is infuriatingly slow

ABSTRACT: Full clones from hg.openjdk.java.net are infuriatingly slow. This got worse since JDK 9
Jigsaw reshuffling increased repo size, and got significantly worse since JDK 10 switch to monorepo.
On top of the large clone time (1+ hours), cloning the repository frequently times out, which means
fresh clone of new repository could easily take an entire work day. Full clones are not rare: with
faster release cadence repositories fork often, features in development use their own repositories
often, special repositories like jdk-submit get recreated on regular basis. I'd like to talk what
options committers use to deal with their clones, and the way forward.

PLAN:
 - Show of hands who has this trouble and has workarounds
 - Discussing options:
    a) Have the local copies/bundles of repositories around and clone from them;
    b) Have something like https://builds.shipilev.net/workspaces/ and pick up snapshot from there;
    c) Have OpenJDK infra enable clonebundles: https://bugs.openjdk.java.net/browse/JDK-8211383
    d) Wait for Skara to (eventually) arrive and (maybe) fix everything;
    e) Something else?
 - Trading war stories

LENGTH: short (if we are discussing options), long (if we are trading war stories)

BIO, BLOGS: http://shipilev.net/, @shipilev

Thanks,
-Aleksey



From shade at redhat.com  Sat Jan  5 15:05:01 2019
From: shade at redhat.com (Aleksey Shipilev)
Date: Sat, 5 Jan 2019 16:05:01 +0100
Subject: Workshop proposal: Maintaining universal buildability
Message-ID: <11ead44e-39f0-346e-abea-07fc6bcd6193@redhat.com>

Hi,

Another infra/cross-cutting discussion proposal.

TITLE: Maintaining universal buildability

ABSTRACT: OpenJDK targets multiple architectures and OSes. Yet, (IIRC) Oracle builds x86_64 only,
Oracle-led jdk-submit verifies only those, and all this leaves other maintainers to catch up with
build failures after features/patches were committed. Additionally, there are JVM variants and
features that need to be checked for buildability. Additionally, there are build configuration
intricacies: precompiled headers, different toolchains, etc. All these fixes add up for backports,
where both the original patch and all the build/platform fixups need to be backported together. This
discussion is to catch up who builds what, why, what tricks builders use, and how crazy should we go
with maintaining the buildability.

PLAN (tentative, off the top of my head):
 - Show of hands: who builds what and why
 - Discussing build configs:
    *) No precompiled headers builds to verify includes
    *) x86_32 builds to maintain 32-bit cleanness;
    *) Minimal VM builds to check JVM features can be cleanly disabled;
    *) Zero VM builds to check JVM is able to run on platforms without ports;
    *) ...
 - Discussing non-x86 platforms builds:
    *) Cross-compilation as the sanity check?
    *) How far do we go? E.g. Linux/SPARC, anyone?
    *) ...
 - Discussing remote builds:
    *) Experience with cloud services for builds
    *) Virtualizing Windows nodes
    *) MacOS X virtualization troubles
    *) Solaris, anyone cares?
    *) ...
 - Discussing newer/alternative toolchains:
    *) How it all fits the "supported toolchains" for OpenJDK
    *) Building with newer GCC with new warnings
    *) Building with Clang for the warnings
    *) ...

LENGTH: long

BIO, BLOGS: http://shipilev.net/, https://builds.shipilev.net/, @shipilev

Thanks,
-Aleksey


From joe.darcy at oracle.com  Thu Jan 17 03:16:36 2019
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Wed, 16 Jan 2019 19:16:36 -0800
Subject: Workshop proposal: What is the CSR (Compatibility and Specification
 Review) Group?
Message-ID: <5C3FF394.1080508@oracle.com>

Title: What is the CSR (Compatibility and Specification Review) Group?

Abstract: The CSR (Compatibility and Specification Review) Group reviews 
interface changes proposed within active JDK release projects such as 
JDK 10, 11, 12, and 13. The CSR looks after source, binary, and 
behavioral compatibility. This talk will give an overview of the CSR's 
role and discuss the general JDK Compatibility Policy.

Length: Short

From tiago.daitx at canonical.com  Fri Jan 18 04:45:02 2019
From: tiago.daitx at canonical.com (Tiago Daitx)
Date: Fri, 18 Jan 2019 02:45:02 -0200
Subject: Workshop logistics?
In-Reply-To: <5fd51bc5-4e1f-0747-d24f-6bc601467b2a@redhat.com>
References: <CA+3eh11Do-Z1sRK9ob2JXHX5H6c23LzK58N6evJJKvojBrW8UQ@mail.gmail.com>
 <5fd51bc5-4e1f-0747-d24f-6bc601467b2a@redhat.com>
Message-ID: <CAC-Dh98_fXgCcWxr99NMB=KENvLZTED9ivj0R48HoQkbPf3iFA@mail.gmail.com>

Hi,

On Fri, Jan 4, 2019 at 11:43 AM Andrew Haley <aph at redhat.com> wrote:
>
> On 12/17/18 5:08 PM, Volker Simonis wrote:
> > are there any updates regarding the workshop logistics?
> >
> > I'm mainly interested in the time table of the meeting and the
> > location of the workshop.
>
> The day is February 4, 2019. The place is somewhere in Brussels. We'll
> know the exact location by then. It's an unconference, so the
> timetable is decided by consensus at the start of the day. I would
> imagine that the start of the day will be 9am.
>
> > Once that is clear, the registration procedure would be nice to know
> > as well :)
>
> Me too. I'm guessing that registration will be unnecessary.

Has there been any updates on the (probable) location of the workshop
in Brussels? What about the registration process?

Regards


-- 
Tiago St?rmer Daitx
Software Engineer
tiago.daitx at canonical.com

PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E  8CA4 1931 8D5E F5B2 13BE

From sgehwolf at redhat.com  Fri Jan 18 10:13:50 2019
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Fri, 18 Jan 2019 11:13:50 +0100
Subject: Workshop proposal: How to do backports/bug fixes properly?
Message-ID: <3d80555d05e4dfbc181b70ee580aaecc839a6f06.camel@redhat.com>

With the new fast-release cycle it's hard to know where fixes should
get pushed in certain phases of the development cycle. Let's exclude
enhancements for this discussion for simplicity.

Consider the fast-release-cadence cycle:

---------------------------------------------------------------------------------------
                             ,- JDK 12,     ,- JDK 12,     ,-- JDK 12 GA
Time:                        |  RDP 1       | RDP 2        |
                            \|/            \|/            \|/
                             `              `              `
---------------------------------------------------------------------------------------


                ,--jdk-updates/jdk11u----                   ,--------jdk-updates/jdk12u
 ,---jdk/jdk11-+              ,------------jdk/jdk12-------+ 
+----------------------------+-----------------------jdk/jdk---------------------------


We are currently between JDK 12, RDP 1 and JDK 12, RDP 2. So if a
bugfix is being developed it's not entirely clear where to push the fix
to. Should it go to jdk/jdk, or jdk/jdk12? Do all bugfixes go to
jdk/jdk12 directly before RDP 2? Would I need to push it to both,
jdk/jdk and jdk/jdk12?

What if the fix needs to go to JDK 11 too? It's possible for a fix to
be in jdk/jdk and jdk-updates/jdk11u, but not in jdk/jdk12 because of
some RDP 2 rules where only high priority bugs can be fixed. This might
cause issues where JDK 12 could potentially regress if the developer
forgets to revisit the backport for jdk-updates/jdk12u once that tree
exists.

Who gets to decide which fix gets pushed where?

If a backport depends on other fixes getting backported too, what's the
process to get it included? Should the backport merged changes? Keep
them separate as much as possible? Where do we draw the line?

Perhaps we could discuss those issues and set some ground rules. Trying
to simplify the process would help too.

Thanks,
Severin


From mark.reinhold at oracle.com  Fri Jan 18 23:30:33 2019
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 18 Jan 2019 15:30:33 -0800
Subject: Workshop logistics?
In-Reply-To: <CAC-Dh98_fXgCcWxr99NMB=KENvLZTED9ivj0R48HoQkbPf3iFA@mail.gmail.com>
References: <CA+3eh11Do-Z1sRK9ob2JXHX5H6c23LzK58N6evJJKvojBrW8UQ@mail.gmail.com>
 <5fd51bc5-4e1f-0747-d24f-6bc601467b2a@redhat.com>
 <CAC-Dh98_fXgCcWxr99NMB=KENvLZTED9ivj0R48HoQkbPf3iFA@mail.gmail.com>
Message-ID: <20190118153033.844694720@eggemoggin.niobe.net>

2019/1/17 20:45:02 -0800, tiago.daitx at canonical.com:
> Has there been any updates on the (probable) location of the workshop
> in Brussels? What about the registration process?

Expect an announcement early next week.

There will be a simple, lightweight registration process.

- Mark

From chris.hegarty at oracle.com  Thu Jan 31 17:25:41 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Thu, 31 Jan 2019 17:25:41 +0000
Subject: Workshop proposal: Working in the Sandbox
Message-ID: <2E91CA62-F936-46BB-BC95-CA01B6E5E428@oracle.com>

Title: Working in the Sandbox

Abstract: The JDK Sandbox Development Repository [1] facilitates OpenJDK
committers that are working on non-trivial changes, possibly JEP-scale,
whose scope and duration make it necessary to collaborate with others in
an open shared version control system, rather than sharing patches. This
session will give an overview of the Sandbox, the kind of projects that
it has supported ( and continues to support ), and will address common
questions and guidance for using the Sandbox.

Length: Short

-Chris.

[1] http://cr.openjdk.java.net/~chegar/docs/sandbox.html