<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 5, 2021 at 10:09 AM Tom Stellard 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">On 10/5/21 9:47 AM, Renato Golin wrote:<br>
> On Tue, 5 Oct 2021 at 17:06, Tom Stellard via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a> <mailto:<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>> wrote:<br>
> <br>
> - Any other information that you think will help the Board of Directors make the best decision. <br>
> <br>
> - Foundation Board will have 30 days to make a final decision about using GitHub Pull Requests and then communicate a migration plan to the community.<br>
> <br>
> <br>
> Hi Tom,<br>
> <br>
> Please help me here, I think I'm severely misunderstanding what this means...<br>
> <br>
> I'm reading it that the "Board of Directors" will make a decision and communicate to the community, apparently through some undisclosed internal process.<br>
> <br>
> For example:<br>
> * What about people that are on holidays during the 30 days comment period?<br>
> * What if the points are not made clear after 30 days?<br>
> * How do we know the IWG will correctly summarise the comments to the board?<br>
> * How does the board guarantee it will take all facts in consideration without bias?<br>
> * What kind of recourse would the community have if the decision alienates a large part of the developers?<br>
> <br>
> Please understand that I'm not assuming malice *at all*. We're all humans, and in the effort to make some change happen we quite often let unconscious bias be the merits of our decisions.<br>
> <br>
> For context...<br>
> <br>
> Since its inception[1], the foundation has always steered away from technical decisions, always referring to the llvm-dev list for those. Previous long running contentious issues (Github, monorepo, CoC) were all decided by the community, in the llvm-dev list, and executed by the foundation.<br>
> <br>
<br>
In my opinion, this is not a technical issue. The Board owns the infrastructure</blockquote><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">
for the project and is responsible for ensuring that it is well maintained and<br>
functional. From the blog post:<br>
<br>
"The LLVM Foundation" will allow us to:<br>
<br>
- Solve infrastructure problems.<br>
<br>
This is what we are doing here. The project is very much at risk by using<br>
a self-hosted, unmaintained code review tool. We really need to move forward<br>
with a more robust solution otherwise we risk a major disruption to the community.<br></blockquote><div><br></div><div>I'd like to dispute this on multiple accounts.</div><div><br></div><div>- You write that "the board owns the infrastructure", but the board has never been involved with Phabricator in any way (the hosting is provided by Google from the beginning: both the machine and human-power to keep it running), nor did the board get in touch recently with the folks currently keeping the instance running as far as I know.</div><div>- You write that the "project is very much at risk", but Phabricator has been self-hosted for > 8 years and it isn't clear to me why there is a sudden emergency on this side. The claim of "risk a major disruption to the community" to justify the current push looks like FUD to me.</div><div><br></div><div>The RFC states that "we would like to move away from a self-hosted solution", but who is "we"? How was this decided and why?</div><div><br></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">
> Recent discussions about the mailing list, irc, discord, discourse have emphasised that, even with an infrastructure working group, the views of the community are still too hard to predict and make it work for the majority. Neither the board of directors, nor the IWG are wide and diverse enough to make decisions that take most people's views into consideration. That is why we still rely on the dev list for large technical discussions and decisions.<br>
> <br>
> Code review and bug tracking are very much technical decisions. Not code directly, but how we all work. And there are a lot of us. Giving feedback and having no insight into the decision making process will certainly divide the community even more, if we're forced to accept whatever outcome.<br></blockquote><div><br></div><div>+1 to everything Renato wrote above, in particular how these tools are fairly core to our development and are technical matters.</div><div><br></div><div>With all that said, I think the process and the way the RFC was written distracts unnecessarily from the discussion here: it seems fairly healthy to me to just re-evaluate our tooling and how they fit our needs and revisit the alternatives. <br></div><div><br></div><div>I'd love it if we were able to move to pull-request, but I'm also quite wary of rushing it for other considerations before we can get a roadmap to get to the same feature level on GitHub that we get through Phabricator today (and the narrative pushed through in the RFC does not bring me confidence here).</div><div><br></div><div>Best,</div><div> </div><div>-- </div><div>Mehdi</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">
> <br>
<br>
What additional information about the decision making process would you like to see?<br>
<br>
-Tom<br>
<br>
> I can't see how this "solves" the problem of never-ending discussions, other than further fragmenting the community.<br>
> <br>
> cheers,<br>
> --renato<br>
> <br>
> [1] <a href="http://blog.llvm.org/2014/04/the-llvm-foundation.html" rel="noreferrer" target="_blank">http://blog.llvm.org/2014/04/the-llvm-foundation.html</a> <<a href="http://blog.llvm.org/2014/04/the-llvm-foundation.html" rel="noreferrer" target="_blank">http://blog.llvm.org/2014/04/the-llvm-foundation.html</a>><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>