New candidate JEP: 369: Migrate to GitHub

[Per Bothner]

On 11/13/19 10:31 AM, Andrew John Hughes wrote:
> Each developer has a fork of the actual repo as it stands now; this is
> the very nature of using a distributed version control system (DVCS).
> What differs with the pull request model is that fork is made public
> rather than patches being generated from it and posted. The advantage of
> that is that other developers can check out the published repository
> rather than attempting to recreate it by applying the patch to their own
> fork.

The straight-forward way to "check out the published repository" unfortunately
requires a lot of duplicated (wasted) bandwidth and disk space, for every time
you want to test a patch.  Probably there is tooling that can mitigate that.

A related annoyance with the pull-request model is that every contributor
needs to have public fork on GitHub, and create a fresh branch for each change.
That seems a bit of a hassle compared to older ways of working.

"The JEP proposes to support multiple workflows" - but do they all require
a contributor to explicitly create a branch in a personal fork on GitHub?
If not, how do they avoid that?

One idea: a separate repository openjdk-prs that would be a clone of and automatically
track the main openjdk.  In addition, automated tools that process a patch would create
an automatic branch with the change, and the automatically-generated pull request
uses that branch.  They branch can be automatically deleted when the PR is closed.

(Anyway - just a crazy idea.  I'm no longer an OpenJDK contributor, though who
knows what might happen in the future.)
-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/