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

[David Herron]

Mario,

I did not see in Joe's message a suggestion to "Move to GitHub".

I'm sure you're aware there are other possibilities for hosting Git
repositories.  Gitlab, Gitbucket, Gogs, etc

Those three all attempt a version of the GitHub experience without being
GitHub.  I personally use Gogs at home for personal projects.

What I'd be concerned about is that moving to a web-ui-for-Git doesn't add
anything unless you're also going to change processes for managing OpenJDK
contributions.  Joe's email said nothing about changing processes and
explicitly said it would not be about changing the bug tracker.

So... all that would be gained is switching from Mercurial to Git as the
repository technology and one would not be gaining any of the benefits of
the UI offered by GitHub et al.

There may be some gains in performance and the size of the repository.  Joe
says there is, and I'm sure Joe has some proof to back that up.  But ... is
the work involved to switch SCM's worth only that gain?  The project seems
to not be seeking any of the other possible gains from switching to Git.

Okay, Joes message also did not explicitly say "switch from Mercurial to
Git" ... but in the SCM landscape, aren't those the remaining two choices?
And isn't it Git that has the huge marketshare/mindshare advantage?

+ David Herron



On Fri, Jul 27, 2018 at 4:11 AM, Mario Torre <neugens at redhat.com> wrote:

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