RFC: JDK 9 Sandbox Forest Proposal

Mon Sep 22 22:18:40 UTC 2014

On Sep 21 2014, at 00:30 , Ben Evans <benjamin.john.evans at gmail.com> wrote:

> Would this be a good place for betterrev to baseline against?
> 
It depends. I suspect that betterrev might need the ability to generate reviews against either the jdk9/dev mainline or a single branch of this sandbox. In the later mode it would be collapsing the entire branch from where it diverges from the mainline to a single changeset suitable to integration back to jdk9/dev. Both functions would be very useful!

> & +1 from someone else who doesn't get a vote
> 
Still appreciated. :-)

Mike

> On 20 Sep 2014 19:16, "Martijn Verburg" <martijnverburg at gmail.com> wrote:
> +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