Coherent release process

Discussion:

dalibor topic

2015-11-12 14:53:18 UTC

if/when the OpenJDK project may develop a more coherent release plan?

You can find the plans for JDK 9 at
http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are
linked off the Project page of the corresponding JDK 8 Updates Project
in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ .

The corresponding Project's mailing list, jdk8u-dev, is the right place
to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has
completed its work with the JDK 8 GA a while ago, so this list is
largely dormant.

The lack of consistency among branches for different releases makes
it extremely hard to create a well defined build process for OpenJDK.

The separate Mercurial forests existed for the convenience of developing
multiple releases with a large number of changes and features in
parallel within a single OpenJDK Project (just as was the case for the
JDK 7 Updates Project, fwiw).

For reasons discussed back in July, the JDK 8 Updates Project in OpenJDK
no longer needs to do that. Accordingly, the jdk8u master and dev
forests are adequate for our current needs. Please see
http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-July/003985.html
for details.

If for some reason you strive to create your own build process for JDK 8
Updates, I'd suggest subscribing at least to the jdk8u-dev, jdk9-dev and
build-dev mailing lists.

Instructions for checking out the code for the latest release developed
within the JDK 8 Updates Project in OpenJDK can be found on the
Project's web page. Please keep in mind that CPU releases like 8u51 are
not developed within OpenJDK Projects.

In addition the fact that the bug system is locked down

Please consult the "Account Eligibility" section of
https://wiki.openjdk.java.net/display/general/JBS+Overview for the facts.

If you are not eligible for an account on JBS, because you're not an
OpenJDK developer with an adequate role, you may still file issues
through the web interface at bugs.java.com.

The following patch fixes this

Please see http://openjdk.java.net/contribute/ for how to contribute to
OpenJDK Projects, and note in particular the requirements spelled out in
section 0.

Of particular note for the contribution flow to the JDK 8 Updates
Project is that changes to it will typically go through JDK 9 first.

So once your organization meets the requirements spelled out in the
guide above, I'd suggest adjusting, testing and sending your proposed
patch as plain text within an e-mail to the build-dev mailing list for
JDK 9 first. Once it has been reviewed and pushed there, then you can
follow up with a backport for the JDK 8 Updates Project. Details on the
backport process can be found at the JDK 8 Updates page linked above.

As we rely heavily on being able to provide up to date, consistent,
secure OpenJDK builds to our customers

Unfortunately, I don't see your organization listed at
http://www.oracle.com/technetwork/community/oca-486395.html so I'd like
to again refer you to the guide for contributing to OpenJDK linked above.

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, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

Carlos de Luna Saenz

2015-11-12 15:18:44 UTC

Permalink

I'm sure this topic has arise sooner here... but PPAPI is being considered... lot of oraganizations relies on Java applets for key based authentication and is a very important deal...
If you can clear me on what's the future of applets fron open JDK perspective i will appreciate it.Greetings
De: dalibor topic <***@oracle.com>
Para: jdk8-***@openjdk.java.net
Enviado: Jueves, 12 de noviembre, 2015 8:53:18
Asunto: Re: Coherent release process

if/when the OpenJDK project may develop a more coherent release plan?

The lack of consistency among branches for different releases makes
it extremely hard to create a well defined build process for OpenJDK.

In addition the fact that the bug system is locked down

The following patch fixes this

As we rely heavily on being able to provide up to date, consistent,
secure OpenJDK builds to our customers

Dalibor Topic

2015-11-12 18:21:45 UTC

Permalink

Post by Carlos de Luna Saenz
I'm sure this topic has arise sooner here... but PPAPI is being considered... lot of oraganizations relies on Java applets for key based authentication and is a very important deal...
If you can clear me on what's the future of applets fron open JDK perspective i will appreciate it.Greetings

From the mention of PPAPI I assume that this question is about a browser plugin. There is no implementation of a browser plugin in OpenJDK.

cheers,
dalibor topic
--
Oracle <http://www.oracle.com>
Dalibor Topic | Principal Product Manager
Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961 <tel:+491737185961>
Oracle Java Platform Group

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, Astrid Kepper, Val Maher

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment

Andrew Hughes

2015-11-20 03:34:57 UTC

Permalink

[Adding in the 8u mailing list]

----- Original Message -----

Hi,
I was wondering if/when the OpenJDK project may develop a more coherent
release plan? Right now, there seems to be no consistent strategy, which
makes it very difficult for downstream consumers of OpenJDK to be able to
reliably build out new OpenJDK releases. While I appreciate that the
process has become easier with OpenJDK 8 vs the prior OpenJDK versions,
right now the build process for new releases, particularly critical
security updates, seems quite the mess.

+1. I've said pretty much the same before and it's only got worse of late.
The number of people I have to explain it to, even people who actively work
on OpenJDK on a daily basis, suggests it's far from obvious. It's nice to
know I'm not the only one who feels this way.

