Re: [PATCH] RFC: add MAINTAINERS file

From: Linus Arver <linusa@google.com>
Date: Apr 4, 2024, 00:47 UTC
Message-ID: <owlyzfuarm1o.fsf@fine.c.googlers.com>
In-Reply-To: <ZgukEQVqOgqAIIVR@tanuki>

Patrick Steinhardt <ps@pks.im> writes:

Show 40 quoted lines

> On Sat, Mar 30, 2024 at 10:59:53AM -0700, Linus Arver wrote:
>> Junio C Hamano <gitster@pobox.com> writes:
>> 
>> > Linus Arver <linusa@google.com> writes:
>> >
>> >> I realize that such an idea is beyond the scope of a simple MAINTAINERS
>> >> (or similar) file that's checked into the Git code repo, but I think
>> >> it's worth stating as a thought experiment.
>> >
>> > As we already have agreed that neither of us care the exact format
>> > of the file (yet), regardless of how a contributor, who is about to
>> > send a patch, will find an area "maintainer" to help the patch along
>> > the process, it is far more important to discuss and decide what
>> > responsibilities and authorities are expected of these maintainers.
>> 
>> I'm starting to think that the new responsibility should be as small as
>> possible, and build from there. So the smallest bit of (initial?)
>> responsibility expected of the new roster of maintainers could be
>> "maintainer must respond to CC pings on the list within 7 days".
>> 
>> For those who have more time to spend on the project, the next rung of
>> responsibility could be "maintainer is available to review patches
>> outside of their domain of expertise if no one else has reviewed the
>> series in 7 days".
>> 
>> I haven't thought too much about the "authority" part yet.
>
> One thing that makes me feel a bit uneasy about the authority part is
> that contributors to Git are quite often direct competitors on the
> company level, as well. This never has been a problem in the past, quite
> on the contrary: I really value the cross-competitor collaboration we
> have in this project.
>
> But I have to wonder what it can potentially lead to if we did assign
> more authority to some contributors. Theoretically speaking, that would
> allow for sabotaging interests of a direct competitor.
>
> Mind you, I don't think this would happen in the current state of the
> project. I'm merely trying to think about worst-case scenarios, which
> may or may not be helpful in this context.

No problem (I also like to think worst-case scenarios, so thanks for the thought experiment).

Initially I agreed with the concerns you raised, but on further thinking I don't have the same concerns any more, for two reasons.

  (1) It's impossible to tell if someone is actually intentionally
      sabotaging the interests of a competitor --- simply because no one
      will admit to doing so openly on this list.

  (2) Even if we do have authority figures on this project, if they
      block a patch series from being merged, the reasons they give must
      remain purely technical. Otherwise, I think such authority figures
      will compromise (lose) their reputation pretty quickly.

For (2) it could be that they could block something for both $DAYJOB and technical reasons, but I think this is still fine. The fact that they have $DAYJOB reasons wouldn't take away any merit from the technical reasons.