From: Taylor Blau <me@ttaylorr.com>
To: Patrick Steinhardt <ps@pks.im>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: the latter half of october, the maintainer goes offline
Date: Fri, 4 Oct 2024 18:47:12 -0400 [thread overview]
Message-ID: <ZwBwcOK2/sazF17B@nand.local> (raw)
In-Reply-To: <ZwAIM6GO3VtoG3ZM@pks.im>
On Fri, Oct 04, 2024 at 05:22:27PM +0200, Patrick Steinhardt wrote:
> There are two maintainership models I can think of: either a single
> individual or a group of people would take over.
>
> - A single individual needs funding. The ideal situation would be if
> that funding came independent of any of the large forges. Or
> alternatively, the big players in this context come together to all
> pay into the same pot to fund that person. In theory, the role could
> be elected and serve for a limited amount of time so that overall,
> the community is in control.
>
> - A group of individuals could take over, sharing the responsibility.
> There would be a ton of different questions in this context: how to
> form the group, how to balance its interests, how to distribute the
> work across its members, how to resolve disputes, etc.
I do think there is a need to have a single individual who is ultimately
responsible for ensuring that the patches are reviewed and merged in a
timely fashion, that releases are cut on time and are high-quality, etc.
But I also think that the project benefits from having trusted
individuals who are knowledgeable about specific areas of the codebase.
The maintainer can lean and rely on those individuals to get a sanity
check of whether or not some patches are good or not. For instance, I
would imagine that Junio relies on you to help review patches in the
reftable implementation.
I think that's more or less the status-quo, and IMHO it works well from
a contributor's perspective. I would be curious if the maintainer feels
the same or not ;-).
I know that we have discussed in the past a more formalized version of
the above where individual sub-systems maintainers are listed in a
MAINTAINERS file with specific roles and responsibilities. I don't think
the project is large enough or has enough active participants to warrant
that formal of a process, but perhaps I am in the minority here.
Thanks,
Taylor
next prev parent reply other threads:[~2024-10-04 22:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-03 17:26 the latter half of october, the maintainer goes offline Junio C Hamano
2024-10-03 17:53 ` Taylor Blau
2024-10-04 15:22 ` Patrick Steinhardt
2024-10-04 16:31 ` shejialuo
2024-10-04 16:38 ` shejialuo
2024-10-04 16:58 ` Junio C Hamano
2024-10-04 22:35 ` Taylor Blau
2024-10-07 5:47 ` Patrick Steinhardt
2024-10-07 14:56 ` Taylor Blau
2024-10-07 15:28 ` Patrick Steinhardt
2024-10-04 22:47 ` Taylor Blau [this message]
2024-10-08 16:56 ` Junio C Hamano
2024-10-09 5:51 ` Patrick Steinhardt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZwBwcOK2/sazF17B@nand.local \
--to=me@ttaylorr.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.