RFC: JDK 9 Sandbox Forest Proposal

[Martijn Verburg]

+1 (from an outsider)

On Friday, 19 September 2014, Keith McGuigan <kmcguigan at twitter.com> wrote:

> 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
>
> @kamggg
>
> kmcguigan at twitter.com
>


-- 
Cheers,
Martijn