jdk11u-dev is now switched to 11.0.5

[Andrew Haley]

On 6/3/19 8:04 AM, Lindenmaier, Goetz wrote:
> 
> 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. 

I'm happy with that.

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

I think I get your point.

The problem is that these two goals are in opposition:

1. Preserve stability and prefer safety by minimizing
   potentially-breaking backport patches.

2. Keep in step with Oracle.

I've been favouring 2. There are good reasons for this, in particular
that many users are now moving to OpenJDK from Oracle's proprietary
binaries, and those users want idenatial behaviour.

There's also the guidelines in https://openjdk.java.net/projects/jdk6/:

   Changes allowable within the Java SE 6 specification may still be
   rejected for inclusion in OpenJDK 6 if the behavioral compatibility
   risk is judged as too large. Behavioral compatibility concerns
   implementation properties of the JDK. Clients of the JDK can
   knowingly or unknowingly come to rely upon implementation-
   specification behaviors not guaranteed by the specification and
   care should be taken to not break such applications needlessly. In
   contrast, if a change is appropriate for every other JDK release
   train, it is generally appropriate for OpenJDK 6 too. Examples of
   such universal changes include security fixes and time zone
   information updates.

   With the above caveats, bug fixes in JDK 7 that do not involve
   specification changes have presumptive validity for OpenJDK 6. That
   is, by default such fixes are assumed to be applicable to OpenJDK
   6, especially if having "soaked" in JDK 7 for a time without
   incident.

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

True, but that's what the CSR process is for.

I'd like the guidelines to be clear enough that, for most patches, the
decision would be the same regardless of who did the approval. I
accept that there are judgment calls to be made sometimes, but these
should be based on a common understanding.

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