RFC: JDK 9 Sandbox Forest Proposal

Keith McGuigan kmcguigan at twitter.com
Fri Sep 19 19:36:26 UTC 2014

This sounds great!  Thanks for doing this.

On Fri, Sep 19, 2014 at 1:15 PM, Mike Duigou <mike.duigou at oracle.com> wrote:

> Hello all;
> I've been instigating internal discussions with the Oracle OpenJDK
> developers about where to do OpenJDK development work for JEP-scale
> efforts. The scope, duration, and necessary collaboration of JEP-scale
> efforts makes it appropriate for collaboration to be done using an open,
> shared version control system rather than just using privately shared
> patches. As incubation development work it is not appropriate though for
> this work to be hosted in the jdk9/dev main-line repos. We need a public
> place to collaborate on issues and features before they are ready for final
> integration into the main-line JDK repos.
> It is possible for any OpenJDK developer to request a new OpenJDK project,
> but the OpenJDK project process seems entirely too heavy-weight to have
> full OpenJDK projects and/or forests for every issue, feature, exploration
> or prototype. The problem is both the creation process overhead for new
> projects as well as the various ongoing administration and maintenance
> issues attendant with ongoing projects. For larger efforts it is still
> entirely appropriate to create an OpenJDK project. An extremely rough guide
> is that if the result of an effort will be a new JDK module or API package
> then it is probably big enough to deserve a separate project. For
> everything smaller, shorter or more speculative than is appropriate for a
> project this new sandbox forest will provide a comfortable home.
> This proposal has been through a few rounds of internal review and
> refinement and I believe is nearly ready for activation. Ideally the new
> sandbox forest would be available for use in early October.
> Feedback and suggestions welcome.
> Cheers,
> Mike
> Proposal:
> - Create a new forest in the JDK 9 project for developers to use for
> experiments, new features, prototypes or any other non-trivial efforts.
> Goals:
> - Open          : Use OpenJDK public infrastructure
> - Low-friction  : Minimal start-cost and no delays
> - Collaboration : Individual efforts can self-organize and self-regulate
> - Approachable  : Community members can easily locate, review, comment and
> participate
> - Participation : Open to all JDK 9 Reviewers, Committers and Authors(*)
> - Light-weight  : Minimal required policy, simpler pre-push rules than
> main-line jdk9/dev forest
> - Visible       : Links from JEP or issue page and sharable URIs to repo,
> branches and changesets
> (*) Authors will require a Committer or Reviewer to push changesets for
> them.
> Constraints:
> - Policies are consistent with OpenJDK bylaws and JDK 9 project rule.
> - Future OpenJDK bylaws changes may make things easier but we won't block
> waiting for changes.
> - Use the JDK 9 project membership and roles.
> Specifics:
> - New "sandbox" forest in JDK 9 project is a clone/child of jdk9/dev
> forest.
> - Eligible committers are JDK 9 committers as this is a forest in the JDK
> 9 project.
> - Each repo in the forest has a branch (possibly default) that is lockstep
> updated from parent jdk9/dev repo via cron job syncing or triggered.
> - Neither jcheck nor hgupdater is enabled for this forest.
> - All development happens on branches. Committers can create whatever
> branches in this forest they wish. Branch names "JEP-XXX" and "JDK-XXXXXXX"
> are, by courtesy, reserved for use of the corresponding JBS issues. Branch
> names prefixed with an OpenJDK username and a delimiter, by courtesy, are
> reserved for use of that OpenJDK user.
> - JBS allows web links to be associated with issues. This can be used to
> identify the location of development branch for an issue.
> - Branch owners determine the pre-commit review policy (if any) for their
> branches.
> - Branch owners are responsible for reparenting/rebasing their branch to
> the provided upstream lockstep-with-dev branch however often they wish.
> - There will be no pushes or promotions from this forest to any other
> forest.
> - Integration to the main-line jdk9/dev forest repos will be via the the
> current JDK 9 changeset review and approval process.
> - Nightlies, testing, CI, etc. are the responsibility of the individual
> branch owners.
> - Since the work in this forest is unreviewed, experimental, prototype or
> exploratory there is no commitment whatsoever that anything in this forest
> eventually be part of JDK 9 or any other release.
> - The forest will be frozen at the release of JDK 9 and possibly deleted
> sometime thereafter. Feature owners would be responsible for archiving or
> migrating anything that they wish to retain. Notice and warning will be
> given on jdk9-dev mailing list to which all JDK 9 project committers are
> presumed to subscribe.
> - Changesets pushed to the sandbox forest do not count as "significant
> contributions" for the purposes of JDK 9 project role eligibility.
> Desirable Future Changes:
> - Allow changesets to be pushed to branches in the sandbox forest by users
> with Author role. This new privilege would be consistent with other Author
> privileges such as uploading to cr.openjdk.java.net, editing bug reports,
> and modifying the wiki. Allowing Authors to push changesets would require a
> modification to the OpenJDK bylaws so we cannot currently implement this
> policy.
> Contributors (in no particular order):
> Stuart Marks, Alan Bateman, Joe Darcy, Paul Sandoz, Mark Reinhold, John
> Rose, Brian Beck, Brian Goetz, Roger Riggs and Chris Hegarty all reviewed
> earlier drafts of this proposal and provided insight and encouragement.


[image: twitter-icon-large.png]

Keith McGuigan


kmcguigan at twitter.com

More information about the discuss mailing list