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

[Volker Simonis]

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