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

[David Blaikie via lldb-dev]

On Thu, Oct 7, 2021 at 3:44 PM Renato Golin <rengolin at gmail.com> wrote:

> On Thu, 7 Oct 2021 at 23:16, David Blaikie <dblaikie at gmail.com> wrote:
>
>> I don't think diversity necessarily relates to this aspect of managerial
>> structure. Unless we're talking about the less benevolent dictatorships
>> where the authority figures both provide structure, but also set some
>> fairly negative tones for how people should relate. Those things aren't
>> necessarily connected though, and I don't see signs that's the kind of
>> leadership we have or are moving towards in the LLVM community.
>>
>
> Sorry, that's not at all what I meant.
>
> LLVM attract all kinds of people, not just from different backgrounds and
> minorities, but also different cultures. And by culture I mean a lot of
> things.
>
> We have different countries and continents; academia, enterprise and
> government; students, professionals, directors; enthusiasts or people just
> trying to make some money; open and closed source source projects; embedded
> into or built as a library or being used by a dependency. I myself have
> belonged to many of those groups over the years.
>
> In my opinion, that variety in how we all use and rely on LLVM is key to
> its success, but it's also what makes it hard to drive larger changes that
> affect the least amount of people.
>
> Even foundations and working groups can't be representative of all people
> and most of the time we don't even know who "the people" are until we try
> to change something and it breaks for them.
>
> This is why long consensus "works" for us, because eventually by then,
> most people would have seen it and voiced their opinions. But it's slow and
> painful.
>
> I personally prefer that pain, then the pain of seeing each new decision
> alienating a small, but substantial, part of the community, and making the
> project less and less palatable to new contributors from different cultures.
>

Not making changes (or making them especially slowly) can also exclude
people, which is one of the things we're grappling with in this decision
too (every patch that comes in through a pull request and is automatically
rejected - where that contributor doesn't then go and do all the extra work
of figuring out phab, creating an account, etc, is lost new
contributions/contributors, for instance)

I don't think the longer process we've used in the past necessarily created
higher quality decisions - I think moving to github, preserving
commit/author history, and maintaining a linear version history might've
been a decision that could've been made (& would likely have been made,
moreso than other options that were considered) relatively quickly, for
instance.

All this said - I think the place where the IWG/board can be most helpful
is to lower the costs of dealing with the infrastructure problems - in the
github migration, figuring out tooling to preserve history/manage the
migration and enforce the linear version history, etc - that took time to
consult with github, build scripts and test them, etc. Doing that
pre-emptively/more aggressively and being able to demonstrate a path
forward to the community would probably be pretty helpful.

Similarly, taking the feedback from a review like this around github pull
requests for review, and using whatever weight/consulting/paid
consultants/contractors/etc might be available to help implement any
feasible feature improvements to smooth the transition might be quite
helpful. (tricky to frame that as "exploratory"/lowering barriers without
it being "we've already decided the direction and the community will just
have to accept it" is tricky, and how much of that sort of work is worth
doing without it being clear that the work will be used/will pay off in the
end - that's complicated) But hopefully a general "what're the concerns,
how broad reaching are they/how many people have them" and then some time
to figure out how feasible addressing each of them is, what sort of
timeframe, etc, seems like a place to start.

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