jdk11u-dev is now switched to 11.0.5

[Lindenmaier, Goetz]

Hi Andrew,

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

Yes, I also think that all changes Oracle pushes to 11.0.n should be
pushed to the open 11.0.n, too.  
This assures identical behavior, at least open 11 will not stay behind.
And I don't think this will affect stability. Oracle is doing a very good
job at testing, and we will see potential fixes pushed by them.
I rather think this improves stability.
Giving this simple rule, we don't need to tag them with jdk11u-fix-request.

But we need additional changes. Andrew Hughes mentioned the
architecture changes.  Other changes might be interesting for 
the community that Oracle does not downport.

For these changes we need the approval via jdk11u-fix-request etc.
and we need guidelines.  But we first need guidelines for 
developers what to consider for downporting. 
If you want to keep open 11 very close to Oracle's 11, these guidelines
must be very strict. If you want to allow 11 to evolve past
Oracle's 11, they can be less strict.

Once we have such guidelines, we can think about the guidelines
for delegating the approval process. 

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

This description makes completely sense to me.  

Nevertheless, for example JFR is downported to 8, which breaks this rule.
And I also think it makes sense to make an exemption for JFR.
I guess these are the judgement calls you talk about below.

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

I would be fine with Andrew Hughes also approving jdk11 changes.

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

Best regards,
  Goetz.



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