[llvm-dev] [cfe-dev] RFC: Code Review Process
Renato Golin via llvm-dev
llvm-dev at lists.llvm.org
Thu Oct 7 14:22:16 PDT 2021
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.
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.
cheers,
--renato
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20211007/553f742e/attachment-0001.html>
More information about the llvm-dev
mailing list