[llvm-dev] RFC: Code Review Process
Mehdi AMINI via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 5 10:48:39 PDT 2021
On Tue, Oct 5, 2021 at 10:09 AM Tom Stellard via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On 10/5/21 9:47 AM, Renato Golin wrote:
> > On Tue, 5 Oct 2021 at 17:06, Tom Stellard via llvm-dev <
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> > - Any other information that you think will help the Board of
> Directors make the best decision.
> > - Foundation Board will have 30 days to make a final decision about
> using GitHub Pull Requests and then communicate a migration plan to the
> > Hi Tom,
> > Please help me here, I think I'm severely misunderstanding what this
> > I'm reading it that the "Board of Directors" will make a decision and
> communicate to the community, apparently through some undisclosed internal
> > For example:
> > * What about people that are on holidays during the 30 days comment
> > * What if the points are not made clear after 30 days?
> > * How do we know the IWG will correctly summarise the comments to the
> > * How does the board guarantee it will take all facts in consideration
> without bias?
> > * What kind of recourse would the community have if the decision
> alienates a large part of the developers?
> > 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.
> > For context...
> > Since its inception, 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
> In my opinion, this is not a technical issue. The Board owns the
for the project and is responsible for ensuring that it is well maintained
> functional. From the blog post:
> "The LLVM Foundation" will allow us to:
> - Solve infrastructure problems.
> This is what we are doing here. The project is very much at risk by using
> a self-hosted, unmaintained code review tool. We really need to move
> with a more robust solution otherwise we risk a major disruption to the
I'd like to dispute this on multiple accounts.
- 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.
- 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.
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?
> 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.
> > 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.
+1 to everything Renato wrote above, in particular how these tools are
fairly core to our development and are technical matters.
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.
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
> What additional information about the decision making process would you
> like to see?
> > I can't see how this "solves" the problem of never-ending discussions,
> other than further fragmenting the community.
> > cheers,
> > --renato
> >  http://blog.llvm.org/2014/04/the-llvm-foundation.html <
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev