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

[joe darcy]

Hello,

On 7/27/2018 3:50 AM, Martijn Verburg wrote:
> 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
>

One of my professors was fond of saying "The essence of civilization is 
being about to benefit from someone else's experience without having to 
relive it." In that sense, I think we should also strive to have any SCM 
transition for the JDK to be a civilized one.

For example, the Python community migrated from Mercurial to Git on Github:

     PEP 512 -- Migrating from hg.python.org to GitHub
     https://www.python.org/dev/peps/pep-0512/

They put in place automation for contributor agreement checking, etc. I 
understand the Graal project on Github has OCA checking as well.

I think a change like an SCM transition is an opportunity to reassess 
existing processes and consider better aligning them with the preferred 
workflow of the new tool set. For example, a git migration for the JDK 
could involve adjustments to things like syntax of the commit messages 
and I would expect use of bots working with a hosting provider to 
automate other checking of various kinds too. For example, besides a 
contributor agreement bot it would be possible to have a jcheck bot 
validate a pull request. A CI bot could also notice a pull request, run 
tests on behalf of the author, and report back a comment summarizing the 
resulting build and test status.

Cheers,

-Joe