jdk11u-dev is now switched to 11.0.5

[Andrew John Hughes]

On 30/05/2019 22:56, Langer, Christoph wrote:
> Hi,
> 
>>> The level of bureaucratic overhead in these projects is getting absurd.
>> We're
>>> 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.
>>
>> 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. I'm not
sure if anyone but the lead would be accepted for such a request.

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

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.

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.

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.

> 
> Best regards
> Christoph
> 

[0] https://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009508.html
-- 
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