Re: adacore git-hooks - daemon-mode email vs. systemd-logind linger

[Joel Brobecker <brobecker@adacore.com>]

Hi Frank,

> - just send the emails immediately, without the daemon stuff; if the
>   delays are there to try to sequentialize them, consider instead
>   getting the hooks to emit Message-Id:/In-Reply-To:/Date: headers to
>   let MUA's sort properly at reception

We can certainly add a non-daemon mode to the hooks. I don't know
when I'd have time to work on this enhancement, unfortunately.

> - invoke the email sending wrapped in a "systemd-run --user"
>   deferred execution gadget, including a "sleep XXX" if you must
>   keep time-hope-based sequencing
> 
> - move email stuff entirely out of the hooks; these repos are "public
>   property" anyhow, and we can put cron jobs in place elsewhere to
>   trigger email notifications about commits; heck, they could run the
>   hook code itself later, just feed it retrospective git-hook lines

You can configure the hooks to turn emailing off completely. From
memory, this triggers a warning message on the user end when they do
the push, just to let them know to not expect emails.

The downside of going this way, other than the minor annoyance above,
is that you lose track of who did the push. Right now, the emails
allows you to derive the information from the emails' from field.

Thinking more long term, I think there are talks about using a more
comprehensive system for source and contribution management, similar
to products such as GitLab or GitHub. Those will likely come with
they own set of tooling for things such as alerting, pre-commit
checks, keeping track of who submitted, who reviewed and approved,
and who pushed. That's why I tend to think that, for the moment,
I'd go the simplest route overall: In this case, I think the simplest
is to just have a way to disable the daemon mode, and just have
the users wait. In the vast majority of cases, the wait will be
a few seconds. Even with a patch-series of a 100 patches, it would
mean a 1min40s wait. Very bearable.

If you agree, we can create an issue for it on the git-hooks repoisitory
on GitHub.

-- 
Joel