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-...@lists.llvm.org
<mailto:llvm-...@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-...@lists.llvm.org
<mailto:llvm-...@lists.llvm.org> <mailto:llvm-...@lists.llvm.org
<mailto:llvm-...@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-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
