JDK Updates Project Page

[Mario Torre]

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