Proposal to revise forest graph and integration practices for JDK 9 (original) (raw)

mark.reinhold at oracle.com mark.reinhold at oracle.com
Thu Dec 5 09:39:52 PST 2013

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

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

More information about the jdk9-dev mailing list