Call for Discussion: New Project: Skara -- investigating source code management options for the JDK sources

Martijn Verburg martijnverburg at gmail.com
Fri Jul 27 10:50:15 UTC 2018


Hi Mario,

AdoptOpenJDK is not intended to be a place for source code development of
OpenJDK, so we deliberately don't accept patches there with the exception
of one patch to support a particularly esoteric platform which OpenJDK did
not want to support (completely understandable).  We want all source code
development to happen at OpenJDK.

We've had a fair number of requests to allow patches because using
Git/GitHub has less friction for those folks (in particular new developers
to OpenJDK). More importantly they would like to see their patches go
through our build and test pipeline before submitting to OpenJDK (upstream).

We've still go some work to go on the build farm (e.g. adding flexibility
to build and test the various branches for amber and panama etc) before
we'd discuss / consider doing this, but all of Infrastructure as Code that
we have could be utilised to do so (and my understanding is that a few
vendors are trying just that).

--

As a side note SCM workflow hubs BitBucket and GitHub have powerful hooks
where you could also list and/or block a Pull Request / Issue on patches,
for example:

* Have you discussed this change on X mailing list?
* Have you signed your CLA?
* Have you written / extended a jtreg test for this?

They also has the built in mechanisms to support reviewers and a patch
lifecycle (authored, builds OK on all platforms, passes test pipeline,
ready for review, reviewed etc).

I fairly regularly see exchanges on the mailing list where folks are asking
for a reviewer to review a patch, get sent to a different mailing list(s),
find out post commit that their patch breaks something like the Zero
compiler etc, etc. I think there's an awful lot that a shared SCM workflow
hub / CI pipeline can do for OpenJDK developers in terms of managing their
patch lifecycle, freeing them up to work on the more important stuff.

Cheers,
Martijn


On Fri, 27 Jul 2018 at 10:27, Mario Torre <neugens at redhat.com> wrote:

> Hi Martijn,
>
> How many contributions from developers in those git mirrors came into
> OpenJDK (or even, how many contributions happened on those mirrors
> outside of OpenJDK development?).
>
> I think the point about performance is sound [1], but I would be very
> careful to introduce a new SCM, lots of developers are used with
> mercurial now, and even if git is probably just a small learning step
> away, I would argue that this is unnecessary to the people who are
> already contributing.
>
> What are the actual benefit for this change? I mean, yes, the list of
> evaluation criteria, but in practice, why do we need to change?
>
> I don't think the remote possibility of attracting a few more people
> is an answer, the current work flow is simple enough, while the
> biggest barrier is the process, not the SCM. I doubt we want to change
> the process (and I'm not advocating this either!), so the benefit to
> go git (unless you mean we're exploring svn or cvs!!) seems limited
> compared to the overhead.
>
> I may be just too old school, but I think we should be investing the
> energies somewhere else.
>
> Cheers,
> Mario
>
> [1] It really is terrible now with a single repo, but is it a problem
> of mercurial really? Git also carries all the history in the clone,
> did somebody do some testing on this, and I mean, on the same servers
> and network?
>
>
> On Fri, Jul 27, 2018 at 10:31 AM, Martijn Verburg
> <martijnverburg at gmail.com> wrote:
> > Hi Joe,
> >
> > The Adoption group has been having a lot of ‘fun’ with importing hg into
> > git (one of the options that you’ll likely explore) for our git mirrors.
> >
> > We’ve got a bunch of war stories and most importantly working scripts
> that
> > capture history and tags and all that good stuff.  They’re Apache 2
> > licensed at the moment but I’m sure the authors (all being Adoption
> > members) will be happy to re license or dual license.
> >
> > Other useful knowledge we can share is around how we manage repos,
> > projects, issues, work in progress and code reviews at the Adopt build
> > farm. We’ve learned some valuable lessons of what works and what doesn’t
> at
> > a reasonable scale of number of contributors around a git based workflow.
> >
> > Assuming this project kicks off We’re all very happy to help out!
> >
> > Cheers,
> > Martijn
> >
> > On Fri, 27 Jul 2018 at 05:13, joe darcy <joe.darcy at oracle.com> wrote:
> >
> >> Hello,
> >>
> >> The source code management (SCM) system of a software project is a
> >> fundamental piece of its infrastructure and workflows. Starting in
> >> February 2008, the source code of different JDK releases and supporting
> >> projects has been hosted in Mercurial repositories under
> >> http://hg.openjdk.java.net/. Code reviews of JDK changes are typically
> >> conducted as discussions in mailing lists over small patches sent to one
> >> or more lists or over webrevs hosted on cr.openjdk.java.net. Since
> 2008,
> >> many open source projects have successfully adopted more efficient SCM
> >> and review tooling, in some cases provided by third parties.
> >>
> >> In order to help OpenJDK contributors be more productive, both seasoned
> >> committers and relative newcomers, the Skara project proposes to
> >> investigate alternative SCM and code review options for the JDK source
> >> code, including options based upon Git rather than Mercurial, and
> >> including options hosted by third parties.
> >>
> >> The Skara project intends to build prototypes of hosting the JDK 12
> >> sources under different providers.
> >>
> >> The evaluation criteria to consider include but are not limited to:
> >>
> >>      * Performance: time for clone operations from master repos, time of
> >> local operations, etc.
> >>
> >>      * Space efficiency
> >>
> >>      * Usability in different geographies
> >>
> >>      * Support for common development environments such as Linux, Mac,
> >> and Windows
> >>
> >>      * Able to easily host the entire history of the JDK and the
> >> projected growth of its history over the next decade
> >>
> >>      * Support for general JDK code review practices
> >>
> >>      * Programmatic APIs to enable process assistance and automation of
> >> review and processes
> >>
> >> If one or more prototypes indicate a different SCM arrangement offers
> >> substantial improvements over the current situation, the Skara project
> >> will shepherd a JEP to change the SCM for the JDK.
> >>
> >> I propose to lead the project with the initial reviewers including but
> >> not limited to Tim Bell (tbell), Erik Duveblad (ehelin), Erik Joelsson
> >> (erikj), Tiep Vo (tiep), Tony Squier (squierts), and Robin Westberg
> >> (rwestberg).
> >>
> >> We suggest the build group sponsor this work.
> >>
> >> Changing the bug tracking system is out of scope for this project and is
> >> *not* under consideration.
> >>
> >> Comments?
> >>
> >> Cheers,
> >>
> >> -Joe
> >>
> >> --
> > Cheers, Martijn (Sent from Gmail Mobile)
>
>
>
> --
> Mario Torre
> Associate Manager, Software Engineering
> Red Hat GmbH <https://www.redhat.com>
> 9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898
>


More information about the discuss mailing list