<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Nov 6, 2019, at 9:32 PM, Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class="">Hi all,<br class=""><div class=""><br class=""></div><div class="">Now that we're on GitHub, we can discuss about pull-requests.</div><div class="">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 class="">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 class=""><br class=""></div><div class=""><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""> - Contributors should use their own fork and push a branch in their fork.</div><div class=""> - 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 class=""> - 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 class="">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 class=""> - Upon “merge” of a pull-request: <b class="">history is linear</b> and a single commit lands in master after review is completed.</div></div></div></div></div></div></div></div></blockquote><div><br class=""></div><div>This sounds great, and +1 for ’squash and merge’ as the only option.</div><div><br class=""></div><div>I’m a huge fan of incremental public development, and would prefer not to have people incentivized to do “lots of incremental changes in their local fork, then merge the huge thing” while claiming to abide by the idea of incremental development. Such an approach doesn’t get the CI or review benefits, and eliminating this from the workflow seems like a very clean solution. To be clear, I have no problem with people doing whatever local development policies they prefer, I just think they should be squashed out as an implementation detail when the aggregate patch gets merged.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><div class="">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" target="_blank" class="">already exclusively using pull-requests</a>.</div></div><div class=""><br class=""></div><div class="">Here is a more complete doc on the topic: <a href="https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI" class="">https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI</a></div></div></div></div></div></div></div></blockquote><br class=""></div><div>Overall this plan sounds good to me. Please keep the “how to contribute” doc and the project description (which currently says 'Note: the repository does not accept github pull requests at this moment.’) up to date as processes evolve! :-)</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>