<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jun 24, 2020 at 2:31 AM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">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 style="word-wrap:break-word;line-break:after-white-space"><br><div><br><blockquote type="cite"><div>On Jun 23, 2020, at 10:56 AM, Philip Reames via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:</div><br><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote:<br></div><blockquote type="cite" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner 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><div dir="auto">There’s also some feature regressions in GH vs Phab.</div></div><div dir="auto"><br></div><div dir="auto">You *must* initiate a review via a pull request, and pull request by definition compares your working copy against master.</div><div dir="auto"><br></div><div dir="auto">This is not very compatible with LLVMs approach to incremental development.  For example, if you ask someone to break a large patch into 5 smaller patches, with Phab this is very easy because you can upload the diff between N and N+1, then N+1 and N+2, etc.</div><div dir="auto"><br></div><div dir="auto">But with the GH workflow in order to get a review on N+4 you have to include all the changes from all the earlier revisions as well.</div><div dir="auto"><br></div><div dir="auto">The way around this is to fork and make 5 branches in your fork, then base each branch off the previous one.  But now what do you do if someone requests a change on the first one?</div><div dir="auto"><br></div><div dir="auto">Overall it’s a pretty serious limitation if you’re used to Phab, and I would evaluate very carefully if you’re thinking of going this route</div></blockquote><div><br></div><div>Are you volunteering to drive Phab maintenance and keep it up & running?</div></div></div></blockquote><p style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">This really seems like a question for the board, rather than any individual.  If you're resigning and the community values phab, having the board weigh in on cost to support the tool seems worthwhile.  I suspect that cost will be high enough that we will migrate to something free, but we should at least have an informed discussion. <span> </span><br></p><p style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">(In case it's not clear, "cost" above is specifically meant in both the financial and non-financial sense.  This might be a case where a contractor is worth considering instead of relying solely on volunteer labor.)</p></div></blockquote></div>I’m not speaking on behalf of the board, I am just sharing my personal opinion here:<div><br></div><div><br></div><div>I *really* like the Phabricator workflow in practice - I feel like it fits very nicely with the LLVM development model and aside from some super minor UI squabbles, it seems to work great in practice.  I am really thankful that Manuel and others made this happen over the years, it was a huge step up from where we were.</div><div><br></div><div>That said, I can’t see a world in which it makes sense to maintain this, particularly in the absence of a dedicated team that will do ongoing security and other maintenance.  Having such critical project infrastructure on shaky maintenance grounds is a huge liability, and we’ve had Phab go down briefly in the past.</div></div></blockquote><div><br></div><div>This can be addressed by going to a professional hosting for Phabricator though.</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 style="word-wrap:break-word;line-break:after-white-space"><div><br></div><div>Furthermore, LLVM having bespoke infra like this is a burden for new people and contributors, because they have to learn our way of doing things.  The Github workflows (particularly PRs and the review workflow) are widely adopted across a ton of projects, including those that are larger than LLVM and have a dedicated team (GitHub) that maintain and evolve them.  While using GitHub loses us the ability to have full control over the stack, we gain by focusing our limited admin cycles on other infra that is more important to us.</div><div><br></div></div></blockquote><div><br></div><div>I'm sympathetic and in general supportive of standardizing our workflows and tools on what's the most common in the industry (GitHub for example), but I'm also cautious about preserving the quality of our workflow: code-review is a key part of the development and one of the difficult things to handle in general. I consider the review to be quite a critical part and sensitive part of the development process and I would expect very strong consideration before settling for an inferior solution.</div><div><br></div><div>The past thread on Pull-request led us to discuss asking GitHub for missing features we have in Phab and ask for a roadmap on implementing them before commiting to a migration.</div><div><br></div><div>When I looked into this possibility (GitHub PR) when we merged MLIR in the monorepo: just Herald rules was already a blocker and I couldn't find a replacement readily available on GitHub. The handling of stack of revisions on GitHub was another problem mentioned.</div><div><br></div><div>Best,</div><div><br></div><div>-- </div><div>Mehdi</div></div></div>