Changes to 8u and 11u process

[Aleksey Shipilev]

(was surprised why it was not discussed here before, because I have comments)

On 8/6/19 3:46 PM, Andrew Haley wrote:
> 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.

I vehemently oppose this rule.

First, this dismantles the consistency of the process ("every change should be approved, here is the
checklist [1]") for the sake of less maintainer work (which can be alleviate by assigning more
maintainers, as we did with Christoph). Having a single checklist for everything is simpler to
remember, simpler to act upon, and it provides less cognitive load. We need to continue doing the
same thing on all paths, and if on some of those paths it would reduce to mechanical rubber-stamping
work, so be it. It is the same as with code reviews in trivial patches: we do not circumvent the
review process by telling "trivial patches do not need review", we just say "trivial patches enjoy
more mechanical rubber-stamping approach".

Second, summarily accepting every Oracle-proprietary change dismantles the maintainers'
responsibility over everything in JDK Updates projects. There are changes that could be rejected
from JDK Updates, even if Oracle-internal repositories have it: platforms not supported, features
not maintained, cleanups not needed. We have to reserve the opportunity to act upon this, if/when
needed. It feels like this rule should just go to maintainer's rule book: once somebody requests the
backport for something Oracle-proprietary fork has, rubber-stamp it. But do not summarily relinquish
maintainer's power to veto.

> Backports of fixes to tests no longer need to be approved, but they
> should still be reviewed if there are any changes.

Same thing as above.

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

Understanding that retrofitting the patch comes with the risks in itself, in many cases bringing up
more code is better, if it minimizes the difference against other versions, applies mechanically,
matches the history of the later code. So, I think we should default to bringing in the patches
wholesale, and leave it to maintainers/reviewers to ask backporters to cut the patches shorter if
maintainers/reviewers argue there is no reason to bring large change with it. It happened multiple
times already, and I don't think it needs to be changed.

-- 
Thanks,
-Aleksey

[1] https://wiki.openjdk.java.net/display/JDKUpdates/How+to+contribute+a+fix