How to host HS14 stable? (Was: RFC: Change name of default HotSpot to 'default')
James.Melvin at Sun.COM
Mon Feb 23 11:26:55 PST 2009
The SCM for class libraries is different between JDK 6 and JDK 7...
Hotspot - Mercurial
Libraries - Teamware
Hotspot - Mercurial
Libraries - Mercurial
So, you will not find any 'changeset' in JDK 6 for this particular
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:
> 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
> "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
> 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...
> 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
More information about the hotspot-dev