jdk11u-dev is now switched to 11.0.5

[Lindenmaier, Goetz]

Hi Andrew,

> >>> Yes, there is some overhead, it does not make things more
> >>> simple.  You could delegate some tasks.
> 
> But that won't reduce the overhead: all it will do is spread it out.

Some simple steps, like switching from 11.0.n to 11.0.n+1 require
several people. This is overhead that would go away if all is 
in one hand.  I.e., if I could ping ops for the JBS update, this 
would save the indirection of asking you to do that.  This again
might reduce the time the repo is closed, and thus the 
chance for wrong pushes. 

> >>> E.g.,
> >>>   * I would volunteer to trigger the update of the JBS version
> >>>      For 11 whenever needed.
> >
> > Do you mean the hgupdater changes via ops? I think usually both 8u & 11u
> > should be handled at the same time to minimise such updates.
> 
> But how? It's not as if the projects are perfectly synchronized. Sure,
> if they happen to need changing at the same time, then we can do so.
> 
> > I'm not
> > sure if anyone but the lead would be accepted for such a request.
> 
> I'm sure I can delegate anyone to do it.
> 
> >>>   * You could allow to push the version bump without
> >>>      jdk11u-fix-yes tag. It's obvious we need it.
> >
> > That makes sense to me, given we have no such approval process for the
> > equivalent process of tagging the repository.
> 
> Yes.

Thanks. I'll skip the tagging next time.


 
> > I've been thinking about this for 8u too [0] and, as both 8u & 11u allow
> > multiple changesets to use the same bug ID, I think keeping such bumps
> > under the same bug ID is a better idea than creating numerous bug IDs
> > just for version updates. That also elegantly solves the approval
> > process issue without the need for exceptional cases.
> >
> >>> Further, I would propose that we exclude all changes Oracle
> >>> pushes to their 11.0.x from the tagging if pushed to
> >>> the open 11.0.x (same x!).
> >>> They have already been judged to be good for downport by Oracle.
> >>> The "Fix Request" comment should be added to the change
> >>> nevertheless. This way one can know that a change is being
> >>> worked on.  Maybe we should note in the bug that it is a downport
> >>> that went to Oracle's 11.0.x, so it's clear why it is not tagged.
> >
> > I strongly disagree with this. It would amount to most of the changes
> > not going through the approval process.
> >
> > I can see that with 11u, in its present state, this may mean a lot of
> > rubber stamping of clean backports, because 11u has not diverged much
> > from trunk. However, with 8u, the backported patch can frequently be
> > quite different, and approval should be of that reviewed patch, not
> > based on a decision at Oracle we know nothing about.
> 
> The backported patch, if different from the patch applied at head,
> will have to be reviewed. That's when the code walkthrough and the
> impact should be assessed. On the other hand, approval says that, in
> principle at least, this change is one that we want in the release
> branch.
> 
> > I expect, with time, 11u will diverge in a similar way and so the
> > approval process will be more involved. I definitely think the solution
> > here is more hands on deck, not effectively removing the process altogether.
> >
> >> Those seem good suggestions to me. I also think that you could
> >> extend the group of maintainers, that is, people who can approve
> >> backports. Andrew (Hughes) is already listed for 8u but 11u could
> >> also use additional approvers. However, if you do that, you should
> >> give some rules and criteria that the approvers have to follow.
> 
> Definitely, yes. The thing holding me back from appointing more
> maintainers, still, is that I perceive a lack of consensus about the
> criteria by which a backport should be judged. I personally would be
> strict about this: serious bugs and regressions, plus perhaps some
> important performance improvements.  However, there seems to be a
> general sentiment that we don't want to diverge from Oracle, so some
> pretty trivial backports have been approved.

Personally I think the approval for one Java version should
be in one hand (excluding substitute for absences) to make
sure it remains consistent what kind of changes are permitted.
If the changes downported by Oracle are excluded from approval,
it should not be that many anymore.
And developers should be patient to wait for weekly approvals.

> To some extent I accept the "don't diverge" reasoning because feature
> differences between OpenJDK and Oracle are to be avoided if possible:
> we don't want to confuser our users unnecessarily.
> 
> > I'm open to doing 11u as well. I often have to remind myself I can't
> > do that one when something comes up for both 8 & 11. I also think we
> > should have at least a third maintainer on both projects, ideally
> > from outside Red Hat.
> >
> > The primary things I look at for approval is the potential effect it
> > has. Test cases are pretty unproblematic as are arch-specific
> > changes coming from those maintaining that architecture. I'm more
> > critical of general changes and try to ensure that there's nothing
> > in there that will alter API compatibility.
> 
> This is a good start. If we can agree what criteria we should apply
> when approving a backport then we can share the maintainer's role.

Yes, makes sense.  But between maintaining an architecture and 
altering the API there is a huge gap ...

Best regards,
  Goetz.

> > Also, ensuring the correct process is followed ends up being part of
> > approval, so e.g. I will ask for a review if one isn't listed and
> > seems needed, and other such sanity checks.
> 
> That imposes a strict ordering: review first, then approval. I think
> that approval and review can run in parallel: we don't want to fully
> review every backport patch twice.
> 
> --
> Andrew Haley
> Java Platform Lead Engineer
> Red Hat UK Ltd. <https://www.redhat.com>
> https://keybase.io/andrewhaley
> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671