JDK Updates Project Page

[Rob McKenna]

Yep, an LTS may require some special casing. Since the first of these is
about a year away I'd like to focus on ensuring the process works for
the new release cadence for 9u/10u before dealing with LTS specific
changes to the project rules.

I agree that it is an important conversation that needs to take place
once we have a bit more experience with the new release cadence and
prior to the first of the LTS releases, perhaps around 6 months or so
down the road.

    -Rob

On 10/11/17 17:24, Mario Torre wrote:
> 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