<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="">Thanks for all the replies! <div class=""><br class=""></div><div class="">From the responses it seems like there is a bit of interest in a solution in tree, but there are also plenty of people mostly happy with the current tools/workflows (arc / website upload). I think it is great that there are multiple tools/workflows and it’s great they work well for people. Personally I am quite happy with arc, which works fine for me after getting it set up. </div><div class=""><br class=""></div><div class="">However it seems like there are at least some contributors (and potential contributors) who’s workflow would slightly benefit from having something in-tree. I realise that any work on such a script might be ‘wasted’ because there are other alternatives already or if we switch to a different review tool. But I do not think that should be a blocker for adding a script like that, if there are people willing to invest the time knowing it might be wasted in the end.</div><div class=""><br class=""></div><div class="">Also adding such a script should not add any maintenance burden outside the script itself. And that should be limited to the users of the script, as long as we not endorse it too much. If it turns out there are no users or no-one interested in maintaining the script, it should be easy to remove.</div><div class=""><br class=""></div><div class="">Personally, I think the benefits would outweigh the extra work, but if the consensus is that we shouldn’t add something custom, I am happy to abandon the patch.</div><div class=""><br class=""></div><div class="">As others already mentioned, I think there’s also potential for improving our docs related to Arc. I think that’s something we should do regardless of any custom script. IMO it is an advantage to provide a choice of tools.</div><div class=""><br class=""></div><div class="">Apologies if I missed anything in my attempt of a summary!</div><div class=""><br class=""></div><div class="">Cheers,</div><div class="">Florian</div><div class=""><br class=""></div><div class=""><br class=""><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 21 Jan 2020, at 13:53, Reid Kleckner <<a href="mailto:rnk@google.com" class="">rnk@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">+1 to this. I will not deny that, for whatever reason, people don't seem to use Arcanist. Using PHP as the scripting language seems to be a major sticking point for people, since it is not typically preinstalled or required for normal LLVM development, in the way that Python is. I've done it, and it works for me.<br class=""><div class=""><br class=""></div><div class="">I think it makes more sense to try and standardize on the existing tool rather than building our own. If that means writing three docs with steps for Win, Linux, and Mac, so be it, it will cost less to maintain than something custom written against the Phab APIs.</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 20, 2020 at 10:09 PM David Tellenbach via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br class="">
<br class="">
although I think making the arcanist workflow more accessible is an excellent idea I'm not entirely sure if providing a custom script is the best solution (yet).<br class="">
<br class="">
A lower hanging fruit would be to have a good and comprehensive documentation, ideally including some example workflows, for using arcanist with LLVM. While the Phabricator documentation on arcanist is quite helpful for getting started it's not very detailed. Our own docs on the topic are basically non-existent.<br class="">
<br class="">
The downsides of providing a custom script are obvious: Someone has to write it and someone has to maintain it. Moreover I don't think that arcanist is so complicated that a custom script would be a huge improvement (you'd have to read the documentation of the new tool anyway).<br class="">
<br class="">
If a well organized documentation still doesn't resolve the problem of arcanist being too confusing (uncommon, ...) we could definitely think about providing a custom script, I just think it's not the first logical step.<br class="">
<br class="">
Thanks,<br class="">
David<br class="">
<br class="">
> On 21. Jan 2020, at 03:15, Florian Hahn via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>> wrote:<br class="">
> <br class="">
> Hi,<br class="">
> <br class="">
> One takeaway for me from the recent Phabricator vs Github PR discussions was that arc (arcanist) can be a pain to set up and may pose a hurdle for some contributors.<br class="">
> <br class="">
> I think those points could be addressed relatively easily by adding a llvm-patch script (or an even better name) that allows users to create and apply patches from <a href="http://reviews.llvm.org/" rel="noreferrer" target="_blank" class="">reviews.llvm.org</a> using Phabricators API. In my experience, the three most common uses cases are:<br class="">
> <br class="">
> 1. Create a new review from the current HEAD commit in the working directory and let me optionally add subscribers/reviewers<br class="">
> 2. Update the diff for an existing review with the current HEAD commit in the working directory<br class="">
> 3. Download the latest diff for a revision and apply it to the working directory, using the commit message from Phabricator.<br class="">
> <br class="">
> Those should be fairly easy to implement and as a proof-of-concept I went ahead and put up a patch implementing 3. from the list above: <a href="https://reviews.llvm.org/D73075" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D73075</a> .<br class="">
> <br class="">
> Please note that the script is probably a bit rough around the edges and I probably won’t have time to implement 1. and 2. in the near future on my own, but maybe someone would be interested in helping out.<br class="">
> <br class="">
> I think that could improve the experience for new contributors substantially: <br class="">
> * Create a new patch: `llvm-patch upload`<br class="">
> * Apply a patch from a review: `llvm-patch apply D12345`. <br class="">
> <br class="">
> WDYT?<br class="">
> <br class="">
> Cheers,<br class="">
> Florian<br class="">
> _______________________________________________<br class="">
> LLVM Developers mailing list<br class="">
> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
> <a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
<br class="">
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div>
</div></blockquote></div><br class=""></div></div></body></html>