Russ Allbery <[email protected]> writes: > Simon Josefsson <[email protected]> writes: > >> Indeed -- we made Rules-Requires-Root and Priority:optional irrelevant >> recently, couldn't we also make Standards-Version an optional field? > >> In many packages, having that field just results in needless churn of >> debian/ files. > > This comes up regularly, and maybe it's not worth having the field just > for this reason given how much it apparently annoys people, but I've never > seen anyone provide a good solution for the primary use case I have for > Standards-Version: When I pick up a random package to update, I want to > know how far back in time I have to go in looking at the Debian Policy > upgrading checklist to see what I may need to update.
Yeah, for people initimiately familiar with that checklist I suppose that is a good use-case for this. The information could be in a git commit message though? Personally, I've never found the upgrade checklist relevant for per-package upgrades. I find the checklist useful to understand what changed between policy releases, but more as a curiosity to understand general preferences over time. This is because 1) the upgrade checklist often lacks concrete actionable recommendations, or 2) for those things which ARE concrete and actionable, lintian and the Salsa CI/CD pipeline are a more cost-effective way for me to discover what I need to do. Granted, I do run the risk of missing something really important that the checklist say I should do. I find the occasional bug report about that a more cost effective way to go about incremental over-time changes than having uploaders re-read the checklist for every package upload. Alas, this ought to be a separate bug report for discussion to be useful, and I'm not sure I feel strongly about this. I may also be lacking context about the history and relevance of this field. /Simon
signature.asc
Description: PGP signature
