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

[Mario Torre]

On Fri, Jul 27, 2018 at 12:50 PM, Martijn Verburg
<martijnverburg at gmail.com> 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).

Right, but that is not solved if we move to GitHub, because the
process of OpenJDK isn't compatible to this process, and that has
nothing to do with Git vs Mercurial I think, GitHub is just another
place to host the code, the OpenJDK process would the same, so the
only difference would be using GitHub for patch review rather than
webrev, but if any, I would find that more dispersive for the
reviewer, this is likely due to my own experience with GitHub, where I
found the need to have eyes open everywhere to review code, I don't
think it's made for such large projects as OpenJDK (and the Linux
Kernel people seem to agree on this).

> 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.

But is that really necessary?

Also, I think the GitHub process moves the burden to the reviewers,
instead of making life easier for them, and we lack this resource more
than anything. If there were a massive return in patches from the
community that would be interesting to explore, but I don't see this
level of involvement from outside. Instead, I fear it would make life
harder for people who already contribute.

After all, it's not that hard to become a committer really, and the
barrier being the same with or without GitHub, I can't understand
what's difficult about webrev that GitHub would solve without
introducing unneccessary overhead. We've been there before, when we
discussed helping people compile OpenJDK, my objection was that if
someone isn't able to invoke make I'm not sure I want his patch in ;)

Same argument here, if somebody claims that he can't contribute
because it's too hard to run "webrev" then perhaps I don't miss that
contribution.

All that, of course, assuming we're not touching the process. If we
talk about the process that's a different story, and again, the
benefit of GitHub is really on its process work flow (if you happen to
like it, which I don't), but this is not compatible with our current
one. Git vs Mercurial as SCM... well I don't see that big of a case
here either but well...

In any case, if we want to change, I think the *existing* community of
OpenJDK should be allowed to properly vote on this.

Cheers,
Mario

-- 
Mario Torre
Associate Manager, Software Engineering
Red Hat GmbH <https://www.redhat.com>
9704 A60C B4BE A8B8 0F30  9205 5D7E 4952 3F65 7898