From: Patrick Steinhardt <ps@pks•im>
To: Junio C Hamano <gitster@pobox•com>
Cc: Taylor Blau <me@ttaylorr•com>, git@vger•kernel.org
Subject: Re: the latter half of october, the maintainer goes offline
Date: Wed, 9 Oct 2024 07:51:04 +0200 [thread overview]
Message-ID: <ZwYZwBOYpd4nribV@pks.im> (raw)
In-Reply-To: <xmqqv7y2354r.fsf@gitster.g>
On Tue, Oct 08, 2024 at 09:56:36AM -0700, Junio C Hamano wrote:
> Taylor Blau <me@ttaylorr•com> writes:
>
> > 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.
> >> ...
> > 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 ;-).
>
> This turned my "explore how you folks want to manage yourselves
> while I am away" into "how would we want to run the project after
> Gitster retires (or moves on)". While I find that the rumor of my
> retirement is greatly exaggerated, I think that is a discussion
> worth having.
Just to make things clear: I didn't think that you're going to retire
anytime soon. As you say, I rather wanted to use this situation to think
a bit about the bigger picture and think way ahead into the future.
We do not have any kind of contingency plan if you ever did retire, to
the best of my knowledge. And while I hope we won't need such a plan
anytime soon, having some kind of common understanding of how that
situation would be handled in the community would be nice. I could
imagine that this discussion would be rather heated, so my hope was that
it is less heated by having it in a situation without an immediate
need.
> It is a tricky topic how we want open source funding to work.
>
> The "benevolent dictator" model, even if the day-to-day operation is
> delegated to various area experts (aka lieutenants), cannot work if
> such a dictator simply does not exist (due to various reasons,
> ranging from "nobody wants to become one" to "community cannot agree
> on whom to make one"). The community has to go with some other
> model that does not require a dedicated full-time maintainer, even
> if it prefers to have one (and the community can choose to follow a
> different model even if it can afford one, of course).
>
> I think the status-quo, which was nurtured over the years, is the
> best this community can have, *if* we want to keep the "benevolent
> dictator" model. I would not claim that we perfected the model, but
> I would say we are close enough.
I do not really see a strong reason to change the current model while
you are happy to fill in the role. If the model _has_ to change I think
it strongly depends on exactly what you say, whether the community can
agree on a new maintainer or not.
The Linux kernel partially uses group maintainership models for some of
its subsystems, see e.g. [1]. Python uses something a steering council,
which is a 5-person committee [2]. Other large projects like Debian also
use a technical committee to resolve conflicts [3]. So there are some
projects out there where maintainership is handled by a group of people.
Now all of these projects are way bigger than Git, and they of course
have different requirements than we do. So the mere fact that they seem
to use these models successfully doesn't necessarily translate into it
working well for us.
In any case, if we ever wanted to change the model, we'd have to think
quite hard about how to do it.
[1]: https://lwn.net/Articles/705228/
[2]: https://peps.python.org/pep-0013/
[3]: https://www.debian.org/devel/tech-ctte
> What I hoped to see happen here was that the community is prepared
> when the community has to (or wants to)choose another model. And I
> am happy to see the recent trend to document and codify how we make
> decisions and move the project forward, because these efforts help
> us whether we have the "benevolent dictator" or not.
True. We could also do the same for our maintainership model: lay out
requirements and the different models that fulfill these requirements.
That would allow us to discuss things in detail and capture the results
in a single document.
The intent here wouldn't be to change the current model (at least that
would not be my intent), but to document it and maybe have alternatives
ready if we ever got to the situation where the current model doesn't
work anymore due to whatever reason.
Patrick
prev parent reply other threads:[~2024-10-09 5:51 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
2024-10-08 16:56 ` Junio C Hamano
2024-10-09 5:51 ` Patrick Steinhardt [this message]
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=ZwYZwBOYpd4nribV@pks.im \
--to=ps@pks$(echo .)im \
--cc=git@vger$(echo .)kernel.org \
--cc=gitster@pobox$(echo .)com \
--cc=me@ttaylorr$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox