On Tue, Oct 08, 2024 at 09:56:36AM -0700, Junio C Hamano wrote: > Taylor Blau <me@xxxxxxxxxxxx> 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
