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

[Mark Wielaard]

Hi Volker,

Thanks for the informative reply.

On Tue, 2009-02-17 at 11:50 +0100, Volker Simonis wrote:
> As far as I understand the procedure, the HS14 has been branched at
> some time in the past and is now "stabilized" in an Sun-internal
> repository in order to become the next, officially released "Express"
> VM for JDK6.

That would be good, then we are all pushing at the same code base for
stabilization. What does "Express" stand for?

> A good starting point for what you want (i.e. an open, stable HS14
> repository) would be to know the exact point at which the HS14 was
> branched for the next JDK 6 express release. I'm not sure this was
> right before the HS number was bumped to 15.

Yes, my plan was to branch at the commit just before the HS15 tag in
jdk7/jdk7/hotspot appeared. But it would be good to get confirmation
that is the right branch point.

> If it would then also be possible to track the fixes for Sun's
> "stabilization" branch, you could easily maintain an open, stabilized
> HS14 branch yourself. By the way, the bugs which are identified for
> Sun's "stabilization" branch are already visible in the bug database
> today, although they are not easy to find. The problem is, that some
> of the bugs are reported and fixed against the JDK 7 head revisions
> and only back ported to the "stabilization" branch if they are
> regarded critical.

We already backported fixes from the hotspot trees for common crashers
in important applications before the HS14 adoption, including test
cases. Which reminds me to add some of those test cases back that were
recently lost for old crasher bugs.

> Consider for example bug 6661247. It was fixed in  hs12(b02) which was
> the development code line at that time. But there's another bug ID for
> the same bug (2160622) and it states the bug was also fixed in
> hs11(b12) which was a "stabilization" branch at that time.
> Unfortunately there's no link from 6661247 to 2160622. A nicer example
> id probably 6599425. It lists all the parallel bug IDs and releases
> where the bug has been fixed ( hs12(b02), hs10(b22) (Bug ID:2158279) ,
> hs11(b12) (Bug ID:2158280) , 6-open(b11) (Bug ID:2164154)). I think
> this is exactly  the kind of information, that is required - and it
> should be browsable and searchable release-wise (i.e. by the HS
> release number).

Thanks, that is interesting. We could create a bug screen scrapper that
tries to collect all bugs that have relevant tags. But it would be
better to have a more open publicly visible way of coordinating fixes
around shared trees. I found bugs.sun.com not ideal for coordinating
bugs and patches, if only because I haven't found any way to search for
specific tags like hs14. I might be missing some advanced search page,
but it does look like you can only search for a general keyword/bug-id,
not on any specifics (except for the component and state). In general
watching the commit lists has been more productive, but often misses any
discussion about the bug being fixed.

Cheers,

Mark