git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Taylor Blau <me@ttaylorr.com>
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 17:22:27 +0200	[thread overview]
Message-ID: <ZwAIM6GO3VtoG3ZM@pks.im> (raw)
In-Reply-To: <Zv7aLRXwt9cfqW58@nand.local>

On Thu, Oct 03, 2024 at 01:53:49PM -0400, Taylor Blau wrote:
> On Thu, Oct 03, 2024 at 10:26:19AM -0700, Junio C Hamano wrote:
> > It can be somebody stepping up and say "ok, I'll self nominate and
> > run the project as the interim maintainer, just like it was done in
> > the past years", or "let's do something differently, how about
> > everybody throws a merge request to this mob repository, use this
> > (possibly different) review procedure, and give back the tip of
> > 'master' when Junio returns", or "OK, we'll discuss and exchange
> > patches for these two weeks among ourselves and we can cope without
> > a central meeting place".
> >
> > IOW, I am interested to see if the community comes up with a
> > day-to-day project structure that may be better for the contributors
> > than what I have dictated in the past during my vacation time.
> 
> Interesting. If list participants would prefer to use the same structure
> as when you're not on vacation, I'm happy to shuffle the patches and
> send regular "What's cooking" reports for those couple of weeks.
> 
> I guess that amounts to the "I'll self nominate and run the project as
> interim maintainer" option you mentioned above :-).

First things first: I wouldn't mind you doing it again.

But I'd also like to take this opportunity to think a bit about the
bigger picture: what do we all do when Junio stops working on Git at
some point in time? Right now we don't really have a plan for that at
all, to the best of my knowledge. I know this is going a bit further
than what Junio has hinted at with this "fire drill", but thinking about
such a potential future is certainly important. And if we can come up
with good ideas, then we might as well try them out and experiment a bit
while Junio is out.

First, let's talk about the requirements that come to my mind for any
replacement:

  - Doing Junio's work certainly is a full-time job, whether that
    full-time job is handled by a single person or split up across a
    team.

  - As far as I can see, doing the maintainer job doesn't allow for a
    ton of hacking. So whoever is taking over likely wouldn't be able to
    land much code anymore.

  - Junio is doing a great job of being independent from any kind of
    company agenda as far as I can tell. A replacement would have to be
    just that, either because that person is being independently funded
    or because it is a team set up similar to the PLC.

  - It goes without saying that the person would need to have deep
    knowledge of Git and the codebase such that they can make informed
    decisions.

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.

So... that's just me dumping a bunch of thoughts. I'd be quite curious
to learn about everyone else's thoughts.

Patrick

  reply	other threads:[~2024-10-04 15:22 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 [this message]
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

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=ZwAIM6GO3VtoG3ZM@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=me@ttaylorr.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).