[llvm-dev] LLVM Discourse migration: goals justify means?
Krzysztof Parzyszek via llvm-dev
llvm-dev at lists.llvm.org
Fri Jan 28 10:48:07 PST 2022
Certainly, with Bugzilla->GitHub, it was widely communicated that we planned to migrate, at some point, and there was consensus that this was a good idea. Yet, it was still a surprise that it was going to happen imminently, with no prior review from (or communcation with) the community as to the actual final plan.
I think the Working Groups should have a degree of autonomy in working out the details of a plan, especially because the details can change due to unexpected situations, or changing circumstances. As a matter of fact, I think that a part of the purpose of a WG is to be the delegate that executes an idea that the community has accepted.
--
Krzysztof Parzyszek kparzysz at quicinc.com<mailto:kparzysz at quicinc.com> AI tools development
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of James Y Knight via llvm-dev
Sent: Thursday, January 27, 2022 4:54 PM
To: Tom Stellard <tstellar at redhat.com>
Cc: Tanya Lattner via llvm-dev <llvm-dev at lists.llvm.org>; llvm-admin at lists.llvm.org; Joshua Cranmer <pidgeot18 at gmail.com>
Subject: Re: [llvm-dev] LLVM Discourse migration: goals justify means?
WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.
On Thu, Jan 27, 2022 at 4:04 PM Tom Stellard via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
From my perspective, I feel like a lot of the frustration around some
of these infrastructure projects could be avoided by improved communication
to the community about the status of these projects.
Yes, this is the problem. For both issue-tracking and mailing-list migration, I think that the announcement of an imminent migration came as a surprise to most of the community. Certainly, with Bugzilla->GitHub, it was widely communicated that we planned to migrate, at some point, and there was consensus that this was a good idea. Yet, it was still a surprise that it was going to happen imminently, with no prior review from (or communcation with) the community as to the actual final plan. For the discourse migration, it was a surprise that it's going to be happening at all -- the previous thread ended with questions, not conclusions, and there was no follow-up until "It's happening now". Although, apparently, if I'd've read the Foundation board minutes, I would've known...
It quite surprises me that, from all appearances, the LLVM IWG is not actually the entity coordinating or running these projects, but rather that apparently they're run by the LLVM Foundation Board, completely independently from the IWG. Now, I'm not in either group, so maybe I'm mistaken, but:
Discourse: https://github.com/llvm/llvm-iwg/issues/47 "figure out if the IWG should help with the migration. If not: close the issue."
Bugzilla: https://github.com/llvm/llvm-iwg/issues/56 "Just for tracking the infrastructure effort, the IWG is not involved in this activity."
Even if these projects are sponsored by the Foundation, and the person doing the technical work is a Foundation board member, I feel like the projects ought to be coordinated in public under the auspices of the IWG, rather than coordinated via private Foundation board meetings. (Otherwise, what's the point of the IWG?)
And, please note, I totally understand just how hard and time-consuming it is to run one of these migrations, both technically and socially. I really do want to support people who are trying to get infrastructure work done. And I really would like to encourage the ability to make a decision in less than 2 years. But, the almost complete lack of communication and information -- to anyone outside of the Foundation Board -- makes it quite difficult not to feel frustrated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20220128/ef2a8703/attachment.html>
More information about the llvm-dev
mailing list