Bake time in JDK8 before 7u ? (original) (raw)

Erik Trimble trims at netdemons.com
Mon Sep 5 18:11:36 PDT 2011

On 9/5/2011 12:55 PM, Edvard Wendelin wrote:

Hi,

While it would certainly be nice to let the fixes get some bake time in JDK 8 before going into 7 updates, I think there are a few other factors that are also important. If developers are allowed to submit the fix to both forests at the same time, it lets them work the bug in one go, instead of having to context switch after 2 (or so) weeks and pick up the left overs. When I deal with forward/back-ports I prefer to take care of it ASAP and then move on to the next thing on my list. Secondly I think its good to get the fixes integrated sooner rather than later in the project, so that the fix goes through as many QA cycles as possible. I also think we can afford to be more liberal in this phase of the project. Once we enter phase 2 and create the stabilisation forests, the process for integrating fixes will be different.

Cheers, Edvard On 3 sep 2011, at 10.58, David Holmes wrote: Most fixes to 7u must go to 8 first. I assume at least part of the reason for this is to have fixes "bake" in 8 before coming down into 7u. But I'm seeing a lot of pushes to 8 followed (sometimes within minutes) by requests to push to 7u. I know there are various schedules to adhere to but it seems to me that the requirement to push to 8 before 7u is not serving any purpose in these cases.

David

Edvard makes a good point about reducing the cognitive and logistical load on developers, however, that assumption presumes there are equal testing resources being allocated to BOTH 7u and 8.

Last I'd heard, there were actually more QA resources going to 7u than 8 for the time being, as 7u1 and 7u2 had a rather high priority on work to solve some of the issues discovered in JDK 7 FCS.

We do need to take into account the QA load and resource availability when setting developer policies. As such, we definitely should be flexible about adjusting commit policies over time to reflect those (possibly shifting) resource realities.

-Erik

More information about the jdk7u-dev mailing list