Changes to 8u and 11u process

[Lindenmaier, Goetz]

Hi Andrew, 

I appreciate these simplifications a lot! I also share your
concerns wrt. feature backports.   Thanks for appointing
Christoph a maintainer!

Best regards,
  Goetz.



> -----Original Message-----
> From: jdk-updates-dev <jdk-updates-dev-bounces at openjdk.java.net> On
> Behalf Of Andrew Haley
> Sent: Tuesday, August 6, 2019 3:47 PM
> To: jdk8u-dev at openjdk.java.net; jdk-updates-dev at openjdk.java.net
> Subject: Changes to 8u and 11u process
> 
> We've been running 8u and 11u for two quarters now, and it's time to
> adjust our processes.
> 
> First, the easy one: Christoph Langer is now a maintainer of JDK 11u.
> 
> Backports which have already been approved by Oracle for their
> proprietary fork will no longer need approval for 8u- and 11u-open.
> There are two reasons for this. Firstly, it's safe to assume that
> Oracle have done their due diligence with regard to suitability.
> Secondly, it's a waste of effort on the part of the maintainer.
> 
> Backports of fixes to tests no longer need to be approved, but they
> should still be reviewed if there are any changes.
> 
> We will use the CSR process, with the help of the CSR team, for any
> backports of patches which required CSRs in mainline. Hopefully this
> will be rare, and the CSR team will process review requests promptly.
> 
> Finally, more of a recommendation.
> 
> Rule #0: Do no harm.
> 
> I know of no very strong reason why 8u- and 11u-open should in general
> have much more churn than the corresponding closed projects. If they
> have, there is a serious risk that they will be less stable. We must
> avoid, above all else, the open updates being (or being perceived as)
> less reliable than the closed. [That being said, we've already made
> the decision to backport some major items; it's a delicate balance.]
> 
> Where it makes sense, please minimize the size of the patches. If you
> can adapt a backport patch to fit rather than also backporting a bunch
> of its dependencies, please consider doing so. Bear in mind that
> stability is the most important feature that these updates projects
> have. Simple history in backports is important: it's more important to
> reduce the volume of changes to 8u and 11u than it is to reduce the
> differences between the backports and head.
> 
> Feature backports should be treated with a degree of skepticism. 8u
> and 11u are stable maintenance versions not development branches, so
> features shouldn't be backported without a compelling reason and a
> careful analysis of risk. Please discuss such backports on the list.
> 
> --
> Andrew Haley  (he/him)
> 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