Proposal to revise forest graph and integration practices for JDK 9

[mark.reinhold at oracle.com]

2013/11/24 1:41 -0800, joe.darcy at oracle.com:
> On 11/23/2013 2:08 PM, Omair Majid wrote:
>> Would forests for specific projects (as an example, lets say jigsaw)
>> also follow this pattern of pulling from and merging to dev ?
> 
> I would expect Jigsaw to follow a model more like Project Lambda: the 
> project-specific forest lives on its own for an extended period of time 
> (months or longer) and syncs in changes from the corresponding JDK dev 
> (or master). When the project has sufficiently matured, there is large 
> sync from the project to dev. From that point forward, there is 
> diminished activity in the project forest as activity related to the 
> project shifts to happening directly in dev.

Yes, this is how we plan to manage Jigsaw-related changes.

>> ...
>> 
>> With the benefit of hindsight, I wonder why it wasn't this way to start
>> with :)
> 
> The integration structures described earlier have been in place since at 
> least JDK 5, circa 2003 - 2004. (We've actually used distributed version 
> control for the JDK since that time too; although it was the Sun 
> teamware product rather than Hg.)

TeamWare was used for the JDK code base from nearly the very beginning.
Here's the log entry for the first delta of java/lang/Object.java:

  D 1.1   94/08/12 18:08:06 csw   1 0     00099/00000/00000
  date and time created 94/08/12 18:08:06 by csw

If you never used TeamWare, understand that while it was a distributed
version-control system it was also deeply flawed in that it tracked
changes on a per-file basis rather than across an entire repository.
It was possible, but extremely clumsy, to do something like tag the
current state of an entire repo, so we'd instead use whole repos to
capture such information.  That's one reason why we've historically
had more repos than you might expect.

Another relevant factor was TeamWare's dependence on NFS to transfer
files, which made pulls and pushes extraordinarily expensive and hence
motivated a very conservative approach to managing the flow of changes.

>                                   Historically, I believe there were 
> concerns about being able to do proper testing for cross-component 
> fixes, but I think solving that challenge would be an improvement over 
> the current state of affairs.

Heartily agreed.

- Mark