Getting jdk7 changes into jdk8

[John Coomes]

David Holmes (David.Holmes at oracle.com) wrote:
> John,
> 
> John Coomes said the following on 06/07/11 10:14:
> > David Holmes (David.Holmes at oracle.com) wrote:
> >> John Coomes said the following on 06/07/11 09:50:
> >>> Kelly O'Hair (kelly.ohair at oracle.com) wrote:
> >>>> Some questions have come up with regards to how the jdk7 changes will be pulled into jdk8.
> >>>>
> >>>> Please be careful here, we do NOT want new changesets created in jdk8 for the exact same change
> >>>> that was pushed into jdk7, we want the EXACT same jdk7 changeset in jdk8, not a re-creation.
> >>>> The default behavior for 'hg import' is to re-create a new changeset (unless you use --exact).
> >>>> This might sound like a silly difference, but it is actually very important.
> >>>>
> >>>> If you re-create changesets for the same CR number, your integrator will be in a world of hurt when he/she
> >>>> finds out that they cannot sync with the master jdk8 repos because of the same CR was used in 2 different
> >>>> changesets.
> >>>> The Release Engineering team will likely be doing syncs between jdk7 and jdk8 at jdk7 promotions or
> >>>> maybe nightly, so unless you are in some kind or urgent hurry, please just let RE do this jdk7->jdk8 sync.
> >>> Hotspot is already in position where we cannot merge from jdk7 ->
> >>> jdk8, because of the order in which approvals occurred.  So RE should
> >>> *not* sync hotspot from jdk7 -> jdk8.  The hotspot fixes added late to
> >>> jdk7 will propagate to jdk8 as part of the regular hotspot express
> >>> release model.
> >> Which will mean new changesets - correct?
> > 
> > Yes.
> > 
> >> That said, there are no 8 hotspot changesets yet so I don't understand 
> >> why the master hotspot repo for 7 can't be used to push all missing HS 
> >> fixes from 7 to 8 ???
> > 
> > There are jdk8 hotspot *changesets*.  Not yet bug fixes, but
> > *changesets*.  They are in the hotspot 'ongoing development' repos,
> > e.g.
> > 
> > 	http://hg.openjdk.java.net/hsx/hotspot-{group}/hotspot
> > 
> > Approved bug fixes from these repos were put into the jdk7 repos in a
> > different order, so they now have different changeset ids.
> > 
> > So hotspot has forked from jdk7 and cannot merge from jdk7 <-> jdk8.
> 
> What has been done with the hotspot repos is very confusing.

Think of the hotspot in jdk7 as "just" a fork of hotspot express.  As
an example, the prior fork of hotspot express was hs20.  Once we
forked hs20, we stopped merging fixes into it and instead created new
changesets (using the transplant extension or hg export + hg import).

The confusing thing about the old procedure was that our 'ongoing
development' repo was labeled with a specific release (jdk7), even
though the content we placed there was being delivered to multiple
releases (jdk6 and jdk7).

Now, we have new 'ongoing development' repos (hsx/hotspot-{group}/...)
that are not labeled with a specific release.  We put fixes there to
soak and get tested.  Once we're convinced they're stable and they are
approved for jdk7, we backport individual fixes to jdk7 (with hg
export + hg import, not by merging).

> ...                                                          I thought 
> the new repos were restricted to only those changsets/CRs targetted for 
> 7. ...

They are, because we do not have the testing bandwith for multiple
releases right now.

>    Are you saying they also contain stuff for 8 that is not in 7 ???

Some bug fixes have different changeset ids in the hsx/hotspot-{group}
repos vs. the jdk7/hotspot repos, because they went into the repos in
a different order.

> If not (or even if so) then lets clean the slate again and get rid of 
> the current hsx repos and re-create them with a clone of 7-b145.

Why?  How would that help you?  It'd be a big flag day.  Anyone that
has a copy would have to destroy it, after saving any work in progress
as a patch, and we have no idea who has a copy.  Also there are at
least 3 changes in the repos that are not in b145.

-John