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

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/llvm-dev/attachments/20211007/bee5fb79/attachment.html>

On Thu, 7 Oct 2021 at 22:31, David Blaikie <dblaikie at gmail.com> wrote:
> 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.
>
Right, "working well" can mean multiple things... :)

Most people I spoke about this over the years think that it's still better
than other models, like "benevolent" dictator,
"meritocratic" authority,
diverse types of voting systems, elected "officials", etc.

There are plenty of big projects that follow those models and ours seems to
be the most inclusive and open to diversity, but not the most efficient. I
think that side of our community still attracts a lot of people from all
over the world and is an identifying trait.

Personally, I prefer to be in the diverse end of the spectrum than on the
efficient end, mostly because the efficient ones tend to be autocratic in
nature.

But this is mostly on the technical but not code decisions. Code decisions
I think we can be pretty efficient.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/bf705f5e/attachment.html>