Setting up the Mercurial Repositories for Sumatra
Frost, Gary
Gary.Frost at amd.com
Wed Jan 9 18:58:26 PST 2013
John
This is good news.
Here at AMD we have built some local mercurial repositories (clones of
project Lambda for java.util.stream.* experiments, and JDK 8 for more
general lambda experiments) and have some code we have been playing with
that we would like to share.
So my guess is we should be able to make some of this code generally
available as soon as the Sumatra repositories are available.
Gary
On 1/9/13 7:51 PM, "John Rose" <john.r.rose at oracle.com> wrote:
>OK, I think we've aired out the issues enough to start building repos for
>Sumatra.
>
>Let's start with
>sumatra/{sumatra-dev/scratch,sumatra-dev/{hotspot,jdk,langtools,...}},
>snapped from jdk8/jdk8 (scratch is empty).
>
>We'll eventually enable branches in it. (This might take a little
>longer, to modify the server scripts.)
>
>The scratch repo can be used (or not) to hold patches, if necessary. It
>can also hold small standalone experiments (code trees).
>
>We can build the "stable" sumatra/sumatra repo later, when we have some
>stable stuff to put into it.
>
>‹ John
>
>On Dec 7, 2012, at 4:54 PM, John Rose wrote:
>
>> A. We need a stable prototype which can be built using standard
>>procedures.
>> B. We need a "sandbox" or "workbench" for maybe-throwaway experiments
>>in modifying the JVM and JDK (not to interfere with A).
>> C. We need a part of the "workbench" to share flat files, small proofs
>>of concept, and other ad hoc resources (not to interfere with A or B).
>> D. We do not need direct mergability into jdk8 (same as lambda repos,
>>which do not merge up directly, and does not need to pass jcheck).
>> E. The workbench version of things needs to be malleable by
>>simultaneous independent workers.
>> F. However, workbench experiments should be shareable, when the workers
>>want to collaborate.
>> G. Successful, maturing experiments should be shareable with a wider
>>audience, by moving changesets to the stable prototoype (A).
>> H. Eventually (as with Project Lambda) the prototype can be moved
>>(after further development) into the main jdk source base (JDK 9 or
>>whichever).
>> I. Unlike big projects like HotSpot, Sumatra will not grow very large,
>>and so does not need a high level of codification and formality.
>> J. We will (per OpenJDK) distinguish the roles of author, committer,
>>and reviewer.
>>
>> In concrete terms, we think this comes to something like the following
>>repositories:
>>
>> A.
>>http://hg.openjdk.java.net/sumatra/sumatra/{hotspot,jdk,langtools,...}
>>(cloned from jdk8, buildable & testable, occasionally refreshed and
>>rebased)
>>
>> B.
>>http://hg.openjdk.java.net/sumatra/sumatra-dev/{hotspot,jdk,langtools}
>>(bundle of independent branches, occasionally rebased on A)
>>
>> C. http://hg.openjdk.java.net/sumatra/sumatra-dev/scratch (initially
>>empty workbench shelf, for sharing artifacts other than JDK source
>>changes)
>>
>
More information about the sumatra-dev
mailing list