HotSpot bulk changes (Re: [7u-dev] Request for approval for CR 8005722)

Dmeetry Degrave Dmitry.Degrave at oracle.com
Mon Mar 4 08:34:57 PST 2013


On 03/04/2013 05:47 PM, Dalibor Topic wrote:
> On 2/28/13 4:37 PM, BILL PITTORE wrote:
>> Hmm, ok. I do recall having to send out a request last time I wanted to push into jdk7u-dev. Did I muddy up the waters by mentioning hs24 in my email?  So if I push into hs24, no approval needed. Push into jdk7u-dev, approval needed; correct?
>>
> HotSpot (and JAXP, JAX-WS, CORBA,..) fixes in 7u get integrated as bulk changes.

Is it really true for CORBA, or JAXP, or JAX-WS ?

thanks,
dmeetry

> Your changes
> concern HotSpot only, so they need to go through hs24.
>
> Bulk changes are approved on an 'all or nothing' base, since they carry more risk than single
> changes - breaking HotSpot, for example, breaks things for everyone, so it's better to know
> that a set of HotSpot changes has been successfully tested together and builds everywhere
> (and to discover such issues prior to the integration into the update tree), than to discover
> after the Nth push that something broke somewhere somehow.
>
> In either case one needs to track down the issue and fix it, but in the latter case no one else
> working on 7u needs to suffer in the mean time, and time (and reducing risk of losing it) is of
> essence for updates.
>
> So, if your fix is headed for hs24, then the integrator will take care of posting the bulk
> change approval request, and you don't have to do it yourself. If, for example, it's a fix
> for the core JDK libraries, or any other component not getting integrated as bulk changes, though,
> then you'd need to post your own approval request.
>
> One special case are changes core library changes that are tightly (i.e. builds and/or tests will break)
> integrated with HotSpot changes, like the last JSR 292 or VM tracing changesets - in those very few
> cases, it's preferable to have the JDK side of the change come in via a HotSpot bulk change, as well,
> to avoid a situation where one of the tightly connected parts has already landed in the 7u tree while
> the other has not.
>
> cheers,
> dalibor topic




More information about the jdk7u-dev mailing list