Community Input on Hotspot 22 integration into 7u

[Edvard Wendelin]

Hi,

In this case I'd vote for replace + good documentation of which repos 
you need to re-clone.

Cheers,
Edvard

On 08/11/2011 04:50 AM, Erik Trimble wrote:
> Please see my related post on the process around integrating Hotspot
> Express versions into JDK 7u.
>
>
> This email is specifically about a technical question around the
> integration of Hotspot 22 b01 into the 7u series.
>
> The current situation is this:
>
> The contents of http://hg.openjdk.java.net/jdk7u/jdk7u/hotspot (and
> jdk7u-dev/hotspot ) are derived from the JDK 7 FCS Hotspot, which is
> Hotspot 21 Build 17.
>
> Hotspot 22 is a fork from Hotspot 21 build 13, as HS21 was being
> stabilized for the JDK 7 release, and additional work needed a new place
> to reside.
>
> Thus, the current contents of jdk7u/hotspot are not an ancestor (in Hg
> terms) of the HS22 repository
> (http://hg.openjdk.java.net/hsx/hsx22/hotspot ).  In particular, there
> are a multitude of instances where the same CR is fixed in both HS22 and
> HS21 in a different changeset.
>
> While the jcheck restriction on duplicate CRs has been relaxed for the
> 7u repositories (i.e. jcheck will complain, but will allow one to push a
> changeset that has an already-existing CR in the summary), there is a
> technical issue here.
>
> We have two options:
>
> A) We can delete the existing copy of jdk7u/jdk7u/hotspot  (and all
> derived repositories, e.g. jdk7u/jdk7u-dev/hotspot ), and simply copy
> the new Hotspot 22 repository files into those places. This is done
> INSIDE the Hg servers, as a filesystem-level delete and copy.
>
> B) We can do a merge of the HS22 repo into the existing HS21 repo. From
> a technical standpoint, I've been informed that it's about a 4 on a
> 10-scale of difficulty to do.
>
>
> Here's the tradeoffs:
>
> Option A will require everyone to re-clone any repository they have made
> from any repo derived from jdk7u/jdk7u/hotspot. Obviously, we (Oracle)
> would have to publish a complete list of all repositories which were so
> affected.  Option B would be simply business-as-usual.
>
> Option B would result in a repository with several dozen changesets
> which have both the same bugID (CR), AND which also perform the exact
> same code change. This can make code review a bit dicey, and results in
> a much "messier" history than Option A.
>
> Option B retains all the JDK 7 FCS-related tags (e.g. hs21-b1[4-7] and
> jdk7-b14[4-7]), while Option A does not have them (it stops at
> hs21-b13/jdk7-b143).
>
> The Option A replacement would be a one-time occurrence - no future
> update to the 7u/hotspot repo would ever have to undergo this
> replacement again (as all such future updates would be a direct
> descendant of the existing HS22 repo). The Option B merge would of
> course also be a one-time thing, though the "messy" history would remain
> forever.
>
> Both A and B require about the same level of work on our (Oracle's) end.
> B is slightly more risky than A, due to the added burden of making sure
> the merge is correct.
>
>
>
> Given that it is very, very early in the development process for 7u
> (we're on what, about build 02?), I would vote for cleanliness over some
> minor temporary inconvenience in re-cloning. Thus, personally, I would
> prefer Option A, avoiding the messy merge history, and forcing everyone
> to re-clone.
>
> But, this being a community, and I not being Dictator-for-Life, I put it
> to everyone here:
>
> A, or B?  Replace or Merge?
>
>
> I'd like to do this HS22 integration right after the resolution to my
> "Process proposal for Updating JDK 7u with Hotspot Express..." proposal.
> Thus, please have your votes (and, of course, comments/questions) in by
> no later than 12pm (noon), on Friday, 12 August.
>
> Thanks, everyone!
>
>
>