[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jdk7u-dev
Subject:    Process proposal for Updating JDK 7u with Hotspot Express...
From:       dalibor.topic () oracle ! com (Dalibor Topic)
Date:       2011-08-24 18:19:54
Message-ID: 4E5540CA.9030609 () oracle ! com
[Download RAW message or body]

Thanks, Erik & thanks, John. 

I'd like to leave this thread open for a couple more days, until next 
Wednesday, to see if there is going to be any further feedback, in 
particular now that the first merge following this process has landed in 
the forest, and then turn this proposal with its amendments into a hotspot 
bulk integration process documented on this project's web site. 

cheers,
dalibor topic

On 8/23/11 8:07 PM, Erik Trimble wrote:
> 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
> 
> 



-- 
Oracle <http://www.oracle.com>
Dalibor Topic | Java F/OSS Ambassador
Phone: +494023646738 <tel:+494023646738> | Mobile: +491772664192 <tel:+491772664192>
Oracle Java Platform Group

ORACLE Deutschland B.V. & Co. KG | Nagelsweg 55 | 20097 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 M?nchen
Registergericht: Amtsgericht M?nchen, HRA 95603

Komplement?rin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Gesch?ftsf?hrer: J?rgen Kunz, Marcel van de Molen, Alexander van der Ven

Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing \
practices and products that help protect the environment


[prev in list] [next in list] [prev in thread] [next in thread]