Tagging proposal for JDK GA releases

Thu Oct 4 09:58:37 UTC 2018

Hi Goetz,

I see, so it was more by accident than on purpose it was that way before. Let's not hijack this thread with this discussion, it should be discussed as a separate suggestion. Personally I'm not in favor for adding more merge changesets but that doesn't mean I won't do it if there is a good reason for it.

Thanks,
/Jesper

> On 4 Oct 2018, at 11:44, Lindenmaier, Goetz <goetz.lindenmaier at sap.com> wrote:
> 
> Hi
> 
> I think before, when no-one committed to jdk/jdk because there were the hs/comp/gc etc
> repositories it happened by process. I.e., no changes were merged into the repo
> before the build was tagged.
> 
> I think all the jdk10 tags have the tagged change for parent.
> This is no more the case since jdk11.
> 
> Best regards,
>  Goetz.
> 
> 
>> -----Original Message-----
>> From: Jesper Wilhelmsson <jesper.wilhelmsson at oracle.com>
>> Sent: Donnerstag, 4. Oktober 2018 11:38
>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>> Cc: Hohensee, Paul <hohensee at amazon.com>; Seán Coffey
>> <sean.coffey at oracle.com>; jdk-dev <jdk-dev at openjdk.java.net>; jdk-
>> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
>> Subject: Re: Tagging proposal for JDK GA releases
>> 
>> 
>> 
>>> 4 okt. 2018 kl. 11:09 skrev Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>:
>>> 
>>> Hi Jesper,
>>> 
>>> I didn't mean that the tag is on a Merge changeset,
>>> I didn't know that rule.
>> 
>> It’s more a guideline than a rule I guess. But I’ve heard it can cause issues in
>> some cases.
>> 
>>> What I mean is, in other words than in my mail below:
>>> I would like that the parent of the tag change is the
>>> change to be tagged.
>>> I know this means that there will be a merge, but
>>> it seems worth while.
>> 
>> Has it been done this way in the past? I’ve only been tagging promoted
>> builds for a short while, I may be missing some step that was part of the
>> process before.
>> /Jesper
>> 
>>> Best regards,
>>> Goetz.
>>> 
>>>> -----Original Message-----
>>>> From: jesper.wilhelmsson at oracle.com
>> <jesper.wilhelmsson at oracle.com>
>>>> Sent: Donnerstag, 4. Oktober 2018 10:48
>>>> To: Lindenmaier, Goetz <goetz.lindenmaier at sap.com>
>>>> Cc: Hohensee, Paul <hohensee at amazon.com>; Seán Coffey
>>>> <sean.coffey at oracle.com>; jdk-dev <jdk-dev at openjdk.java.net>; jdk-
>>>> updates-dev at openjdk.java.net; jdk8u-dev at openjdk.java.net
>>>> Subject: Re: Tagging proposal for JDK GA releases
>>>> 
>>>> The proposal looks good to me.
>>>> 
>>>>> On 4 Oct 2018, at 10:19, Lindenmaier, Goetz
>> <goetz.lindenmaier at sap.com>
>>>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I also think this would make things more clear.
>>>>> 
>>>>> I want to propose another point I stumbled about lately.
>>>>> 
>>>> 
>>>> Sorry, my mistake. We are not supposed to tag merge changesets.
>>>> I have re-tagged jdk-12+14 to a non-merge change.
>>>> 
>>>> I would like to take the opportunity to highlight that the hg history would
>> be
>>>> a lot easier to work with if everyone remembers to rebase their changes
>>>> before pushing. Then we would have a lot fewer merges in there.
>>>> /Jesper
>>>> 
>>>>> You all know that if I do hg clone -r jdk-10.0.2-ga
>>>>> I get all the changes, but not the change that tags the version.
>>>>> I often check for the hash of the change tagging the release
>>>>> and clone that. Then I have a repo whose last change is the ga tag.
>>>>> 
>>>>> Unfortunately recently, the tag comes later and is not directly
>>>>> applied to the change it wants to tag, but a few changes later. E.g.,
>>>>> tag 12+14 is applied on top of "8202359: [GRAAL]
>>>> compiler/uncommontrap/TestDeoptOOM.java failed with
>>>> OutOfMemoryError"
>>>>> while it tags "Merge 8897e41b327c":
>>>>> http://hg.openjdk.java.net/jdk/jdk/graph/ef114f6afcf1
>>>>> 
>>>>> * Added tag jdk-12+14 for changeset 8897e41b327c
>>>>> |
>>>>> * 8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java
>> failed
>>>> with OutOfMemoryError
>>>>> |
>>>>> * 8211385: (zipfs) ZipDirectoryStream yields a stream of absolute paths
>>>> when directory is relative
>>>>> |
>>>>> * 8211150: G1 Full GC not purging code root memory and hence causing
>>>> memory leak
>>>>> |
>>>>> * 8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with
>>>> expected value: false
>>>>> |
>>>>> * 8211392:
>>>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java
>> times
>>>> out in JDK12 CI
>>>>> |
>>>>> * 8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF
>>>>> |
>>>>> * 8211375: Minimal VM build failures after JDK-8211251 (Default mask
>>>> register for avx512 instructions)=
>>>>> |
>>>>> * Merge  8897e41b327c  jdk-12+14
>>>>> 
>>>>> The following would be more convenient:
>>>>> 
>>>>> *Merge
>>>>> | \
>>>>> |  * Added tag jdk-12+14 for changeset 8897e41b327c
>>>>> |  |
>>>>> *  |  8202359: [GRAAL] compiler/uncommontrap/TestDeoptOOM.java
>>>> failed with OutOfMemoryError
>>>>> |  |
>>>>> *  |  8211385: (zipfs) ZipDirectoryStream yields a stream of absolute
>> paths
>>>> when directory is relative
>>>>> |  |
>>>>> *  | 8211150: G1 Full GC not purging code root memory and hence
>> causing
>>>> memory leak
>>>>> |  |
>>>>> *  |  8169718: nsk/jdb/locals/locals002: ERROR: Cannot find boolVar with
>>>> expected value: false
>>>>> |  |
>>>>> *  |  8211392:
>>>> compiler/profiling/spectrapredefineclass_classloaders/Launcher.java
>> times
>>>> out in JDK12 CI
>>>>> |  |
>>>>> *  |  8204294: [REDO] - JVMFlag::printError missing ATTRIBUTE_PRINTF
>>>>> |  |
>>>>> *  | 8211375: Minimal VM build failures after JDK-8211251 (Default mask
>>>> register for avx512 instructions)=
>>>>> | /
>>>>> * Merge  8897e41b327c  jdk-12+14
>>>>> 
>>>>> Which easily can be achieved by doing hg update -r 8897e41b327c (the
>>>> merge change)
>>>>> before doing hg tag -f.
>>>>> 
>>>>> Best regards,
>>>>> Goetz.
>>>>> 
>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: jdk-updates-dev <jdk-updates-dev-
>> bounces at openjdk.java.net>
>>>> On
>>>>>> Behalf Of Hohensee, Paul
>>>>>> Sent: Mittwoch, 3. Oktober 2018 17:25
>>>>>> To: Seán Coffey <sean.coffey at oracle.com>; jdk-dev <jdk-
>>>>>> dev at openjdk.java.net>; jdk-updates-dev at openjdk.java.net; jdk8u-
>>>>>> dev at openjdk.java.net
>>>>>> Subject: Re: Tagging proposal for JDK GA releases
>>>>>> 
>>>>>> We at Amazon would find this useful.
>>>>>> 
>>>>>> Thanks,
>>>>>> 
>>>>>> Paul
>>>>>> 
>>>>>> On 10/3/18, 7:55 AM, "jdk-updates-dev on behalf of Seán Coffey" <jdk-
>>>>>> updates-dev-bounces at openjdk.java.net on behalf of
>>>>>> sean.coffey at oracle.com> wrote:
>>>>>> 
>>>>>>  I'd like to propose an enhancement to the JDK build-tagging
>>>>>>  convention to help users more easily identify JDK GA releases
>>>>>>  via Mercurial tag names.
>>>>>> 
>>>>>>  The concept is quite simple and lets people identify snapshots
>>>>>>  of GA releases in Mercurial history without having to know the
>>>>>>  build number of the GA release.
>>>>>> 
>>>>>>  For example, to obtain JDK 10.0.2 GA sources today, one issues the
>>>>>>  `hg update -r jdk-10.0.2+13` command. With the proposed
>>>>>>  enhancement, `hg update -r jdk-10.0.2-ga` could have been used.
>>>>>>  It's proposed that the new ga tag would be in addition to the regular
>>>>>>  GA build number tag. It would be added to the relevant repository
>>>>>>  once the GA milestone has been reached.
>>>>>> 
>>>>>>  This new convention would be used for future JDK releases and is
>>>>>>  tracked via JDK-8180946[1]. If the changes are adopted, I can
>>>>>>  look at retroactively adding labels for all feature JDK GA releases
>>>>>>  since JDK 7 to the JDK feature-release main-line repository.
>>>>>> 
>>>>>>  To accommodate the new tag format, some simple jcheck edits
>>>>>>  would be required. Test checks would also be added.
>>>>>> 
>>>>>>  Comments?
>>>>>> 
>>>>>>  regards,
>>>>>>  Sean.
>>>>>> 
>>>>>>  [1] https://bugs.openjdk.java.net/browse/JDK-8180946
>>>>>> 
>>>>> 
>>> 
> 