From: Junio C Hamano <hidden> Date: 2021-05-10 06:25:13
Eric Sunshine [off-list ref] writes:
quoted
I think others have strong opinion on not using "%1$s",
and prefer simple "%s" and using "exec_path" twice instead.
I brought it up only because I hadn't seen it in Git sources, and
wasn't sure if we'd want to start using it. Aside from Ævar, who
seemed reasonably in favor of it, nobody else chimed in, so it could
go either way, I suppose.
If this were a piece of code that _everybody_ would use on _all_ the
supported platforms, I would suggest declaring that this is a
weather-balloon to see if some platforms have trouble using it. But
unfortunately this is not such a piece of code. Dependence on
systemd should strictly be opt-in.
So my preference is
- here, just do it in the dumb and simple way
- somewhere else, find code that is compiled and run for everybody
on all platforms that feeds two same arguments to printf format,
and update it to use "%1$x" twice, mark it clearly as a weather
balloon, and document it (see how what 512f41cf did is documented
in Documentation/CodingGuidelines and mimick, but tone it down as
we haven't declared it safe to use (yet).
It is likely that we need rearrangement of argument order for po/
files anyway, but a misimplementation might not handle using the
same placeholder twice, and that is why I'd like to be a bit extra
careful.
From: Đoàn Trần Công Danh <hidden> Date: 2021-05-12 00:29:48
On 2021-05-10 15:25:07+0900, Junio C Hamano [off-list ref] wrote:
Eric Sunshine [off-list ref] writes:
quoted
quoted
I think others have strong opinion on not using "%1$s",
and prefer simple "%s" and using "exec_path" twice instead.
I brought it up only because I hadn't seen it in Git sources, and
wasn't sure if we'd want to start using it. Aside from Ævar, who
seemed reasonably in favor of it, nobody else chimed in, so it could
go either way, I suppose.
If this were a piece of code that _everybody_ would use on _all_ the
supported platforms, I would suggest declaring that this is a
weather-balloon to see if some platforms have trouble using it. But
unfortunately this is not such a piece of code. Dependence on
systemd should strictly be opt-in.
Yes, dependence on systemd should be strictly opt-in.
Although, I don't use systemd-based distro, so it is irrelevant to me.
I think it's none of Git (the project) business to decide which
scheduler should be given higher priority. It's crontab when
maintenance was introduced, it should be crontab, now.
Another point for eternal bikeshedding: why do we limit ourselves in
crontab and systemd, how about other homebrew schedulers? What should
we do if another scheduler raise to be the big star in the scheduler
world?
I guess we should take some templates for running on {,un}register
instead? However, I think such design may open another can of worms.
So, I don't know.
--
Danh
From: Felipe Contreras <hidden> Date: 2021-05-12 06:59:40
Đoàn Trần Công Danh wrote:
Yes, dependence on systemd should be strictly opt-in.
Although, I don't use systemd-based distro, so it is irrelevant to me.
I think it's none of Git (the project) business to decide which
scheduler should be given higher priority. It's crontab when
maintenance was introduced, it should be crontab, now.
I do use a systemd-based distro, and I like the option to use systemd
units, but let's be honest...
100% of systems with systemd have cron... So...
--
Felipe Contreras
Yes, dependence on systemd should be strictly opt-in.
Although, I don't use systemd-based distro, so it is irrelevant to me.
I think it's none of Git (the project) business to decide which
scheduler should be given higher priority. It's crontab when
maintenance was introduced, it should be crontab, now.
I do use a systemd-based distro, and I like the option to use systemd
units, but let's be honest...
100% of systems with systemd have cron...
This is untrue, as the commit message points out cron is optional on
systems running systemd and there are distributions such as Arch Linux
that do not install a cron daemon without explicit user intervention.
So...
Hi Đoàn
On 12/05/2021 01:29, Đoàn Trần Công Danh wrote:
On 2021-05-10 15:25:07+0900, Junio C Hamano [off-list ref] wrote:
quoted
Eric Sunshine [off-list ref] writes:
quoted
quoted
I think others have strong opinion on not using "%1$s",
and prefer simple "%s" and using "exec_path" twice instead.
I brought it up only because I hadn't seen it in Git sources, and
wasn't sure if we'd want to start using it. Aside from Ævar, who
seemed reasonably in favor of it, nobody else chimed in, so it could
go either way, I suppose.
If this were a piece of code that _everybody_ would use on _all_ the
supported platforms, I would suggest declaring that this is a
weather-balloon to see if some platforms have trouble using it. But
unfortunately this is not such a piece of code. Dependence on
systemd should strictly be opt-in.
Yes, dependence on systemd should be strictly opt-in.
Although, I don't use systemd-based distro, so it is irrelevant to me.
I think it's none of Git (the project) business to decide which
scheduler should be given higher priority. It's crontab when
maintenance was introduced, it should be crontab, now.
You seem to be simultaneously arguing that git should be neutral on the
choice of scheduler while saying it should prioritize crontab. The
commit message and cover letter list a number of difficulties with the
strategy of prioritizing crontab over systemd when both are installed. I
think we should aim for the solution that has the most chance of working
without user intervention.
Another point for eternal bikeshedding: why do we limit ourselves in
crontab and systemd, how about other homebrew schedulers? What should
we do if another scheduler raise to be the big star in the scheduler
world?
We should support the default scheduler on each platform - that was the
rod we made for our own back when we decided to use the platform's
scheduler rather than having a cross platform git maintenance daemon. It
just happens that there are two possible default schedulers on linux so
we need to support both of them.
Best Wishes
Phillip
I guess we should take some templates for running on {,un}register
instead? However, I think such design may open another can of worms.
So, I don't know.
From: Đoàn Trần Công Danh <hidden> Date: 2021-05-12 16:45:23
On 2021-05-12 14:38:26+0100, Phillip Wood [off-list ref] wrote:
quoted
Yes, dependence on systemd should be strictly opt-in.
Although, I don't use systemd-based distro, so it is irrelevant to me.
I think it's none of Git (the project) business to decide which
scheduler should be given higher priority. It's crontab when
maintenance was introduced, it should be crontab, now.
You seem to be simultaneously arguing that git should be neutral on the
choice of scheduler while saying it should prioritize crontab.
Yes, I'm arguing for git should be neutral on the choice of scheduler.
No, I'm not arguing for git should be prioritize crontab, I'm arguing
for "princible of least surprise" for no known break-through advantage.
FWIW, whatever default scheduler chosen won't affect me, since I don't
have systemd-timers to begin with. So ...
In addition, I was one of those people pointed out that beside
crontab, Linux users nowaday employed different schedulers [1],
and the consensus, some how, settled on crontab.
I think we shouldn't switch away from crontab if we don't have any
compelling reasons.
The commit
message and cover letter list a number of difficulties with the strategy of
prioritizing crontab over systemd when both are installed. I think we should
aim for the solution that has the most chance of working without user
intervention.
The solution that has the most chance of working without user
intervention is the solution that is the status quo. Promoting
systemd-timers to higher priority is a solution requires either
user intervention or our supports (which will be carried over our
lifetime).
quoted
Another point for eternal bikeshedding: why do we limit ourselves in
crontab and systemd, how about other homebrew schedulers? What should
we do if another scheduler raise to be the big star in the scheduler
world?
We should support the default scheduler on each platform - that was the rod
we made for our own back when we decided to use the platform's scheduler
rather than having a cross platform git maintenance daemon. It just happens
that there are two possible default schedulers on linux so we need to
support both of them.
As noted in [1], some home-brew solutions are very popular solutions
among those some community.
I'm not arguing that crontab or systemd-timers aren't popular.
In fact, I think they're *very* popular, I listed systemd-timers as
*first* alternative in the linked email.
I'm not against supporting both of them, I was arguing about a generic
solution.
1: https://lore.kernel.org/git/20200407005828.GC2568@danh.dev/
--
Danh