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

[David Holmes]

On 28/07/2018 4:31 PM, Thomas Stüfe wrote:
> Hallo,
> 
> If this is just a move from mercural to git with all else staying the
> same, I am indifferent. I like mercurial but git is pretty similar.
> Moving to git may make life easier for all those people who manage
> downstream repos in git. Git may also (need to check that) run faster
> under Windows Cygwin, which would be a nice bonus.
> 
> However, I am apprehensive about a move away from the current review
> process (mailing lists). The proposal mentioned "different providers"
> which I assume would mean GitHub?
> 
> For me, the review discussions on the mailing lists - with all their
> combined knowledge, wisdom and civility - are a huge wealth in itself.
> Close in value, to me, to the source code itself. I am afraid that
> moving to a different review platform would endanger all that.

+1 on that. With a simple email-based review process (plus webrevs 
hosted on cr.o.j.n) I can easily scan dozens of incoming changes to see 
if they may be something I need to dive more deeply into. That is all 
lost if reviews happens inside some other system - even if a 
notification email is generated when such reviews are initiated.

Changes to the review processes/tools should be kept a separate as 
possible from the selection of an underlying SCM.

Cheers,
David

> The fact that past discussions are preserved and searchable for all
> eternity is extremely valuable. Old school mailing lists can be
> archived by anyone, by definition, the content is democratically
> shared by all subscribers. If we move to e.g. GitHub, who owns that
> content? How easy would it be to archive discussions from github?
> 
> Then, I can read review old school mails with whatever reader I
> please. With the review process closed up in a providers website, I am
> effectively forced to that one review interface he offers.
> 
> That interface may also change the way reviews are done. Currently,
> review mails are often long, involved, carefully worded, with lots of
> condensed knowledge. Which is good. A new interface may negatively
> effect the quality of the review answers. I found discussions on
> Github never quite up to par with what I know from our mailing lists,
> but I could be biased. Slack or IRC is even worse.
> 
> This may just me being old school. But for me, this is a bit like
> electronic voting machines: sometimes old school techniques still have
> their place.
> 
> Best Regards, Thomas
> 
> 
> 
> 
> On Fri, Jul 27, 2018 at 5:42 AM, 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
>>