Hotspot shell games

[Kelly O'Hair]

Sigh... our home grown bug system does have these strange shadow bugs,
but in general people are told to not refer to them directly.
So whether it's jdk5, jdk6, or jdk7 people usually use the 6NNNNNN
number, or are told to. Not that your suggestion of using the 2NNNNNN
bugs would not work.
I was kind of wishing we could just start using bugzilla numbers. :^(

---
I'm thinking about proposing a change to the jcheck rule on
a single bugid being used once in a repository.

What if we could allow an optional '-N' or '-text' after the bugid,
e.g. allow additional changesets that look like (just examples)

    6123456-1: Synopsis ...
    Summary: Additional change needed due to ...

    6123456-workaround: Synopsis ...
    Summary: Temporary workaround until more formal fix ...

    6123456-transplant: Synopsis ...
    Summary: Transplant of fix from jdk7 repository

    6123456-testcase: Synopsis ...
    Summary: Temporarily ignore testcase until bug fixed...

    6123456-phase88: Synopsis ...
    Summary: Phase 88 of doc changes for milestone 9,564 ;^)

Where the pattern would be either a 6 or 7 digit number with an
optional set of characters.
The rule then changes to that pattern (up to the ':') cannot be repeated
in any other changeset.
Transplants are then allowed, but some changes to the changeset comment
to identify them as such would be needed.

Just ideas....  All to avoid having to file extra and needless bugs.

Comments?

-kto


Volker Simonis wrote:
> Thank you for the detailed explanation. It was indeed the situation
> with the same changesets beeing applied in parallel to both
> repositories that worried me. But aren't there already different
> BugIds for the same change in the Bug database (those strange "shadow"
> bugids starting with 2***) for exactly this purpose?
> 
> Volker
> 
> On Fri, May 29, 2009 at 8:01 PM, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>>
>> Volker Simonis wrote:
>>>>  * Tag the rev in the jdk7/hotspot repo with a name jdk6-b17, the
>>>>    rev that matches what is in the hsx14 repo
>>> Is this really possible? I thought the HS which is now in 6u14 (and in
>>> HSX14) was branched from the jdk7/hotspot sometimes around hotspot
>>> build 9/10 of the jdk7/hotspot. Afterwards, the hotspot version was
>>> incremented to 15 in jdk7/hotspot while there have been about six more
>>> builds of HS 14 in the HSX14 repository. From my understanding, the
>>> change history in jdk7/hotspot and HSX14 is different after HSX has
>>> been branched off from jdk7/hotspot and I can't imagine how one can
>>> now find a changeset in jdk7/hotspot which matches the hotspot version
>>> in HSX14. After all, the whole purpose of branching HSX14 is to
>>> stabilize it while the development can proceed in jdk7/hotspot. Or am
>>> I missing something here?
>> Mercurial tags can be created after the fact. A tag is just a reference
>> or name to a changeset ID, they can also be updated or changed later.
>> They are very simple things.
>>
>> I'll ignore "HSX14", and call it "jdk6/hotspot", but if you like, you can
>> replace the names as you read this. ;^)
>>
>> If jdk6/hotspot work is done in a jdk6/hotspot repository, and new
>> changesets are
>> added or new tags created, you should be able to pull those changesets
>> into jdk7/hotspot, merge and commit them there too.
>> The end result is that all the jdk6/hotspot changesets are in jdk7/hotspot,
>> then you could 'hg clone -r jdk6-bNN' from either repository and get the
>> exact same thing.
>>
>> The trick is to create jdk6/hotspot changesets in an jdk6/hotspot repository
>> so that the graph of changesets for jdk6/hotspot are all connected together.
>> The sync to jdk7/hotspot effectively adds any jdk6/hotspot changesets and
>> merges
>> with the current jdk7/hotspot tip, creating a new jdk7/hotspot tip.
>>
>> The jdk6/hotspot repository acts as a branch, yet no hg branches are used.
>> Someone would occasionally need to make sure the jdk6/hotspot changes that
>> are not in jdk7/hotspot get pulled over (a sync).
>>
>> The tricky part is transplanting or cherry picking 1 changeset from
>> jdk7/hotspot back to jdk6/hotspot without accepting the whole graph
>> of changesets above it. Unless we relax the jcheck rules around this,
>> two changesets with the same bugid cannot exist in one repository, so
>> a new bugid is needed to do any transplants (where a new changeset is
>> created for the same patch or code change).
>>
>> -kto
>>
>>> Regards,
>>> Volker