Re: [PATCH] multimail: stop shipping a copy

From: Matthieu Moy <git@matthieu-moy.fr>
Date: Jun 10, 2021, 14:03 UTC
Message-ID: <1554066605.61418500.1623333784687.JavaMail.zimbra@matthieu-moy.fr>
In-Reply-To: <877dj22fly.fsf@evledraar.gmail.com>

"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>:

Show 12 quoted lines

> On Thu, Jun 10 2021, Johannes Schindelin via GitGitGadget wrote:
>
> > From: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> > The multimail project is developed independently and has its own project
> > page. Traditionally, we shipped a copy in contrib/.
>
> > However, such a copy is prone to become stale, and users are much better
> > served to be directed to the actual project instead.
>
> Let's CC its maintainer / other people who've actively contributed to
> it. I've taken the liberty to do that.

Thanks.

> It seems to me that the state is that we're on the 1.5.0 release, and
> upstream hasn't cut a new release.

Yes. In practice, I am no longer a user of git-multimail.py (my use of Git moved from some self-hosted repo on a server accessible through SSH to some more black-box hosting like GitLab where I can't use it anymore), and I receive very few pull-requests and issues, so the project is essentially stalled. Not dead, but probably just good enough so no real evolution happen these days.

> The upstream maintainer(s) are active contributors to git,

Actually, I used to, but it's been a while since I contributed to Git. I've been busy with other stuff, and I'm struggling to find time to come back.

Michael used to be the maintainer, but completely left the project after I took it over.

> so the risk of this becoming stale seems low.

This part is still true: sending the patch to Git is part of my release checklist, I'm unlikely to forget.

That said, the benefit of keeping a copy in git.git is debatable, and probably low. I have no objection in removing it, i.e. applying Dscho's patch.

> Having written a system in the past that made use of git-multimail.py
> (and sourced it from git.git's copy) I'd think a better direction would
> be to keep this and modify githooks(5) to actively recommend it over the
> older and less featureful post-receive-email script.

I'm all for recommending it in githooks, but this can be done by pointing to GitHub's URL instead of a local path. Actually the sample script could look like

# Fetch git-multimail.py from https://github.com/git-multimail/git-multimail/ # adapt and uncomment the following line: #exec /path/to/git_multimail.py

Cheers,

-- 
Matthieu Moy
https://matthieu-moy.fr/