Mercurial forests for JDK 8

[Georges Saab]

If I have understood correctly the present system of the 'static and somewhat fixed schedule
of integrations' was introduced a number of years ago when there were lots of issues with
destabilizing (ok, build breaking!) changes coming in,  And that it has been successful in
preventing these, albeit at quite a bit of cost.

So what (other than momentum) is preventing us from having a more nimble integration
capability?  In my naive view, it looks to be having better testing (as in more effective -- less but 
more tailored to hit the issues in a particular integration repo). 

I like Kelly's suggestion of viewing it as a 'budget of time' -- i.e. we should figure out the best set
of tests for a repo that can be run within 24 hours'.  I think there is more that can be done here
to make sure integration repos stay clean...


On 30 maj 2011, at 10.09, Kelly O'Hair wrote:

> 
> On May 24, 2011, at 2:35 PM, Phil Race wrote:
> 
>> I also think there's a tenuous connection between merging these and getting fixes into
>> master at a faster rate.
>> 
>> -phil.
> 
> I have to agree with Phil here.
> 
> Although the number of team forests does need to be controlled, the primary issue with getting fixes
> into the master repos is the speed and timing of integrations.
> In my opinion, the current static and somewhat fixed schedule of integrations needs to be made more dynamic,
> allowing for an integration to happen in a more 'on demand' way.
> The time it takes to do an integration also needs to be addressed.
> Integration testing needs to be completely automated, and false negatives need to be minimized to
> speed up the analysis phase.
> 
> The actual integration itself cannot be completely automated (merges or syncs with the master must
> always be watched carefully) but many of the large steps in the integration process can be automated.
> Ideally, we should be able to have all team areas ready for an integration on a 24hour basis, based on
> an inspection of acceptable results, a sync with master changes, a quick re-build and re-test, and a push.
> Just my opinion.
> 
> -kto