jdk11u-dev is now switched to 11.0.5
aph at redhat.com
Fri May 31 17:25:17 UTC 2019
On 5/31/19 5:44 PM, Andrew John Hughes wrote:
> On 30/05/2019 22:56, Langer, Christoph wrote:
>>>> The level of bureaucratic overhead in these projects is getting absurd.
>>>> going to have to do something about it before we all drown.
>>> 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.
>>> * 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.
> I've been thinking about this for 8u too  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
> 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.
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.
> 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.
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the jdk-updates-dev