[cfe-dev] [llvm-dev] RFC: Code Review Process

[David Blaikie via cfe-dev]

On Thu, Oct 7, 2021 at 2:22 PM Renato Golin via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> On Thu, 7 Oct 2021 at 21:48, Reid Kleckner <rnk at google.com> wrote:
>
>> I want to take the other side here, and say that I appreciate that the
>> board is trying to provide more structure for this decision making process.
>> I don't think the board is trying to step in and take ownership of the
>> decision, they are trying to solicit input and reflect it back to LLVM
>> developers in an efficient way. It has long been clear that LLVM needs a
>> more effective process for building consensus and making decisions, and in
>> the absence of that, the board came up with this ad hoc process. That seems
>> very reasonable to me.
>>
>
> Ad-hoc isn't really sensible for such an important thing. We have done
> this before, so it's not lack of prior art either.
>

I think the term "ad-hoc" was applied to the process, not the outcome. I
don't think Reid's suggesting we'd end up with a "multiple different
kinds of review process", but that we don't have a good formal process for
decision making, so folks are experimenting with various ways to help move
big, difficult decisions forward in a more reliable way.

I do agree that it's a bit surprising to me that the board is (trying to?)
take a more authoritative responsibility over this decision. Though I'm not
averse to it in some of these sort of infrastructure cases myself. Might've
been better received if it came from the infrastructure working group
instead, not sure.


> In every past similar situation it has been the consensus that the board
> does not decide on technical matters. They may help, organise, spend
> resources, gather information, build tools, but the ultimate decision is up
> to the community (whatever that means).
>
> So far, the harder technical decisions (for example, migrating to Github),
> have been taken after enough consensus was built in the list and enough
> discussions happened in the conferences, until such a day the vast majority
> agreed it should be done.
>
> There are three main pending issues:
>  * Bugzilla, where everyone thinks we have to change but GH issues are
> nowhere near complete enough.
>  * Phabricator, where we're mostly in favour of GH PRs, but there's still
> at least one major hurdle, patch sets.
>  * Mailing list, where it's a pretty even split, with the IRC/Discord
> split being a major counter-example.
>
> Hosting on github vs self-hosted was a small change, and most people were
> in favour, but the problem was mostly around monorepo vs submodules.
>
> Starting a discord channel is not something people need "permission", but
> it did fragment the just-in-time interactions. Starting a Slack channel or
> whatever is the new thing would be the same problem, but nothing too
> terrible.
>
> However, code review, technical discussions and bug tracking are pretty
> core to how we all interact, and we should not have more than one of any of
> those things. so, whatever decision is taken it will be a decision to
> *move*, not add.
>
> This is a pretty serious decision, and I believe we'd have a lot less
> friction if we do in the same way we did the Github. Proposals,
> discussions, BoF sessions and a final decision when it's clear that the
> majority of the community is on board with the changes.
>
> But to get there, we'll need to hash out all issues. Right now, the
> discussion is around patch sets, and until that gets sorted, we really
> shouldn't even try to use PRs. It may take less then 30 days, it may take
> more, but that discussion must happen in the list, not in a working-group
> or in the foundation board's meeting.
>
> This is how we've always done it so far and it has been working well. At
> least most people I know think that this is better than most other
> alternatives, including ad-hoc decision making plans.
>

I'm not sure I'd say it's been working well - it took a lot of time, a lot
of volunteers and dragging some folks along in the end anyway. I think
there's a lot of merit in having a more structured (honestly: faster)
decision making process. We often end up in choice/analysis paralysis -
where it's easier to object than to address objections, which is tiring for
those trying to make change & slows down things quite a bit.

- Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20211007/bee5fb79/attachment.html>