JDK Updates Project Page (original) (raw)

Mario Torre neugens at redhat.com
Fri Nov 10 16:24:15 UTC 2017

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

More information about the jdk-updates-dev mailing list