[llvm-dev] [cfe-dev] Phabricator -> GitHub PRs?

Stella Laurenzo via llvm-dev
Wed, 16 Sep 2020 13:17:25 -0000

On Wed, Sep 16, 2020, 1:36 AM Anton Korobeynikov <anton at
korobeynikov.info>
wrote:

> Apparently reviewable.io requests full permissions to control the
> repository and its settings.
>
> We need to figure out why it needs so much...
>

Yes, and the organization request is somewhat opaque to me. As an end user,
when it prompted me for permissions to act on my behalf for another
project, the requirements were nominal/in line with what I expect from
GitHub helper tools. I can see about following up with them, I guess, for
more details.


> On Wed, Sep 16, 2020 at 9:43 AM Stella Laurenzo via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> Uh-oh: Failed to publish: GitHub error 404 on POST
>> https://api.github.com/repos/llvm/mlir-npcomp/pulls/42/reviews: Not
>> Found (The llvm organization may need to authorize Reviewable as an
>> accepted third party application.)
>>
>> Can an admin take the suggested action on the mlir-npcomp project in
the
>> LLVM org? I've followed the instructions in this help doc
>>
<https://docs.github.com/en/github/setting-up-and-managing-your-github-user-account/requesting-organization-approval-for-oauth-apps>
>> and requested that reviewables be granted access to the LLVM
organization.
>> I'm not completely aware of how this will show up on the admin
side. +LLVM
>> Administration List <llvm-admin at lists.llvm.org>
>>
>> [image: image.png]
>>
>> I'm far from an expert user of reviewable after one review, but I
found
>> it wholly superior to the built-in GitHub UI and will likely keep using
it
>> (assuming no major problems). I've got comments pending on the
above access
>> request and will check in the morning. If not resolved, I'll port
them to
>> the normal GitHub UI to unblock the review.
>>
>> On Tue, Sep 15, 2020 at 2:48 PM Stella Laurenzo <
>> stellaraccident at gmail.com> wrote:
>>
>>> I just tried it for a fairly trivial review on another project.
I'll
>>> need to do some more complex reviews with it, but my initial
impressions
>>> are quite positive. The UI is intuitive and seems "review
oriented",
>>> whereas I've always felt like GitHub's UI is very
"commit oriented" -- it
>>> feels like a review tool. I should also give it a try on mobile:
the UI
>>> presents as a long-scrolling-page form factor that feels slightly
odd on
>>> desktop, but I suspect is optimized for tablet/phone use.
>>>
>>>
>>> On Mon, Sep 14, 2020 at 12:44 PM James Y Knight via llvm-dev <
>>> llvm-dev at lists.llvm.org> wrote:
>>>
>>>> Has anyone tried out reviewable.io yet? It integrates with
GitHub pull
>>>> requests, but provides a separate UI for doing the review which
promises to
>>>> fix a lot of the issues encountered with Github's review
interface.
>>>>
>>>> Some of the things it claims to support which seem like
important
>>>> additions:
>>>> - Tracking the resolved status of each discussion point
>>>> - Rebasing a PR without losing review history.
>>>> - Optionally reviewing each commit in a branch separately, and
tracking
>>>> across rebase/force-pushes of the PR branch, via matching the
>>>> commit descriptions of the new push against the old push.
>>>>
>>>> However, I haven't tried it. It'd be great if some of
the folks using
>>>> GitHub PRs could try switching to reviewable.io, to evaluate
whether
>>>> that can more successfully replace phabricator than just GitHub
PRs by
>>>> themselves.
>>>>
>>>> On Mon, Sep 14, 2020 at 3:14 PM Nicolai Hähnle via cfe-dev <
>>>> cfe-dev at lists.llvm.org> wrote:
>>>>
>>>>> Hi Stephen,
>>>>>
>>>>> Here's a real-life example of reviews that GitHub
doesn't properly
>>>>> support to my knowledge: https://reviews.llvm.org/D83088,
look for
>>>>> "Stack" under "Revision Contents".
>>>>>
>>>>> The key here is that there's a sequence of commits
that's partially
>>>>> dependent on each other, so that reviewing each one
individually is
>>>>> suboptimal, but at the same time you really don't want
to be forced to
>>>>> review the whole thing as a unit. In fact, I've been
adding to it over
>>>>> time.
>>>>>
>>>>> If the review process of LLVM was significantly faster, the
pain of
>>>>> GitHub's inferior tooling here wouldn't be quite as
much of a problem,
>>>>> but it just isn't -- and I don't think hurrying up
the process at the
>>>>> expense of quality is quite the right answer, either.
>>>>>
>>>>> Cheers,
>>>>> Nicolai
>>>>>
>>>>> On Fri, Sep 11, 2020 at 7:39 PM Stephen Neuendorffer
>>>>> <stephen.neuendorffer at gmail.com> wrote:
>>>>> > The LLVM incubator projects have been using github PRs
for reviews
>>>>> and so far haven't really seen any significant issues.
The biggest
>>>>> confusion so far has not been with reviews but with the
difference between
>>>>> "rebase and merge" and "squash and
mere".  We have used basically 3
>>>>> different processes:
>>>>> >
>>>>> > Method 1: start a review with one commit on a new
branch (typically
>>>>> in a personal repository 'fork'). Respond to review
comments by adding
>>>>> additional commits on the same branch. Then you want to
"Squash and
>>>>> Merge".   Real life example:
https://github.com/llvm/circt/pull/62
>>>>> Note that Github keeps seems to keep a reference to commits
where a review
>>>>> occurred, but does not necessarily preserve other commits
in the chain.
>>>>> Also note that you can go back and look at either the final
disposition of
>>>>> the code on the main page, or view the diff "as
reviewed" to understand
>>>>> comments in their original context.
>>>>> >
>>>>> > Method 2: start a review as a sequence of commits.
Respond to review
>>>>> comments by updating your sequence of commits rebasing
locally and git push
>>>>> -f to update your branch with a new set of commits. The
sequence of commits
>>>>> is preserved using 'rebase and merge'.  Real life
example:
>>>>> >
>>>>> > Method 3: start a review with one commit, respond to
review comments
>>>>> with git commit --amend on the commit. git push -f to
update your branch.
>>>>> In this case, only one commit is being merged, so
'rebase and merge' and
>>>>> 'squash and merge'.  Real life example:
>>>>> https://github.com/llvm/circt/pull/63
>>>>> >
>>>>> > Some projects attempt to simplify the options and only
allow "squash
>>>>> and merge" as an option.  This eliminates Method 2,
but also prevents
>>>>> mistakes where people intend to use Method 1, but
accidently select "Rebase
>>>>> and merge".  This results in undesired commit history
littered with a bunch
>>>>> of meaningless commits like "Fix typo.",
"Address comments." etc  Method 2
>>>>> is generally harder to review and discouraged, but seems
sometimes
>>>>> necessary when you have dependent commits that are
logically separate but
>>>>> need to be reviewed together to make sense.
>>>>> >
>>>>> > There seems to be a split between those who prefer to
curate commits
>>>>> locally and present them in the PR (i.e. Method 3) as they
are to be
>>>>> committed (i.e. squash/amend/etc from my workstation and
push the result),
>>>>> and those who seem to feel that it is better to avoid
"git rebase" and "git
>>>>> commit --amend" and let github handle rewriting the
history with the commit.
>>>>> >
>>>>> > Steve
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Wed, Jan 29, 2020 at 12:56 AM Nicolai Hähnle via
llvm-dev <
>>>>> llvm-dev at lists.llvm.org> wrote:
>>>>> >>
>>>>> >> On Tue, Jan 28, 2020 at 2:23 PM Renato Golin
<rengolin at gmail.com>
>>>>> wrote:
>>>>> >> > On Tue, 28 Jan 2020 at 12:28, Nicolai Hähnle
<nhaehnle at gmail.com>
>>>>> wrote:
>>>>> >> > > I don't quite follow. Yes,
gratuitous useless changes tend to
>>>>> create
>>>>> >> > > merge and rebase problems and should
generally be avoided. Why
>>>>> does it
>>>>> >> > > make a difference whether they're in
multiple commits though?
>>>>> >> >
>>>>> >> > I think you misunderstood.
>>>>> >> >
>>>>> >> > Our policy [1] is that independent NFC fixups
on existing code
>>>>> should
>>>>> >> > be separate from new changes.
>>>>> >> >
>>>>> >> > The point here is that fixups *to the patch*
should be squashed
>>>>> into
>>>>> >> > their original commits *before* merging.
>>>>> >>
>>>>> >> Okay, this intention wasn't clear to me from
what was written. It
>>>>> >> looks like we agree, then.
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> > Once the patches are in master, and problems
have been found, then
>>>>> >> > adding a fixup to master is totally fine.
>>>>> >> >
>>>>> >> > We don't want to rewrite history on
master, that'd be a
>>>>> nightmare. If
>>>>> >> > something is botched, we revert, then
reapply.
>>>>> >> >
>>>>> >> > We also don't want to have fixups to
things that haven't landed on
>>>>> >> > master yet, so cleaning up the patches and
series before merging
>>>>> is
>>>>> >> > highly encouraged.
>>>>> >> >
>>>>> >> > But during the review, rewriting history of
the series itself
>>>>> makes it
>>>>> >> > hard for any review tool to have meaningful
representations.
>>>>> >>
>>>>> >> This isn't quite true, as others already
pointed out, and *not*
>>>>> >> rewriting history can make reviews harder as well!
In fact, I've
>>>>> *just
>>>>> >> now* had that happen to me on another GitHub
project, where this
>>>>> >> sequence of events happened:
>>>>> >>
>>>>> >> 1. PR was opened with a series of commits, one of
which (call it
>>>>> >> commit B for base) is non-trivial and under review
separately as a
>>>>> >> different PR.
>>>>> >> 2. Other reviewer makes comments, asks for some
refactoring changes.
>>>>> >> 3. Author makes those changes, adds them as a
fixup commit.
>>>>> >> 4. I can now no longer usefully review the PR,
because I only have
>>>>> two
>>>>> >> options, both of which are similarly useless:
>>>>> >> 4a. I look at all changes in the PR, in which case
I get a messy
>>>>> >> mixture of commit B (which ought to be reviewed
separately) and the
>>>>> >> rest.
>>>>> >> 4b. I look at individual commits in the PR, but
then I only see a
>>>>> >> stale version of the author's work.
>>>>> >>
>>>>> >> The fixup approach *might* work if there is only a
single reviewer,
>>>>> >> but even then I suspect things can quickly become
messy. And in any
>>>>> >> case, the default assumption in LLVM should be
that anybody can
>>>>> join a
>>>>> >> review at any time.
>>>>> >>
>>>>> >> The one tool that actually gets this right is
Gerrit, which
>>>>> >> understands commit series *and* allows you to diff
between versions
>>>>> of
>>>>> >> a commit. It's unfortunate that Gerrit is so
ugly that most people
>>>>> >> won't even look at it (and it does have other
weaknesses as well,
>>>>> >> admittedly).
>>>>> >>
>>>>> >> Cheers,
>>>>> >> Nicolai
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> > So, it's better to have separate fixups
during review, but we
>>>>> really
>>>>> >> > should squash them into their related commits
in the series before
>>>>> >> > pushing.
>>>>> >> >
>>>>> >> > --renato
>>>>> >> >
>>>>> >> > [1] http://llvm.org/docs/DeveloperPolicy.html
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Lerne, wie die Welt wirklich ist,
>>>>> >> aber vergiss niemals, wie sie sein sollte.
>>>>> >> _______________________________________________
>>>>> >> LLVM Developers mailing list
>>>>> >> llvm-dev at lists.llvm.org
>>>>> >>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lerne, wie die Welt wirklich ist,
>>>>> aber vergiss niemals, wie sie sein sollte.
>>>>> _______________________________________________
>>>>> cfe-dev mailing list
>>>>> cfe-dev at lists.llvm.org
>>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>>
>>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200916/0ca23c52/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 25040 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200916/0ca23c52/attachment.png>