New candidate JEP: 369: Migrate to GitHub

[Florian Weimer]

* Andrew Dinn:

> My experience of GitHub use in the Graal project suggest that this is
> not entirely the full picture. My view derived from that experience is
> that the GitHub PR is very much an inferior medium for review
> discussion. In particular, it definitely fails to be "structurally
> similar to the existing e-mail and webrev based workflows".

I'm currently evaluating Gerrit for use with glibc, so this discussion
struck a nerve with me.  I haven't used Github or Gitlab in a
significant way, though.

What surprised me about Gerrit is that it's not a clear improvement
over a mail workflow with a legacy mail client that has proper
threading.  (I assume the non-legacy clients also have ways to tag
messages for later action, but I suspect that few people use them.)
If people optimize for the threaded mail reader when they reply
(trimming irrelevant context, replying to the right message etc.), it
is surprisingly convenient for readers.  Curiously, most non-legacy
mail clients still get the threading metadata right even though they
themselves do not use it. But that's not an option if the user enters
their new comment in a box that applies to all previous comments
equally.

Given that, I wonder if the alternative should be to train more users
on those older threading email clients.

> By contrast discussions in GitHub PRs are essentially linearized (modulo
> a single level of nesting of commentary on top level comments). Worse,
> the presentation forces all commentary to be flattened into a single
> browser pane view. This linear mode of presentation results in a severe
> hindrance to separation of, and attention to, separate concerns. It also
> fails to preserve and display source relationships that clarify the
> provenance and relevance of quoted text i.e. it not only fails to record
> but actually obfuscates important context.

What happens to previous commentary when the PR is updated based on
feedback?  That's one of the things that's quite confusing in Gerrit.

If you make a change and the diff hunk to which previous comments have
been applied is gone, does that mean the comments' concerns have been
addressed?  It is impossible to know automatically.  Gerrit does not
automatically remove or close the comments, but hides them from the
default view (i.e., there is no visual cue that there are unresolved
comments on a previous version), which neatly reflects the inherent
ambiguity of the situation, but is also not very helpful.

The same problem exists with review email, of course, and I would
argue that the separate webrev (as opposed to inline patches) makes
that problem a little bit worse.  But if the new webrev link is posted
on the old thread (which is usually the case), I can view the old
thread structure and poke around if there have been any unaddressed
comments (which does not happen that often for me on OpenJDK lists,
admittedly; I'm extrapolating from libc-alpha here).

One more thing: I've been browsing the OpenJDK lists for a while,
trying to help out if a discussion touches something where I feel I
could make a useful contribution.  I used to do this for more
projects, but I couldn't quite get this working for me when those
projects switched to Github. But the custom tooling I see on skara-dev
looks actually pretty decent, although the threads there are pretty
short and perhaps not representative of some of the longer review
threads. We'll see.