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

Joe Darcy joe.darcy at oracle.com
Tue Dec 3 00:37:11 PST 2013

On 12/02/2013 11:50 AM, mark.reinhold at oracle.com wrote:

2013/12/1 13:04 -0800, joe.darcy at oracle.com:

On 11/25/2013 5:40 AM, Dalibor Topic wrote:

(Conceptually, in this model a separate master forest is not strictly needed since the known-good states could be indicated using a mechanism like Hg tags. However, while adjusting to the new model and to allow for fixes directly to master in exceptional circumstances, I'm proposing a physically separate master forest be retained. The distinct URL of master will also clearly indicate known-good states of the source code.) One of the not very useful things we did for 7u was to keep a separate master forest.

Considering the real benefits of a master forest [1], and the real drawbacks when it's being used with a rapidly changing tree underneath [2], I'd suggest you drop the master forest for JDK 9. Thanks for the feedback on that point of the proposal; I'm still uncomfortable with collapsing master and dev before we put the model into practice. 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.

-Joe

More information about the jdk9-dev mailing list