Bake time in JDK8 before 7u ?

[Erik Trimble]

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