<div dir="auto">FWIW I'm with Mehdi here. </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Feb 29, 2020, 8:07 PM Mehdi AMINI 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Feb 25, 2020 at 4:19 AM Christian Kühnel via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">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 dir="ltr">Hi Louis,<div><br></div><div>I think this is a good idea. We should start with some local experiments where people are willing to try it and figure out how well that works and what does not. Why not allow this for "not significant" changes? They are merged without review today, so we could do them with reviews (and automated tests) via pull requests instead.</div></div></blockquote><div><br></div><div>I still feel this is only a recipe for confusion if "some" pull-requests are accepted on Github but not all. So -1 from me on this.</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 dir="ltr"><div><br></div><div>@Mehdi<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">- it does not favor to build common tooling: the recent work on enabling pre-submit CI tests on Phabricator is valuable and I'm looking forward to get this extended. But splitting the various ways of contributing to the repo just means more infrastructure to build to sustain this kind of efforts. (the infrastructure is easier built on <span>GitHub</span> by the way, but that is an argument in favor of migrating from Phab to GH for the full-project).<br></blockquote><div><br></div><div>Oh I'm happy to add Github support as soon as someone switches on PRs. This is soooooo much easier to set up and maintain than the Phabricator integration. And we already have builds for the release branch (<a href="https://buildkite.com/llvm-project/llvm-release-builds" target="_blank" rel="noreferrer">https://buildkite.com/llvm-project/llvm-release-builds</a>) anyway. So we could easily scale that up. And we can only get pre-merge testing on Phabricator to a certain point, as it's not triggering builds for ~50% of the code reviews.</div><div><br></div><div>@Chris Lattner<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">Although I am one of the (many) people who would love to see us move from Phabricator to <span>GitHub</span> <span>PRs</span>, I think it is super important that we do the transition all at once to keep the LLVM community together. I’m already concerned about the fragmentation the discourse server is causing, e.g. MLIR not using a -dev list. I’d rather the community processes stay consistent.<br></blockquote><div><br></div><div>Please allow me to disagree there. IMHO we're way too large and diverse of a project to do binary, overnight transitions.</div></div></blockquote><div><br></div><div>You seem to be arguing the "how to transition" while there is no agreement on a transition happening in the first place.</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 dir="ltr"><div> We're also too large to follow a one-size-fits-all approach. If we agree,</div></div></blockquote><div><br></div><div>I don't: we went with a monorepo because we believed that the one-size-fits-all would be more beneficial than splitting, both in terms of infrastructure, but also in terms of the practices of the community, etc.</div><div><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 dir="ltr"><div> Github PRs are the right glow, why take this step-by-step. We should have something like a list of important and supported use cases/interactions for the infrastructure. Then we could start working on them one-by-one and figure out if/how they could be implemented on Github and how we could do a smooth transition between these.</div><div><br></div><div>If Herald rules are important: Find a way to implement something similar for Github. Maybe there is even a market for such a tool.</div><div>If transparency is the problem: Find a way to mirror PRs into Phabricator, so people can at least see them there. </div><div>We're not restricted to community contributions there. We can also pay someone to build the things we need.</div></div></blockquote><div><br></div><div>One aspect here though is that we can pay someone to build the things we need in Phabricator, we can't change GitHub though.</div><div>It was mentioned in the past that we should engage with GitHub and see if they would add the feature we're missing to their roadmap, if it hasn't been done I'd start there: building up this list of things that need to happens before we can agree towards a transition, and engaging with GitHub to have these. </div><div><br></div><div>-- </div><div>Mehdi</div><div><br></div></div></div>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" rel="noreferrer">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>