JDK Updates Project Page

[Lindenmaier, Goetz]

Hi,

yes, I think too that we need different rules for LTS. 
We backported the ppc port to 8, and some later
the ppc le port. It would be bad if such changes could
not be brought to LTS releases. 

For the short living feature releases backporting only 
P1 bugs is fine.

Best regards,
  Goetz.

> -----Original Message-----
> From: jdk-updates-dev [mailto:jdk-updates-dev-bounces at openjdk.java.net]
> On Behalf Of Mario Torre
> Sent: Friday, November 10, 2017 5:24 PM
> To: Rob McKenna <rob.mckenna at oracle.com>
> Cc: jdk-updates-dev at openjdk.java.net
> Subject: Re: JDK Updates Project Page
> 
> On Fri, Nov 10, 2017 at 4:40 PM, Rob McKenna <rob.mckenna at oracle.com>
> wrote:
> > Thanks for the feedback,
> >
> > 1) Moving to a single page makes sense, we can always split it up as
> > necessary if we end up adding to the process docs.
> >
> > 2) As David notes the bug approval process will be JBS only, no email
> > template involved.
> >
> > 3) We're sticking with the current codereview practices for a couple of
> > reasons:
> >
> >   - Codereview is a contentious issue and out of scope for the updates
> >     project
> >   - Moving to JBS would limit participation to those with JBS logins
> >   - Reviewers are used to monitoring the appropriate email aliases,
> >     introducing a separate process for them to follow would introduce
> >     unnecessary complications
> >
> > 4) As noted in the approval page, the public codereview must be
> > completed prior to requesting critical approval.
> >
> > 5) We're setting a higher bar here for update release content. The
> > process page specifies P1 bugs & serious regressions. If a fix is not
> > critical then it can likely wait until the next feature release which will
> > be available within 6 months. (this has the added benefit of incentivizing
> > users to pick up JDK fixes faster)
> >
> > 6) As Phil noted, we're moving to a model where we no longer mandate
> > that backports need to be fixed in all releases between the next feature
> > and the backport release.
> 
> Makes sense, thank you Rob and Phil for the explanation and summary.
> 
> I still think we should try to leave the door open to non critical but
> popular backports in updates though. This is especially important for
> LTS releases, I don't really see anything from this process that
> requires special casing for the LTS, but if we have a process that
> does not allow non critical backports we will need to have such
> special cases for the LTS or come up with a different process.
> 
> Cheers,
> Mario