On 10/5/21 10:48 AM, Mehdi AMINI wrote:>
>
> On Tue, Oct 5, 2021 at 10:09 AM Tom Stellard via llvm-dev <llvm-dev at
lists.llvm.org <mailto: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>
<mailto: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.
Sorry, 'owns' is probably the wrong word. What I mean is the Board is
responsible
for the infrastructure. Yes, it's great that Google has been contributing
the
machines and human support to keep it running, this has been a great service to
the community. However, it's not a good position for the Board to be
responsible
for something that it doesn't have control over. If Google decided to stop
hosting
Phabricator for some reason (unlikely, but not impossible), the Board would be
responsible for finding a replacement.
> - 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.
>
This is not meant to insult or diminish the work done by the maintainers over
the last 8 years. The self-hosted part is a risk, but a small one for reasons
mentioned above. The main risk is that Phabricator is no longer maintained
upstream.
There was already an issue[1] recently where the arc tool stopped working and
won't
be fixed upstream. Using unmaintained software is a bigger risk.
[1] https://lists.llvm.org/pipermail/llvm-dev/2021-September/153019.html
> 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?
>
We, meaning the LLVM Board of Directors. And really the problem isn't the
self-hosting
so much as it's the lack of an enforceable maintenance agreement the
Foundation and the
maintainers.
-Tom
>
> > 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>
<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 <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
>