Changes to 8u and 11u process

[Andrew John Hughes]

On 06/08/2019 14:46, Andrew Haley wrote:
> We've been running 8u and 11u for two quarters now, and it's time to
> adjust our processes.
> 
> First, the easy one: Christoph Langer is now a maintainer of JDK 11u.
> 

I very much welcome this move as there have been delays in 11u
approvals, not to mention that having only one maintainer inevitably
means that there is no maintainer to approve the work of that person.
Christoph's continued diligent work in handling the 11u release process
makes him the obvious choice and I wish him well in the role.

> Backports which have already been approved by Oracle for their
> proprietary fork will no longer need approval for 8u- and 11u-open.
> There are two reasons for this. Firstly, it's safe to assume that
> Oracle have done their due diligence with regard to suitability.
> Secondly, it's a waste of effort on the part of the maintainer.
> 
> Backports of fixes to tests no longer need to be approved, but they
> should still be reviewed if there are any changes.

I strongly oppose this, for many of the reasons Aleksey has already
outlined.

To add further to that, I would point out that the decisions made by
Oracle for their proprietary fork are opaque to us, and so to do as
proposed would be to essentially hand control of the majority of our
work to a black box. I am vehemently of the opinion that the OpenJDK
projects should remain independent of such proprietary forks. Moreover,
I find it extremely odd to make such a decision to waive approval based
not on the change itself, but merely because it has been blessed by a
certain group that is not even involved in this project.

With reference to my experience as maintainer for 8u, I'll restate what
I said previously on this topic, which is that 8u backports are far more
likely to differ significantly from the originals than 11u backports
(and absolutely nothing applies as is due to all the file movement
between these versions). Far from my efforts being wasted, I think the
work I've been doing in approving backports has been a good safety
check, especially in these early days. It is one thing to review a patch
in isolation, but another to approve it in the context of 8u as a whole;
the concerns are different and it requires someone with a general
knowledge of the entire body of changes being made.

> 
> We will use the CSR process, with the help of the CSR team, for any
> backports of patches which required CSRs in mainline. Hopefully this
> will be rare, and the CSR team will process review requests promptly.
> 
> Finally, more of a recommendation.
> 
> Rule #0: Do no harm.
> 
> I know of no very strong reason why 8u- and 11u-open should in general
> have much more churn than the corresponding closed projects. If they
> have, there is a serious risk that they will be less stable. We must
> avoid, above all else, the open updates being (or being perceived as)
> less reliable than the closed. [That being said, we've already made
> the decision to backport some major items; it's a delicate balance.]

I believe overseeing this is exactly the role of a maintainer and why we
shouldn't cut them out of the picture for the majority of patches.

> 
> Where it makes sense, please minimize the size of the patches. If you
> can adapt a backport patch to fit rather than also backporting a bunch
> of its dependencies, please consider doing so. Bear in mind that
> stability is the most important feature that these updates projects
> have. Simple history in backports is important: it's more important to
> reduce the volume of changes to 8u and 11u than it is to reduce the
> differences between the backports and head.
> 
> Feature backports should be treated with a degree of skepticism. 8u
> and 11u are stable maintenance versions not development branches, so
> features shouldn't be backported without a compelling reason and a
> careful analysis of risk. Please discuss such backports on the list.
> 

Again, I concur with Aleksey here that the default should be to backport
dependants where possible. The viability of this is something for the
patch review process and concomitant approvals, which again brings in
the maintainer as well to give their opinion on whether such a backport
is necessary.

The problem with creating a more divergent change is that you then
create a burden for future backporters; if patch x is backported with
major alterations to avoid bringing in dependants, then patch y, which
applies on top of x, has to then also be altered, whereas it may instead
have been close to a clean backport if the divergence of x had been
minimised.

In short, it seems to me that the two sections here contradict one
another; rule #0 seems to scream out for someone to oversee the overall
set of patches being allowed into the update releases, while the second
proposal risks excluding that same person from overseeing the majority
of changes being made.

Thanks,
-- 
Andrew :)

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

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