<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="">Huge +1 from my side.<div class=""><br class=""></div><div class=""><div class="">There are couple of small patches I want to submit, but the fact that I need to deal with phabricator just stops me from doing this.</div><div class=""><br class=""></div><div class="">Looking at the other comments against this step I'm wondering if the goal of the project is to keep existing (dozens?) contributors happy, or to embrace more (hundreds?) people to join the project?</div><div class=""><br class=""></div><div class="">=====</div><div class=""><br class=""></div><div class="">I'd love to leave some comments on other comments as I've been using Github for OSS/Commercial development for many years now and I find it to be one of the best things that can happen to an open source project.</div><div class=""><br class=""></div><div class="">> "Github UI is ugly/slaggish/bad"</div><div class=""><br class=""></div><div class="">that's obviously subjective, and I can only say the same about phabricator.</div><div class=""><br class=""></div><div class="">> Geopolitics/laws/whatnot</div><div class=""><br class=""></div><div class="">this is orthogonal to the subject, right?</div><div class=""><br class=""></div><div class="">> There is no way to see previous version of the patch.</div>> I don't think there is any way to disable force-push for PR's.<br class="">> While this is only 'slightly' limiting for the reviewer,<br class="">> this can be more limiting for the author - how do i go back<br class="">> to previous revision? I can't, i need to maintain a copy<br class="">> of every branch i pushed manually.<div class=""><br class=""></div><div class="">Seeing previous version is only possible if the author uses different commits, but is it not possible to enforce it.</div><div class="">Force pushes can only be disabled per repo, so if we allow to submit PRs without forks, then it is possible to solve this issue as well.</div><div class=""><br class=""></div><div class="">> Impossible to chain reviews - a PR diff can only be made<br class="">> on top of git master branch.</div><div class=""><br class=""></div><div class="">This is also true only for forked repositories.</div><div class="">Though, imo, chained PRs (feature branch based development) contradicts to the trunk-based approach LLVM project is using.</div><div class="">Correct me if I'm wrong.</div><div class=""><br class=""></div><div class="">> Just recently I submitted a very tiny PR for PcapPlusPlus on GitHub</div>> which involved:<br class="">> 1). Forking the repository<br class="">> 2). Cloning the fork<br class="">> 3). Applying the patch<br class="">> 4). Pushing it and creating a PR.<br class="">> 5). Deleting the fork (Since I didn't want it cluttering up my account<br class="">> and I'm not a regular contributor to PcapPlusPlus).</div><div class=""><br class=""></div><div class="">2) and 3) are not necessary since the repo can have multiple remotes.</div><div class="">For some very simple cases one doesn't even need to leave github UI: it is possible to send patches right from the website.</div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 7. Nov 2019, at 06:32, 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 class=""><br class=""></div><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" target="_blank" class="">https://docs.google.com/document/d/1DSHQrfydSjoqU9zEnj3rIcds6YN59Jxc37MdiggOyaI</a></div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">-- </div><div class="">Mehdi</div><div class=""><br class=""></div></div></div></div></div></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>