<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 30, 2020 at 5:28 PM Mehdi AMINI via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 30, 2020 at 1:38 PM Chris Lattner via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I want to bubble out of this discussion, because most of the conversation has been about merit of various tools, how much the cloud license costs, etc.<br>
<br>
<br>
In my opinion, none of this actually matters. There are much larger strategic questions that we should be talking about instead:<br>
<br>
1) Why is LLVM special? We are a tiny community compared to the larger GitHub community - anything that makes us “weird” (even if weird is better in some ways) increases impedance mismatch, reduces collaboration with other communities etc. Many users of LLVM are already using GitHub for code reviews and PRs etc. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
2) Why should compiler nerds :-) be working on this sort of infrastructure? We have many talented people who are capable of doing many impressive things, why spent that energy on this?<br>
<br>
3) Even if someone is willing to keep this going, what ongoing liability is this for the project as a whole? Phabricator was done for the weekend, did someone’s pager go off? What is the SLA/SLO for the new system?<br>
<br>
As I mentioned upthread, I like Phabricator and its workflow from a personal perspective, but from a project perspective, I can’t see any reason to defend bespoke infra like this.<br></blockquote><div><br></div><div>From a project point of view: the productivity of the developers on the project seems like a major reason to support this infra. </div><div>I'd rather work on writing compiler infra than dev infra, but I still spent a few hours this week-end on setting up a cloud VM to migrate our Phab to it ; because until we have a good story for Phab features we rely on today it does not seem reasonable to me to *rush* the migration to GitHub.</div><div>That said I'm interested to hear how Swift developers (or Rust, or...) are adjusting their workflow to not depend on Herald for example? What about the review dashboard that you have as a landing page on Phab (and that is customizable)? </div><div>Having an answer to all these would help planning a timely migration to GitHub PRs.</div><div><br></div><div>As of the current Phab instance: it has been running for 6 years and we did pretty well with the current setup. It does not seem like an urgent problem to address SLA/SLO just right now. We actually know why the system has some issues like this Saturday: the root partition has 10GB and the apache2 logs can get quite large (I zipped a log file on the server this weekend when folks reported trouble on Saturday, and I'm looking into more maintenance on this topic next weekend).</div></div></div></blockquote><div><br></div><div>I very much appreciate everyone who has volunteered to keep the existing tooling on a stable footing. Until we actually <i>do</i> manage to switch to something else, keeping Phabricator running is extremely important. So, thank you for taking this task on, and thanks to everyone else who has run it before!</div><div><br></div><div>That said...I do hope that having new volunteers to maintain it, for now, isn't going to stop us from working towards being able to migrate away. I believe that is the sense in which Chris's mail is intended: while Phab may soon no longer be at high risk of falling over dead from lack of attention -- which is great -- that doesn't necessarily mean we should keep using it forever.</div><div><br></div></div></div>