Mercurial forests for JDK 8

Kelly O'Hair kelly.ohair at oracle.com
Tue May 31 17:36:24 PDT 2011


On May 31, 2011, at 1:45 PM, Vita Santrucek wrote:

> 2) QE as integrators - QE is responsible for the verifying the fixes and 
> overal component quality. As such, QE should perform the gate-keeping 
> function for their components. This will further speed up the frequent 
> integrations and also it will allow QE to provide proper coverage before 
> integrating. This model has been used by JRockit.

I don't understand how changing from the current integration process we have now, to having it
done by a QE integrator speeds anything up or can increase the frequency in any significant way.
If you are suggesting having more integrators could speed things up, that may work to a degree,
but at some point it won't help to just throw more people at it.

> 
> So the proposed process would be:
> 
> 1) developer creates a fix/feature
> 2) developer tests the fix on his local repo code
> 3) developer(s) integrate(s) a fix into the component repo
> 4) QE runs CI/PIT (coverage as agreed by the component team)
> 5) QE reserves a slot and integrates to the master repo
> 6) other component teams pull the changes (each promo time or more 
> frequently)
> 
> For some teams, this effectively takes the integration process from 
> weeks to a day. Most interaction bugs would be found within a week.

I don't see the "day" here, and I'm not sure I see much difference from what is happening now.

Steps 1-3 have been documented here:
  http://openjdk.java.net/guide/changePlanning.html#bug
granted it needs a little refreshing.

Steps 4-5 have traditionally been assigned to the official "integrator" for a team, who also serves
as a go-between QE, the development team, and release engineering for that integration.
It used to be a rotating assignment in the development team because the complications of
syncs and merges can require developer involvement, or 'walk down the hall' face-to-face interactions.

I'm concerned that "QE as integrators" just moves the work around and perhaps just moves the
bottleneck around.

-kto




More information about the jdk8-dev mailing list