JDK Updates Project Page (original) (raw)

Rob McKenna rob.mckenna at oracle.com
Fri Nov 10 16:39:07 UTC 2017

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

More information about the jdk-updates-dev mailing list