Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Russ Allbery]

Josh Triplett  writes:

> Mostly, recent discussions in various places regarding whether packages
> are required to use *cron* to run periodic jobs. Policy says what
> packages must do if they install a cronjob, but that itself does not
> mandate the use of cron specifically. It seemed worth explicitly stating
> the understood-but-unwritten interpretation that having Policy about XYZ
> does not mandate that packages use XYZ.

There is a near-universal human tendency to argue with the medium if one
disagrees with the message.  As part of the old saying among lawyers,
often attributed to Carl Sandburg, goes: "If the facts are against you,
argue the law.  If the law is against you, argue the facts."

I don't think these discussions were truly about the wording of Policy,
and I don't think changing the wording of Policy in the way you propose
would have changed those discussions.  There is no magic wording of Policy
that, if we get all of the sentences just right, will cause the project
disagreement over the appropriate role of systemd to somehow melt away.

It is possible that someone unaware of the long-standing project debates
about systemd and timers and so forth (I take it on faith that somehow
such people still exist) might, upon reading Policy and seeing only one
description of how to handle periodic tasks, assume that's the only one
that Debian supports.  I don't think the solution to that problem is to
add a generic statement elsewhere in Policy that they are neither likely
to read nor likely to connect to the problem they're trying to solve.  I
think a better solution is to document the other way of doing things in
Policy.  Then we can argue about whether Policy should recommend one
method over another, which is the real heart of the disagreement that at
some point we need to confront.

(I know, I know, I'm one to talk given that I dropped all my Policy work
on the floor and disappeared for six months.  But still, I would give
myself the same advice.)

-- 
Russ Allbery (r...@debian.org)  

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sean Whitton]

Hello,

On Tue 26 Mar 2024 at 10:11am -06, Sam Hartman wrote:

>> "Josh" == Josh Triplett  writes:
>
>
>
> I tend to agree with  Sean that your rationale is not convincing.
> It sounds like you want to use policy as a stick to hit people
> over the head and say "policy is not a stick."

This was basically my concern.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1067079: Clarify that policy on a technology does not implicitly mandate that technology

[Sam Hartman]

> "Josh" == Josh Triplett  writes:



I tend to agree with  Sean that your rationale is not convincing.
It sounds like you want to use policy as a stick to hit people
over the head and say "policy is not a stick."

I get the impression that you are trying to shift the status quo
somehow, and remove flexibility and replace it with certainty.

Let's take installing info files.
Yes, the policy around info files is optional.
But if you have info files, I think it would be a great idea if you
installed them.
(And if you are going to do that, I think we are all agreed you should
follow policy in how you do that.)

You appear to be wanting to say that the presence of the info policy is
entirely neutral.
And I don't quite think that's true.

It could mean:

1) hey it's there if you want to install info files

2) Hey if you've got info files go install them and use this great
mechanism for doing so.

3) Hey, if you're looking for how to document your software strongly
consider info because we have a way of dealing with info.

I think you're arguing that globally unless policy says otherwise we're
at 1 above.
For info I think we're closer to 2, but probably somewhere between 1 and
2.
In the past, we were probably definitely at 2 and probably somewhere
between 2 and 3.
It has shifted over time as the set of software without texinfo
documentation increased, as the limitations in info format became more
important, and as html became more of a common format.

I think the kind of language you propose to add to policy harms rather
than encourages that sort of shift over time.

I think arguments of the form we have an approach for handling this in
policy, and uniformity is good, so please use this approach are
sometimes good.
I think your language would try and cut off those arguments more than
they should be cut off.
I also understand those arguments are sometimes bad.  As an example,
arguments of that form were made in favor of the Debian menu system long
past the time when desktop files were a better choice.

I suspect there are similar issues with cron files.  Five years ago,
even if policy didn't encourage cron as the preferred mechanism for
periodic tasks, it probably was the right choice.  Saying use cron
because we have a cron policy was not and should not be a valid
argument.  Saying that in a multi-init-system world there are
complexities around using something besides cron, and we've thought
through how to handle cron, so it's probably a good choice probably was
a compelling argument five or six years ago.  We probably haven't
thought through the implications of using something other than cron in a
multi-init-system world and making sure everything works well.  What has
changed is that it's not clear we're really in a multi-init-system-world
any more, and systemd has thought through the implications of periodic
tasks in a systemd world.

But I think the kind of language you proposed would be used to treat
arguments like "if you use cron it will work better for sysvinit; we
care about sysvinit; so do that," as "we talk about cron in policy, so
use it."
The second argument never has been valid.
The first argument is one I think should be valid in form, although at
the current time I think it is liked based on a false premise.
The second argument can be dismissed because of its form.
I think the first argument requires more consideration, and I think your
proposal would remove that consideration, even if reworded.


--Sam


signature.asc
Description: PGP signature