Call for Discussion: New Project: Skara -- investigating source code management options for the JDK sources
joe.darcy at oracle.com
Sat Jul 28 03:28:33 UTC 2018
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.
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
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.
More information about the discuss