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