<div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 12, 2019 at 7:03 PM Brian Cain <<a href="mailto:brian.cain@gmail.com">brian.cain@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto">Mehdi and team, thanks for taking the time to make process improvements like this one. I hope we are able to find compromise or alleviate concerns raised in this thread because I think it's a significant step forward to switch to PRs. I look forward to having a streamlined way to stage my patches for review and pre merge test. <div dir="auto"><br></div><div dir="auto">I'd like to request that if we end up moving to PRs that we consider a long term roadmap that allows for devs to summon pre merge test easily if not automatically. And it would be ideal if I could maximize the scope of tests (even if that means my commit would be optimistically included in a batch for in-depth tests, even if maximal testing is opt-in).</div></div></blockquote><div><br></div><div>You may be pleased to hear that this is already a work-in-progress, and it is decoupled from Phabricator vs Pull-requests: while GitHub has a lot of nice integration (and the mass effects makes it a natural fit for third-party to write integration tool as "GitHub Pull-requests"-first), Phabricator also has APIs that allow to plug pre-merge testing (it is annoying though that the little engineer resources we have to dedicate to infrastructure would be sunk into implementing things that "just works" on GitHub though).</div><div><br></div><div>Here is the public repo for the prototype: <a href="https://github.com/google/llvm-premerge-checks">https://github.com/google/llvm-premerge-checks</a> ; feel free to contact <a href="http://lists.llvm.org/pipermail/llvm-dev/2019-November/136584.html">Christian</a> if you'd like to beta-test or get more info on this! </div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><br></div><div dir="auto">Independent testing of my commit puts me at ease about submitting content upstream and I suspect I'm not alone. Reducing the likelihood of post merge buildbot fallout means I would have to babysit my commits less (when is it safe to log off and assume my commit has run the gauntlet?). Also I really hate being responsible for a regression. Seems like some bots easily catch "simple" things that are also pretty easy to forget to check.</div><div dir="auto"><br></div><div dir="auto">Anyways, thanks again to the team for the tireless effort to make progress here. It's really appreciated!</div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 6, 2019, 11:32 PM Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Hi all,<br><div><br></div><div>Now that we're on GitHub, we can discuss about pull-requests.</div><div>I'd like to propose to enable pull-request on GitHub, as a first step as an experimental channel alongside the existing methods for contributing to LLVM.</div><div>This would allow to find workflow issues and address them, and also LLVM contributors in general to start getting familiar with pull-requests without committing to switching to pull-requests immediately. The community should evaluate after a few months what would the next steps be.</div><div><br></div><div><div>GitHub pull-requests is the natural way to contribute to project hosted on GitHub: this feature is so core to GitHub that there is no option to disable it! </div><div><br></div><div>The current proposal is to allow to integrate contributions to the LLVM project directly from pull-requests. In particular the exact setup would be the following:</div><div><br></div><div> - Contributors should use their own fork and push a branch in their fork.</div><div> - Reviews can be performed on GitHub. The canonical tools are still the mailing-list and Phabricator: a reviewer can request the review to move to Phabricator.</div><div> - The only option available will be to “squash and merge”. This mode of review matches the closest our current workflow (both phabricator and mailing-list): conceptually independent contributions belongs to separate review threads, and thus separate pull-requests. </div><div>This also allow the round of reviews to not force-push the original branch and accumulate commits: this keeps the contextual history of comments and allow to visualize the incremental diff across revision of the pull-request. </div><div> - Upon “merge” of a pull-request: <b>history is linear</b> and a single commit lands in master after review is completed.</div><div><br></div><div>As an alternative staging proposal: we could enable pull-requests only for a small subset of sub-projects in LLVM (i.e. not LLVM/clang to begin with for example) in the repo. In this case, we would propose to begin with the MLIR project (as soon as it gets integrated in the monorepo). This would be a good candidate to be the guinea pig for this process since it does not yet have a wide established community of contributors, and the current contributors are <a href="https://github.com/tensorflow/mlir/pulls" rel="noreferrer" target="_blank">already exclusively using pull-requests</a>.</div></div><div><br></div><div>Here is a more complete doc on the topic: <a href="https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI" rel="noreferrer" target="_blank">https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI</a></div><div><br></div><div>Cheers,</div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" rel="noreferrer" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>
</blockquote></div></div></div>