Call for Discussion: New Project: Skara -- investigating source code management options for the JDK sources
neugens at redhat.com
Thu Aug 2 10:23:45 UTC 2018
Reactions ondiscuss at ojnand elsewhere range from:
* The only possible choice is github ftw!
* You can take hg, mq, and webrev.ksh out of my cold, dead hands
I think we've more civilised than that ;)
However, I'll die before you can switch to Git! Also, the slides you
posted are very interesting, I'm not very sure about the last python
stats though, I think you may find this one interesting too:
I don't know how openhub does the collection, but there seems to be a
difference between the reddit thread data and the one on openhub,
clearly there's been a spike in contributions when they did the shift
to github, there hasn't been a spike in activity though (contribution
per month), does it means more people contributing less code perhaps?
Maybe longer contribution times? That may be simple patches and fixes
or large changes that have to go through a number of iterations before
getting in. Also, how do we measure the quality of those
contributions? Also, the reddit thread has a good hint, previous
commit were done by maintainers, thus hiding the real number of
external contributors, it's very well possible that the spike we see
is just the same number of long time contributors now committing the
code directly, this may be supported by the relatively flat activity
Just material for thoughts, but I'm not sure that we want to base our
decision purely on the python experience, or maybe somebody should ask
them the real effects of the move, also considering that those stats,
if anything, can be attributed to github, not to git, so we once again
go back to square one, as much as we say that git != github the
reality is that when we think about the benefits of git we all have
the github model in mind, and so we are inevitably skewed (in one
direction or another).
On Thu, Aug 2, 2018 at 6:05 AM, joe darcy <joe.darcy at oracle.com> wrote:
> PS I presented a slide deck
> and led a discussion about Skara on the first day of the OpenJDK Committers’
> Workshop (http://openjdk.java.net/workshop). Within a few days of the
> workshop ending, I'll post a summary of the discussions to the list.
> On 7/26/2018 8:42 PM, joe darcy wrote:
>> 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
>> * 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.
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