Proposal to revise forest graph and integration practices for JDK 9

[Joe Darcy]

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