To build OpenJDK 1.8u66, you have to use the jdk8u (JDK 8 Updates Master)
branch (doesn't make sense)
To build OpenJDK 1.8u60, you use the jdk8u60 release branch (makes sense)
To build OpenJDK 1.8u51, you use the jdk8u60-dev branch (doesn't make sense)

Actually, that won't get you u66 unless you explicitly check out a tag.
The current tip of 8u is currently receiving fixes people are pushing for u76,
which I believe is due to be released next April, at the same time as the u75
security update, which will be based on u72.

As far as I've been able to grasp, this is the current 8u schedule:

October 2015: u65 (security update based on u60) & u66 (feature release)
January 2016: u71 (security update based on u66) & u72 (feature release)
April 2016: u75 (security update based on u72) & u76 (feature release)
July 2016: u81 (security update based on u76) & u82 (feature release)

You should be able to get all versions from the 8u tree by checking out
appropriate tags. Only 8u65 onwards will be up to date with the latest
security fixes.

The lack of consistency among branches for different releases makes it
extremely hard to create a well defined build process for OpenJDK.

Moreover, the recent changes, as I've mentioned before, also make it
virtually impossible to test something like u72 before it is released.
What I witnessed with u66 was the first few builds being pushed to the
8u tree, but later builds did not appear until u66 was released in late
October. When I raised this before, it was pointed out that the build
could be reconstructed by finding bugs in the bug database that had been
tagged as added to the release and backporting them to a checkout of
the latest u66 tag myself [0]. Not only is this incredibly time consuming
and error prone, but there is no guarantee that the result is the same
as what Oracle are testing. I really don't think the OpenJDK project as
a whole should suffer because Oracle change their internal processes.

In addition the fact that the bug system is locked down makes it extremely
hard to report issues back upstream, such as the fact that the hgforest.sh
script doesn't correctly honor command arguments, meaning that it has to be
patched to get a consistent build of the downstream modules that get
checked out. The following patch fixes this rather significant problem.
<http://fpaste.org/289480/44729880/>
As we rely heavily on being able to provide up to date, consistent, secure
OpenJDK builds to our customers, having the process to build new releases
be reliable is of significant importance. I imagine that is the case for
many others as well.

Another problem I've also observed. I'm happy for you to ping me if you have
a patch and need a bug opening (I've done this for colleagues at Red Hat),
but as Dalibor mentions in response, the OCA needs to be sorted first. There's
not much point opening a bug with a patch if the patch can't be committed for
legal reasons.

Thanks for your time and consideration,
Quanah
--
Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[0] http://mail.openjdk.java.net/pipermail/jdk8u-dev/2015-September/004212.html

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

Quanah Gibson-Mount

2015-11-20 03:45:51 UTC

Permalink

--On Thursday, November 19, 2015 10:34 PM -0500 Andrew Hughes

Post by Andrew Hughes
[Adding in the 8u mailing list]
----- Original Message -----

Hi,

Hi Andrew,

Thanks for the follow up!

Post by Andrew Hughes
Actually, that won't get you u66 unless you explicitly check out a tag.
The current tip of 8u is currently receiving fixes people are pushing for
u76, which I believe is due to be released next April, at the same time
as the u75 security update, which will be based on u72.

Yes, I use a tag for building. However, that process is completely
unreliable UNLESS you use my patch, because the tag is not passed down when
pulling out the sub modules, which means you get mismatched code. I.e.,
without my patch, you cannot build a consistent OpenJDK release against a
specific tag.

Post by Andrew Hughes

<http://fpaste.org/289480/44729880/>
As we rely heavily on being able to provide up to date, consistent,
secure OpenJDK builds to our customers, having the process to build new
releases be reliable is of significant importance. I imagine that is
the case for many others as well.

Another problem I've also observed. I'm happy for you to ping me if you
have a patch and need a bug opening (I've done this for colleagues at Red
Hat), but as Dalibor mentions in response, the OCA needs to be sorted
first. There's not much point opening a bug with a patch if the patch
can't be committed for legal reasons.

I can't see why it'd be a problem to have the patch committed. It's
literally modifying hgforest.sh to include the ${command_args} command line
options that were originally passed get_source.sh. Again, without this
patch, there is literally no way to build OpenJDK where all portions of the
checkout from mercurial are fixed to a given tag.

--Quanah

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

Quanah Gibson-Mount

2015-11-20 03:56:24 UTC

Permalink

--On Friday, November 20, 2015 1:51 PM +1000 David Holmes

Trivial patches can be accepted without the provider being an OCA
signatory. However the patch must be provided using OpenJDK technology so
it can't be taken from an external website, but if small enough should be
included inline in an email message.

--- jdk8u60/common/bin/hgforest.sh.orig 2015-08-10 16:29:42.271352215 +0000
+++ jdk8u60/common/bin/hgforest.sh 2015-08-10 16:36:53.427337849 +0000
@@ -334,8 +334,8 @@
done
fi
# run the clone command.
- echo "hg${global_opts} clone ${clone_newrepo} ${i}" >
${status_output}
- (PYTHONUNBUFFERED=true hg${global_opts} clone ${clone_newrepo}
${i}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 &
+ echo "hg${global_opts} clone ${command_args} ${clone_newrepo}
${i}" > ${status_output}
+ (PYTHONUNBUFFERED=true hg${global_opts} clone ${command_args}
${clone_newrepo} ${i}; echo "$?" > ${tmp}/${repopidfile}.pid.rc ) 2>&1 &
else
# run the command.
echo "cd ${i} && hg${global_opts} ${command} ${command_args}" >
${status_output}

--

Quanah Gibson-Mount
Platform Architect
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

Andrew Hughes

2015-11-20 03:39:35 UTC

Permalink

----- Original Message -----

Post by dalibor topic

if/when the OpenJDK project may develop a more coherent release plan?

You can find the plans for JDK 9 at
http://openjdk.java.net/projects/jdk9/ . The plans for JDK 8 Updates are
linked off the Project page of the corresponding JDK 8 Updates Project
in the OpenJDK Community at http://openjdk.java.net/projects/jdk8u/ .
The corresponding Project's mailing list, jdk8u-dev, is the right place
to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has
completed its work with the JDK 8 GA a while ago, so this list is
largely dormant.

Is there a good reason for this practice? Having seen this happen with
both 7/7u and 8/8u mailing lists, it would seem to make sense to keep
one mailing list instead when 9 goes GA, to avoid this confusion.

It's things like this that make OpenJDK confusing to new users and
I don't see the necessity for it myself.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

dalibor topic

2015-11-27 11:59:47 UTC

Permalink

Post by Andrew Hughes

Post by dalibor topic
The corresponding Project's mailing list, jdk8u-dev, is the right place
to ask questions about JDK 8 Updates in OpenJDK. The JDK 8 Project has
completed its work with the JDK 8 GA a while ago, so this list is
largely dormant.

Is there a good reason for this practice?

Yes.

A JDK Release Project like JDK 8 is very different from a JDK 8 Updates
Project, even though one provides the source code necessary to seed the
other.

As a trivial example of the differences, a JDK Release Project works
towards a single release, and then it's done. A JDK Updates Project
tends to work on multiple releases in parallel, provided at a higher
frequency. Accordingly, the processes, the development life cycle, etc.
are quite different. It's much simpler to start from a clean slate in a
new Project, then to retrofit an existing one for a new purpose.

Post by Andrew Hughes
Having seen this happen with
both 7/7u and 8/8u mailing lists, it would seem to make sense to keep
one mailing list instead when 9 goes GA, to avoid this confusion.

No.

Please see http://openjdk.java.net/projects/ : "A Project may have web
content, one or more file repositories, and one or more mailing lists"

Mailing lists are Project-specific. Once a Project finishes its work,
its mailing list(s) eventually gets dormant and archived, rather than
reused for other Projects. See
http://mail.openjdk.java.net/pipermail/coin-dev/2015-April/003487.html
for an example.

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, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment

Andrew Hughes

2015-12-04 18:37:38 UTC

Permalink

----- Original Message -----

Post by dalibor topic

Post by Andrew Hughes

Is there a good reason for this practice?

Yes.
A JDK Release Project like JDK 8 is very different from a JDK 8 Updates
Project, even though one provides the source code necessary to seed the
other.
As a trivial example of the differences, a JDK Release Project works
towards a single release, and then it's done. A JDK Updates Project
tends to work on multiple releases in parallel, provided at a higher
frequency. Accordingly, the processes, the development life cycle, etc.
are quite different. It's much simpler to start from a clean slate in a
new Project, then to retrofit an existing one for a new purpose.

Post by Andrew Hughes
Having seen this happen with
both 7/7u and 8/8u mailing lists, it would seem to make sense to keep
one mailing list instead when 9 goes GA, to avoid this confusion.

I'm well aware of how things currently operate. However, in practice,
this causes confusion for those not working on OpenJDK every day and could
be improved. I'm not aware of any other FOSS project that endlessly spawns
new mailing lists for the sake of some overly-bureaucratic rules, and it
would be nice to see the OpenJDK project acknowledge that this is problematic
and adjust accordingly.

Thanks,
--
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04 C5A0 CFDA 0F9B 3596 4222

PGP Key: rsa4096/248BDC07 (hkp://keys.gnupg.net)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F 8F91 3B96 A578 248B DC07

dalibor topic

2015-12-04 19:38:01 UTC

Permalink

Post by Andrew Hughes
I'm well aware of how things currently operate. However, in practice,
this causes confusion for those not working on OpenJDK every day and could
be improved.

We could archive mailing list of JDK Release Projects faster, I guess.

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, Astrid Kepper, Val Maher

<http://www.oracle.com/commitment> Oracle is committed to developing
practices and products that help protect the environment