>>>>> "Josh" == Josh Triplett <j...@joshtriplett.org> 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
