Mercurial forests for JDK 8
georges.saab at oracle.com
Mon May 30 11:28:26 PDT 2011
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.
> 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.
More information about the jdk8-dev