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

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

[Josh Triplett]

On Sat, Mar 23, 2024 at 12:08:10PM +0800, Sean Whitton wrote:
> Thanks.  For the time being, I myself am not convinced.  Policy is not a
> stick to beat maintainers with, as we say, but I'm not sure that idea is
> one that ought to be in Policy itself.

Having observed many attempts to use Policy as a stick, could you
provide any insight about why you feel there isn't value in writing down
something that's already established to be true but not otherwise
documented? Would another wording or approach help address that better?

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

[Sean Whitton]

Hello,

On Mon 18 Mar 2024 at 04:06am -07, Josh Triplett wrote:

> On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote:
>> Was there some recent packaging situation that prompted you to think
>> about this?  I'm cautious about adding it in the absence of that.
>
> 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.
>
> I've also seen a few arguments over the decades that amount to "Policy
> talks about A, and doesn't talk about B" being used as some amount of
> weight towards A or against B.
>
> And finally, I have occasionally seen someone try to build a Debian
> package by sitting down with the Policy manual, and start down the route
> of trying to supply everything Policy talks about that seems like it
> makes sense for the package. The mention of "Policy talking about where
> to install info documentation, but that doesn't mean you have to have
> info documentation" was not a hypothetical; I've seen that and similar
> reasoning a non-zero number of times.
>
> I figured that something like this text would help address all of those.

Thanks.  For the time being, I myself am not convinced.  Policy is not a
stick to beat maintainers with, as we say, but I'm not sure that idea is
one that ought to be in Policy itself.

-- 
Sean Whitton


signature.asc
Description: PGP signature

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

[Josh Triplett]

On Mon, Mar 18, 2024 at 05:38:15PM +0800, Sean Whitton wrote:
> Was there some recent packaging situation that prompted you to think
> about this?  I'm cautious about adding it in the absence of that.

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.

I've also seen a few arguments over the decades that amount to "Policy
talks about A, and doesn't talk about B" being used as some amount of
weight towards A or against B.

And finally, I have occasionally seen someone try to build a Debian
package by sitting down with the Policy manual, and start down the route
of trying to supply everything Policy talks about that seems like it
makes sense for the package. The mention of "Policy talking about where
to install info documentation, but that doesn't mean you have to have
info documentation" was not a hypothetical; I've seen that and similar
reasoning a non-zero number of times.

I figured that something like this text would help address all of those.

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

[Sean Whitton]

Hello Josh,

Was there some recent packaging situation that prompted you to think
about this?  I'm cautious about adding it in the absence of that.

-- 
Sean Whitton

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

[Josh Triplett]

Package: debian-policy
Version: 4.6.2.1
Severity: normal
Tags: patch
X-Debbugs-Cc: j...@joshtriplett.org

This proposal adds a paragraph to Policy to explicitly state that having
policy about *how* to use a particular technology or mechanism is not
necessarily policy *requiring* the use of that technology or mechanism.
Policy can explicitly state that packages must use a particular
technology, but having policies *about* that technology does not imply
such a mandate.

For example, having policy about how to install info files does not mean
that packages must provide info files. Having policy about how to ship
cron jobs does not mean that packages must ship cron jobs. (This is
already the standard interpretation, and thus this does not *change*
policy, but rather it clarifies that and avoids misinterpretation.)

Stating this up front can help packagers understand that not all parts
of Policy will apply to them, and that they're not required to use a
particular technology *unless* Policy specifically says that.

I've provided a patch implementing this, but I'm happy to modify the
wording as desired, and will make updates as requested.

This patch is also available on Salsa at:
https://salsa.debian.org/josh/policy/-/tree/no-implicit-requirements

diff --git a/policy/ch-scope.rst b/policy/ch-scope.rst
index a279c26..047cdf8 100644
--- a/policy/ch-scope.rst
+++ b/policy/ch-scope.rst
@@ -25,6 +25,12 @@ Debian policy does not mean that it is not a bug, let alone 
that it is
desirable.  Questions not covered by policy should be evaluated on
their merits.

{+This manual often specifies that if a package wants to use a particular+}
{+technology or mechanism, it must/should meet specific requirements when+}
{+doing so. The inclusion of such requirements in this manual does not+}
{+require the use of that particular technology or mechanism, unless this+}
{+manual explicitly includes a requirement to that effect.+}

The footnotes present in this manual are merely informative, and are not
part of Debian policy itself.