How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default')

[James Melvin]

Hi Volker,

The SCM for class libraries is different between JDK 6 and JDK 7...

JDK 6
   Hotspot -   Mercurial
   Libraries - Teamware

JDK7
   Hotspot -   Mercurial
   Libraries - Mercurial

So, you will not find any 'changeset' in JDK 6 for this particular
libraries enhancement.


Thanks,

Jim


Volker Simonis wrote:
> Just to name a current issue and demonstrate how compilcated it may be
> to follow the development process, lets consider Bug ID: 6622432 (RFE:
> Performance improvements to java.math.BigDecimal):
> 
> On the mailing lists, there was a Request for review:
> 
> http://www.mail-archive.com/core-libs-dev@openjdk.java.net/msg01095.html
> http://webrev.invokedynamic.info/xiaobin.lu/6622432/
> 
> But I couldn't see a changeset for the bug. So apparently it is not in
> any of the OpenJDK 7 repositories (at least I couldn't find it).
> 
> On the other hand, the Bug says "State, 8-Fix Available". Brad
> Wetmores writes in another thread on this list
> (http://www.nabble.com/forum/ViewPost.jtp?post=22140212&framed=y):
> "When the fix is put into one of the gates, the fix goes to "fix
> available" in bugtraq.  It's the gatekeepers who mark as Fix
> Delivered." So apparently, the change went into a closed "gate".
> 
> I would guess it could be the "JDK6 RE build" Mercurial repository you
> mention. Because the list of fixed bugs for JDK 6u14 b01
> (http://download.java.net/jdk6/6u14/promoted/b01/changes/JDK6u14.list.html)
> lists 6622432 as fixed. But this is in contradiction to the status of
> the bug which is  "State, 8-Fix Available".
> 
> So I assume there must be another Bug Id for the same problem, but
> neither could I find it in the bug database, nor is there a link from
> Bug 6622432 to this other bug.
> 
> If I just want to get the patch for this fix, this is quite confusing
> - at least for me...
> 
> Regards,
> Volker
> 
> On 2/20/09, James Melvin <James.Melvin at sun.com> wrote:
>> Hi Mark,
>>
>>  Actually, the Hotspot engineering work is all done in Mercurial.
>>  For the JDK6 RE build, we lazily create a disposable Teamware
>>  workspace from the Mercurial repository...
>>
>>  hotspot.gpl - Mercurial (read-write)
>>  hotspot     - Teamware  (read-only, regenerated for builds)
>>
>>  This mitigates the Mercurial <--> Teamware SCM nightmares.
>>
>>  - Jim
>>
>>
>>
>>  Mark Reinhold wrote:
>>
>>>> Date: Fri, 20 Feb 2009 18:17:27 +0000
>>>> From: Andrew John Hughes <gnu_andrew at member.fsf.org>
>>>>
>>>
>>>> 2009/2/20 james.melvin at sun.com:
>>>>
>>>>> The basic reasoning behind the HS14 fork is two-fold...
>>>>>
>>>>> ...
>>>>>
>>>> I quite agree with the reasons for the branch, that in itself is a
>>>> very sensible approach.  My issue was with why the stable branch, when
>>>> created, was not simply done publicly.  It's not like anyone can just
>>>> commit anything they want to it anyway, and a stable HotSpot is
>>>> valuable for others outside Sun.
>>>>
>>> As I understand it, the real reason the fork of HS14 wasn't done in the
>>> open is fairly prosaic: Sun's proprietary 6uX update releases are still
>>> based on TeamWare, our old internal SCM, rather than Mercurial.  When a
>>> HotSpot "Express" snapshot is taken from JDK 7 it's first converted into
>>> TeamWare, and that's where the stabilization work is done.
>>>
>>> Joe Darcy has been working with the HotSpot team to revise this practice
>>> so that such work can take place in the open.  Hopefully he'll have some
>>> news on that soon.
>>>
>>> - Mark
>>>