Hotspot shell games

Tue Jun 2 06:00:01 PDT 2009

Your proposals look ok to me. There's only one point I would like to
add: until now, the OpenJDK repositories are quite "linear" in the
sense that we created new repositories for every bigger development
line (i.e. branch) like for example OpenJDK 6, Sun JDK updates, HSX,
...

Now, if we start to integrate all these branches back into the main
OpenJDK repository, we get a much more comlex repository with a lot of
branches there. Not sure if that's a problem, it just came to my mind.
In fact it's like if we would have no hsx/hsx14 at all but just keep a
parallel "diverged line of development" for it in the main
OpenJDK/hotspot repository (i.e. keep parallel heads there).

On 5/30/09, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> 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
> > > >
> > >
> >
>