Process proposal for Updating JDK 7u with Hotspot Express...

[Erik Trimble]

On 8/23/2011 10:10 AM, John Coomes wrote:

> Since Erik has left Oracle, I'll be filling in until a permanent
> hotspot gatekeeper is able to take over.
>
> I have some corrections and recommendations below.
>
All of John's comments make sense to me. More importantly, his changes reflect reality
of what the current 7u and 8 situation is.

My one comment is on the following section:

> 2a.) In addition, there will never be a Hotspot->7u integration until
> AFTER the same Hotspot version has been promoted into the JDK 8 forest,
> and undergone a full Release promotion cycle. This will be to make sure
> that the Hotspot version in hsx/hsxN/hotspot is indeed stabilized and we
> have worked out any immediately apparent serious issues. This may very
> well mean that Hotspot will not immediately promote all Hotspot builds
> unto 7u.  E.g. HS20 b01 may go to JDK 8 Build 01, but if there are
> problems detected, then HS22 will not be pushed into 7u until those
> issues are addressed in a new HS build. So, it is entirely possible that
> an integration into 7u will actually encompass several Hotspot build
> numbers.
> This restriction (2a) will have to be relaxed, at least somewhat.
> Since jdk8 builds are not yet happening regularly, requiring the
> hotspot snapshot to appear in a promoted jdk8 build before it can be
> integrated into 7u will delay 7u integrations for indefinite periods.
> So the requirement that a hotspot snapshot complete what Erik calls 'a
> full Release promotion cycle' in jdk8 before being integrated into 7u
> should be dropped.
>
> In addition, given that build schedules and release dates for 7u and 8
> are not aligned, I can easily foresee the case when deadlines will
> necessitate integration into 7u before integration into the jdk8
> master forest.
>
> So we should change the requirement that a hotspot snapshot be
> integrated into the jdk8 *master* before before being integrated into
> 7u.  Instead, the presence of a fix in *hsx/hotspot-main* should be
> enough to meet the requirement that a fix be present in jdk8.  The
> hsx/hotspot-main forest is used very much like the jdk8 integration
> forests used by other groups (e.g., jdk8/build/*, jdk8/tl/*, etc.), in
> that it is regularly pushed up to the jdk8 master.  The only
> difference is that it also delivers into other releases.  The process
> for approving individual fixes for 7u deems the presence of the fix in
> a jdk8 integration forest (e.g., jdk8/tl) as sufficient to meet the
> requirement that a fix be included in jdk8; the same should apply to
> hotspot.
I'd think that what I originally described for the 7u process (i.e. never integrate to 7u
until that change has been pushed into 8) is the goal process - that is, if all the QA
systems are up and running, and all JDK 8 and JDK 7u development work is going full steam,
then the we should adhere to the No 7u Before 8 restriction.

I know that's not the case now, and that 7u is currently being given more priority than 8,
so John's proposal is a good one (and, reflects the facts on the ground). Maybe about the
time 7u2 gets pushed out, things will have settled down sufficiently, and we can look
forward to going back to requiring a tested 8 push before the equivalent 7u push.

>> One specific point where I'm not sure how we want to proceed is this:
>>
>> Should #6 (the push of the Hotspot snapshot into 7u-dev/hotspot) happen
>> right after approval from the Technical Lead happen? If so, then it
>> likely will be BEFORE QA has finished on the snapshot. This would be in
>> line with the other JDK fixes, since they do not undergo QA before being
>> pushed to 7u-dev/*.  However, Hotspot is "special", so do we care to be
>> extra sure that 7u-dev/hotspot is stable?
>> ...
> I think hotspot should complete both a PIT cycle and a control build
> of the JDK before we integrate into 7u-dev since (a) we're doing bulk
> integrations and the amount of change may be rather large, and (b) we
> want to ensure that the hotspot in 7u-dev can be used as a bootstrap
> for a JDK build.  We currently don't test the latest hotspot as a
> bootstrap to build the JDK as part of our automated nightly or JPRT
> tests, so it should be done before integrating into 7u-dev.
>
> We'll follow this order (integrate into jdk7u/jdk7u-dev only after
> passing PIT, and into jdk7u/jdk7u shortly afterward) for the current
> integration of hs22 b02 into 7u2 b03, expected today.  PIT results are
> still pending, but all other requirements have been met.
>
> -John
John's proposal here is the more conservative one, which is entirely acceptable.
I think the only salient notable result is that people will see the 7u-dev/hotspot
updated very shortly before the 7u/hotspot repository (likely only a few hours before, if that).
So, people should be aware that this happens, and not to expect a large amount of time to review and/or
look at things in the 7u-dev/hotspot repository before those changes hit 7u/hotspot.


Lastly, John is correct in that I'm no longer at Oracle. I've moved to a company in downtown San Francisco;
however, I'm going to be a heavy user of the JDK at my new employer (who's building something that will
hammer the living crap out of the JVM), and expect to continue participating in the OpenJDK project.
Email from me will use this (my personal email) account, until it becomes
appropriate for me to use my new employer's address.

So, set your email filters appropriately. :-)

-Erik
trims at netdemons.com