git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] RFC: add MAINTAINERS file

From
Patrick Steinhardt <ps@pks.im>
Date
Apr 2, 2024, 06:22 UTC
Message-ID
<ZgukEQVqOgqAIIVR@tanuki>
In-Reply-To
<owlyttkn61nq.fsf@fine.c.googlers.com>
On Sat, Mar 30, 2024 at 10:59:53AM -0700, Linus Arver wrote:
Show 25 quoted lines
> 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.

Patrick
Show 5 quoted lines
> > The development community has been fairly loosely organized so far,
> > but I'd like to see responsibility and authority spread a bit more
> > widely yet still not too thinly to compromise the project integrity.
> 
> Agreed.
Previous: Linus ArverNext: Linus Arver
Message 20 of 23 in “RFC: add MAINTAINERS file”
  1. RFC: add MAINTAINERS fileLinus Arver via GitGitGadget, Mar 23, 2024
  2. Junio C HamanoMar 23, 2024
  3. Junio C HamanoMar 25, 2024
  4. Linus ArverMar 27, 2024
  5. Patrick SteinhardtMar 27, 2024
  6. Linus ArverMar 30, 2024
  7. Junio C HamanoMar 30, 2024
  8. Taylor BlauApr 1, 2024
  9. Junio C HamanoApr 1, 2024
  10. Linus ArverApr 2, 2024
  11. Patrick SteinhardtApr 2, 2024
  12. Eric SunshineApr 2, 2024
  13. Patrick SteinhardtApr 2, 2024
  14. Linus ArverMar 26, 2024
  15. Taylor BlauMar 26, 2024
  16. Junio C HamanoMar 27, 2024
  17. Linus ArverMar 27, 2024
  18. Junio C HamanoMar 27, 2024
  19. Linus ArverMar 30, 2024
  20. Patrick SteinhardtApr 2, 2024
  21. Linus ArverApr 4, 2024
  22. Patrick SteinhardtApr 2, 2024
  23. Junio C HamanoApr 2, 2024

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.