llvm dev - Nov 2020 - Notes from GitHub Pull Requests round table

I saw some other posts on this list about notes from the round tables at
the conference. Did anyone take some for the GitHub round table?

Thanks!
--
Keith Smiley
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201116/449e0980/attachment.html>

Hi Keith,
You should be able to access the notes here:
https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing
Let me know if you run into any issues.

Thanks,
Mike

On Mon, Nov 16, 2020 at 4:45 PM Keith Smiley via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I saw some other posts on this list about notes from the round tables at
> the conference. Did anyone take some for the GitHub round table?
>
> Thanks!
> --
> Keith Smiley
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201118/2c81f114/attachment.html>

Thanks for posting these notes. I wasn't able to attend the Round Table due
to scheduling conflicts (I had just moved house that week, and the
conference was outside my usual work hours, so...). It's good that people
investigating the viability of other workflows, like using GitHub PRs, I
just want to make sure that once any investigation has been done, it isn't
presented as some sort of fait accompli, discussed and agreed upon outside
the mailing list, when there are a number of people with strong opinions
against moving from Phabricator to GitHub PRs (based on the last time this
discussion was raised on the mailing list). As the review process is pretty
fundamental to the workflow, it's important that changing it gets
widespread agreement, or there's a risk of alienating many developers.

On Wed, 18 Nov 2020 at 17:37, Mike Edwards via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Keith,
> You should be able to access the notes here:
>
https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing
> Let me know if you run into any issues.
>
> Thanks,
> Mike
>
> On Mon, Nov 16, 2020 at 4:45 PM Keith Smiley via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> I saw some other posts on this list about notes from the round tables
at
>> the conference. Did anyone take some for the GitHub round table?
>>
>> Thanks!
>> --
>> Keith Smiley
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20201119/bb983339/attachment.html>

On 18/11/2020 17:36, Mike Edwards via llvm-dev wrote:
> Hi Keith,
> You should be able to access the notes here: 
>
https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing
>
<https://docs.google.com/document/d/1flP8TqS71x4KF6h98vZV3ctXADBD39_vjrXn_BQn4hQ/edit?usp=sharing>
> Let me know if you run into any issues.
Thanks.  There's one issue that isn't directly relevant to PRs, but is 
likely to become more visible if we go to a PR workflow:

LLVM takes quite a long time to run the tests and there's usually one 
commit in between running the test suite on a patch and pushing it to 
master.  If the result then causes test failures, you won't find out 
until some time later.  This means I'm generally only willing to hit the 
merge button near to the start of the day, when I'm likely to be around 
and paying attention when the failure notices come in, which increases 
the likelihood that there will be an intermediate patch that causes 
problems.

With a PR-based workflow, it becomes fairly easy to set up a system to 
manage a queue of patches to be merged, triggered by either a comment 
from a member of the project or a label (e.g. ready-to-merge) being 
added to the PR.  The CI infrastructure then rebases the PR on the PR 
that's ahead of it in the queue (master if it's the front of the queue),
kicks off the build, and fast-forwards master when it succeeds.  Head is 
always in a state where the build bots are happy and if an intermediate 
change causes problems then that's reflected in the PR that would see 
the failure, nowhere else.  Subsequent PRs in the queue can rebased on 
the last passing version and the merge process can continue without a 
human needing to notice the buildbot failures and revert anything.

David