Coherent release process

[Andrew Hughes]

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

> 
> For example:
> 
> 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