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
> community.
> >
> >
> > Hi Tom,
> >
> > Please help me here, I think I'm severely misunderstanding what
this
> means...
> >
> > I'm reading it that the "Board of Directors" will make a
decision and
> communicate to the community, apparently through some undisclosed internal
> process.
> >
> > For example:
> > * What about people that are on holidays during the 30 days comment
> period?
> > * What if the points are not made clear after 30 days?
> > * How do we know the IWG will correctly summarise the comments to
the
> board?
> > * 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[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.
> >
>
> In my opinion, this is not a technical issue. The Board owns the
> infrastructure
for the project and is responsible for ensuring that it is well
maintained> and
> 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
> forward
> with a more robust solution otherwise we risk a major disruption to the
> community.
>
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
confidence here).
Best,
--
Mehdi
> >
>
> What additional information about the decision making process would you
> like to see?
>
> -Tom
>
> > I can't see how this "solves" the problem of
never-ending discussions,
> other than further fragmenting the community.
> >
> > cheers,
> > --renato
> >
> > [1] http://blog.llvm.org/2014/04/the-llvm-foundation.html <
> http://blog.llvm.org/2014/04/the-llvm-foundation.html>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211005/aa770ef2/attachment.html>