[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jdk8-dev
Subject:    Mercurial forests for JDK 8
From:       kelly.ohair () oracle ! com (Kelly O'Hair)
Date:       2011-05-31 20:49:10
Message-ID: 7B1C4B5F-7D39-49D9-A138-49FF69460F57 () oracle ! com
[Download RAW message or body]


On May 31, 2011, at 10:02 AM, David Katleman wrote:

> On 5/30/2011 11:45 AM, Roger Calnan wrote:
> > depending on the integration.  How about having an "integration baton" rather \
> > than a schedule and see if issues come up.  There would then only be one regular \
> > slot for RE.
> 
> Integration schedules were setup not just for build stability, but also to spread \
> out integrations through the entire week.   We also manipulated the schedule to \
> separate integrations that proved to be problematic.

But part of the reason for that spreading out was also related to SQE resources, or \
their ability to turn around a PIT (Pre Integration Testing) report/approval \
certificate, which is a formalism I'd like to completely automate so we don't have a \
people resource limitation. The hardware/system resource issues can't be ignored of \
course.

> 
> Prior to the schedules, integrations tended to bunch up just before the promotion \
> dates, with little change going in for the first half of a week.  That bunching \
> contributed to build failures at promotion time, rather than having those failures \
> earlier in a weekly cycle, where there is more time to recover.

Yes, the old traffic jam issue just before a milestone or promotion build. :^(
We should be operating on a train schedule, and if developer changes are
not ready when it's time for the promotion train to leave the station,
they just need to wait for the next train. Delaying the boarded passengers is \
unacceptable.

And we should have a fixed number of integrations per 24hr period,
just the time needed for sync&build&test.

> I'm not opposed to a more free style approach to integration, especially with the \
> considerable consolidation of groups, as long as we can manage the bunching.

If the integrator has a fixed amount of time for doing his sync&build&test \
verification, then I think we have managed the bunching.

It is most critical that the master repos always build, it's the testing that becomes \
more problematic, at least until we define what "testing" means for an integration.

-kto

> 
> Dave
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]