Subject: Re: the latter half of october, the maintainer goes offline

From: Patrick Steinhardt <[email-masked]>
Date: Wed, 9 Oct 2024 07:51:04 +0200

On Tue, Oct 08, 2024 at 09:56:36AM -0700, Junio C Hamano wrote:
> Taylor Blau <[email-masked]> 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