Proposal to revise forest graph and integration practices for JDK 9

[mark.reinhold at oracle.com]

2013/12/2 16:37 -0800, joe.darcy at oracle.com:
> On 12/02/2013 11:50 AM, mark.reinhold at oracle.com wrote:
>> Can you say more about your discomfort?  Eliminating the master/dev
>> distinction is another good simplification, I think, and if we're
>> going to shake things up anyway then now is a good time to do it.
>> 
>> Is your concern mainly that consumers of the master forest will have
>> to change their habits, and always look for the current build tag?
>> 
>> One way to make that easier would be to define another tag, say
>> jdk9-current, that also tags the latest jdk9-bXXX changesets.
> 
> I would expect some hiccups transitioning to the new model; dev *should* 
> be stable, but a problem may be found later than desired, etc.  Having a 
> separate master forest, and the potential to make out-of-band 
> integrations to it, allows an easy remedy to such a situation by doing 
> what we do know.

We can make an out-of-band fix to a unified master/dev forest simply by
updating the jdk9-current tag:

  $ hg clone -r jdk9-current http://hg.openjdk.java.net/jdk9/jdk9/$REPO
  $ cd $REPO
  $ # ... apply fix ...
  $ hg ci -m $MESSAGE
  $ hg tag -f jdk9-current jdk9-$BUILD
  $ # ... pull and merge if needed ...
  $ hg push

The weekly integration process would work in the same way, except it
would tag every repo in the forest.

The only transition required for consumers who want the latest stable
and tested "master" code is to specify the jdk9-current tag when doing
a clone or a pull:

  $ hg tclone -r jdk9-current http://hg.openjdk.java.net/jdk9/jdk9

(This example uses John Coomes's forthcoming trees extension [1]; it
 should be simple to modify get_source.sh and common/bin/hgforest.sh
 to pull a specific tag as well.)

- Mark


[1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2013-April/000009.html