Call for Discussion: New Project: Skara -- investigating source code management options for the JDK sources
thomas.stuefe at gmail.com
Sat Jul 28 06:31:13 UTC 2018
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.
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
Best Regards, Thomas
On Fri, Jul 27, 2018 at 5:42 AM, joe darcy <joe.darcy at oracle.com> 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.
More information about the discuss