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