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

[Dalibor Topic]

Thanks, Erik.

Just to clarify - the approval was for this attempt, and is now no 
longer valid, since the push has been called off. 

The next HS22 bulk merge attempt will have to go through the the same
approval procedure as this one again, of course.

cheers,
dalibor topic

On 8/13/11 2:27 AM, Erik Trimble wrote:
> 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
> 



-- 
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