Called Off [Re: Bulk Push request for Hotspot 22 Build 01...]

[Erik Trimble]

OK,

One final note here:

We've now taken a very hard look at the differences, and discovered
we're missing at least one fix from HS21-b17 that is NOT in HS22. We do
not want to regress on fixes.

So, we're calling the whole thing off.

The Hotspot team will investigate fully the differences between HS22-b01
and HS21-b17 this coming week, and report on them later. We will also
report on the possibility of doing a merge into 7u at that time, as
fixing these differences may (or may not) result in a more merge-able
solution. This is TBD.

This means we will not make the current build of jdk7u, happening later
tonight.

I expect that HS22-b02 will be the proper candidate for inclusion in
jdk7u.

Sorry for all the noise and confusion on this.

-Erik

On Sat, 2011-08-13 at 02:15 +0200, Dalibor Topic wrote:
> Hi Erik, hi John,
> 
> Thanks for the detailed account of the issues with the merge, and
> for investigating that path. I approve the proposal to replace & document 
> and integrate without a webrev as outlined in steps 1-5 of your e-mail. 
> 
> Edvard, the Technical Lead for JDK 7 Updates has voted in preference of 
> replace & document as well here: 
> http://mail.openjdk.java.net/pipermail/jdk7u-dev/2011-August/000166.html
> so you have green light for this hopefully not too exciting bit of 
> repository brain surgery.
> 
> cheers,
> dalibor topic
> 
> On 8/13/11 1:51 AM, Erik Trimble wrote:
> > This is a request to integrate the new Hotspot 22 Build 01 codebase into
> > the JDK 7u train.
> > 
> > Unfortunately, after thorough investigation, we *cannot* do a merge of
> > the Hotspot 22 repository with the existing Hotspot 21-b17 -based
> > repository currently residing in jdk7u/jdk7u-dev/hotspot .
> > 
> > Earlier today, I had hoped to be able to this merge, which, while it
> > originally looked a bit messy, would retain all history and all tags.
> > 
> > However, we have run into serious Mercurial issues with the merge.
> > 
> > Here is the problem:
> > 
> > jdk7u/jdk7u/hotspot is based on HS21-b17.  HS22-b01 forked off HS21 at
> > b13.  Thereafter, codefixes were pushed into both repositories
> > separately, so there are different changesets with the same code changes
> > and CRs in the two repositories. In addition, HS22 has unique work
> > interspersed with the cross-ported work from HS21.  So, both repos are
> > divergent.
> > 
> > While the relaxed jcheck rules allow for duplicate CRs in 7u, the
> > Mercurial merge is much trickier than it originally looked.
> > 
> > John Coomes has done several passes at the merge, and we're having
> > extreme difficulty in getting the merged repository (that is, the result
> > of pulling HS22 into HS21-b17) to be identical (code-wise) to HS22.
> > 
> > That is, the merged results *must* result in the codebase being
> > identical to HS22, and that is not currently happening. We've tried a
> > couple of options, including telling Mercurial to use the incoming file
> > in all cases of a conflict, but we're still ending up with a diff of the
> > merge vs raw HS22 repositories showing output (i.e. differences
> > existing).
> > 
> > We can't resolve these merge problems. So, we're left with the only
> > option to wholesale replace - that is, blow away the existing
> > jdk7u/jdk7u/hotspot repository (and, all dependent repositories), and
> > copy in the HS22 repository.
> > 
> > We're going to lose a bit of history; I'm sorry, but this is
> > unavoidable. Code consistency is paramount.  As a side note, John has
> > also found a couple of changes that are in HS21-b17 that AREN'T in HS22
> > (mostly copyright, but there's at least one other outstanding fix not in
> > HS22). We will have to audit this, and add them to a future HS22 build.
> > I'm not using a merge of code that results in something which hasn't
> > been tested together.
> > 
> > On a similar note, there can be no webrev for this push. Webrev will
> > attempt to do a merge itself when computing changes, and since the merge
> > won't work correctly, the webrev output is garbage (i.e. it will produce
> > output, but incorrect output). 
> > 
> > So, no webrev, either.
> > 
> > 
> > I deeply apologize for this situation, but I see no other recourse. 
> > 
> > 
> > So, we're proposing to do this:
> > 
> > 1) delete the jdk7u/jdk7u-dev/hotspot and all dependent repositories
> > 
> > 2) copy in the hsx/hsx22/hotspot repository to all the above places;
> > said copy will happen INSIDE the Hg repositories, and is a filesystem,
> > rather than Mercurial, operation
> > 
> > 3) add to the push blacklist one changeset from the HS21-b17 build, to
> > insure that any pushes from that older repository are rejected
> > 
> > 4) publish a list of all repositories which have been affected
> > 
> > 5) along with that list, make it explicit that everyone needs to delete
> > their local copies and re-clone any affected repository 
> > 
> > 
> > 
> > 
> 
> 
> 
> -- 
> 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

-- 
Erik Trimble
Java Platform Group - Infrastructure
Mailstop:  usca22-317
Phone:  x67195
Santa Clara, CA
Timezone: US/Pacific (UTC-0800)