hg: jdk7/hotspot/hotspot: 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM

[James Melvin]

And, yes. Following main and sub CRs should provide sufficient tracking
information for fixes that apply to both the trunk and/or branch
releases. Sub CRs typically represent forward or backward ports of the
main CR fix.

- Jim





James Melvin wrote:
>  > In this context I've recently realized that some bugs are duplicated
>  > in the bug database. Is this because the same bug appearing in both,
>  > the head trunk and a "stabilization repository", needs two different
>  > bug IDs such that it can be fixed independently in both code lines?
>  > Could this be used to identify changes in the head revision which have
>  > also been made to a stabilized version?
> 
> Our current bug tracking tool allows for 1 main bug, and possibly
> several linked bugs for other releases the fix applies. Internally, we
> refer to these as the "main CR" and it's "sub CRs". Both main CRs and
> sub CRs have unique bug ids. However, ids for sub CRs start with a
> number '2' and are inexorably linked to the main CR. So, it might appear
> to be duplicate bugs, but they are really sub CRs.
> 
> - Jim
> 
> 
> 
> Main CR ids start a 6 and sub CRs start with a 2.
> 
> 
> Volker Simonis wrote:
>> Hi James,
>>
>> thank you for the detailed description. Especially the following part
>> was quite interesting for me:
>>
>> "But it's important to note that any bugs resolved in HS14 *must* be
>> forward ported to HS15, if applicable. Also, bugfixes made to HS15,
>> which are deemed critical to HS14, will be considered for backport if
>> there is sufficient time for full testing."
>>
>> How could someone who wants to deliver a "as stable as possible"
>> release of the OpenJDK HotSpot VM take advantage of this model. Is
>> there a way to identify changes which are forwarded from the HS14
>> branch into the head trunk and the other way round, identify changes
>> in the head revision which are considered for backporting into HS14?
>> I.e. will it be possible for an external observer to build something
>> which is "close" to a Sun-released HotSpot VM from the OpenJDK
>> repository?
>>
>> In this context I've recently realized that some bugs are duplicated
>> in the bug database. Is this because the same bug appearing in both,
>> the head trunk and a "stabilization repository", needs two different
>> bug IDs such that it can be fixed independently in both code lines?
>> Could this be used to identify changes in the head revision which have
>> also been made to a stabilized version?
>>
>> Thank you and a happy new year,
>> Volker
>>
>>
>>
>> On Sat, Dec 27, 2008 at 9:21 PM, James Melvin <James.Melvin at sun.com> 
>> wrote:
>>>> ..and what does "Fork" mean in this context. For me this sounds as if
>>>> the HS14 will continue to live in its own "branch".
>>> Yes, exactly. A copy ("fork") of the current mainline repository is
>>> being made for independent stabilization and delivery. This serves 2
>>> purposes...
>>>
>>>  1) HS14 controlled stabilization and testing for production delivery
>>>  2) HS15 continues to be open for business, unabated
>>>
>>> I imagine this is a familiar development model in Software.
>>>
>>>
>>>> Will this be the "Express" VM which will be integrated into JDK 1.6
>>>> eventually?
>>> Yes. Hotspot now productizes more frequently than the JDK. The idea
>>> behind "Hotspot Express" is to make the latest stable Hotspot source
>>> available to stabilizing JDKs for testing and delivery as a matched set.
>>> Note, this does not imply mix-and-match of binaries however. Fully
>>> tested pairs only to mitigate risk.
>>>
>>>
>>>> And where will the future development (I assume its more or less bug
>>>> fixing?) of HS14 take place - will it be an open repository or a
>>>> closed one?
>>> I presume closed, subject to OpenJDK6's adoption of HS14. But it's
>>> important to note that any bugs resolved in HS14 *must* be forward
>>> ported to HS15, if applicable. Also, bugfixes made to HS15, which are
>>> deemed critical to HS14, will be considered for backport if there is
>>> sufficient time for full testing. Security bugs are treated with 
>>> priority.
>>>
>>> I'll take an action item to better document the "Hotspot Express"
>>> delivery model and make sure it's posted.
>>>
>>>
>>> Hope this helps,
>>>
>>> Jim
>>>
>>>
>>>
>>> Volker Simonis wrote:
>>>> ..and what does "Fork" mean in this context. For me this sounds as if
>>>> the HS14 will continue to live in its own "branch". Will this be the
>>>> "Express" VM which will be integrated into JDK 1.6 eventually? And
>>>> where will the future development (I assume its more or less bug
>>>> fixing?) of HS14 take place - will it be an open repository or a
>>>> closed one?
>>>>
>>>> Thanks for the clarifications,
>>>> Volker
>>>>
>>>> On Sat, Dec 27, 2008 at 11:42 AM, Christian Thalinger
>>>> <christian.thalinger at gmail.com> wrote:
>>>>> On Wed, 2008-12-24 at 03:31 +0000, erik.trimble at sun.com wrote:
>>>>>> Changeset: 3cd5c5b027b1
>>>>>> Author:    trims
>>>>>> Date:      2008-12-23 19:28 -0800
>>>>>> URL:
>>>>>> http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/3cd5c5b027b1
>>>>>>
>>>>>> 6788797: Fork HS14 to HS15 - renumber Major and build numbers of JVM
>>>>>> Summary: fork Hotspot 15 - redo verisoning numbers
>>>>>> Reviewed-by: jcoomes
>>>>>>
>>>>>> ! make/hotspot_version
>>>>> Out of curiosity, are there any milestones to bump HotSpot's major
>>>>> version?  And if yes, what milestones are these and are they listed
>>>>> somewhere?
>>>>>
>>>>> I just found these bugs:
>>>>>
>>>>> [1] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6590301
>>>>> [2] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6717462
>>>>> [3] http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6788797
>>>>>
>>>>> which contain very little information.
>>>>>
>>>>> - Christian
>>>>>
>>>>>