New candidate JEP: 369: Migrate to GitHub
per at bothner.com
Thu Nov 14 21:04:11 UTC 2019
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
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 at bothner.com http://per.bothner.com/
More information about the discuss