Changes to 8u and 11u process

[Lindenmaier, Goetz]

Hi Aleksey, 

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

You can as well argue that the need to get an approval for a change
increases the work and thus the possibility to make errors. 
You can not expect the maintainer to approve changes on a daily 
basis. Thus, you get quite some delays with the work on the changes. 
You downport them, test them, ask for approval, and once you get 
it you need to rebase the change and retest them. This rebasing and retesting
is overhead that could be avoided.  Also, personally, I don't like working
on too much changes in parallel. If getting the approval takes a week, 
this limits efficiency.  From my work on our internal JVMs, I know that 
you can move quite a lot of changes on a single day without breaking
anything.

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

Why should we reject changes to a platform supported by Oracle but not
by OpenJDK?  Has there ever been a change downported by Oracle that
was not taken into OpenJDK 11?
And if the two projects OpenJDK 11 and OracleJDK 11 would diverge so 
that this happens, we still could change the policy again.

I would appreciate if the "Fix Request" comment would still be mandatory, 
simply to indicate someone is working on a change. 
But I really think the tagging is unnecessary overhead for the Oracle changes.
And anybody who misunderstands this and puts a jdk11u-fix-request tag there, 
will get an approval and no harm is done.  And well, yes, it would be bad
if it happened the other way around. But people being less involved in 
the updates project probably come up with changes of their own for which 
the established process holds and thus never get in touch with this 
"shortcut rule".

For testbug fixes not downported by Oracle we should maybe 
request tagging, but for changes downported by Oracle we should
relax this rule I think.

Best regards,
  Goetz.



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