Emmanuel Bourg writes ("Re: Standards-Version field should be deprecated"): > Le 8/09/2016 à 17:39, Russ Allbery a écrit : > > If you're just automatically updating it without ever looking at how > > Policy has changed, then yes, it's not useful. And I don't think it's > > very useful to publish. > > That's indeed what happens most of the time. The set of packages > maintained by the Java Team (~900) is mostly comprised of mere libraries > never affected by policy changes, and updating the Standards-Version > field over and over again for these packages becomes frustrating.
I don't think you can be sure that "never" is right, of course. But, accepting your view that policy changes very rarely require changes to these packages, I still don't understand why the analysis, and proposal, I made last night, is not appropriate: Any approach which does away with the source-package-specific Standards-Version field needs to keep the same information somewhere else. [When a policy update has been reviewed with a big collection of packages in mind, and no changes are required], then it is surely a simple matter to update the out-of-source-package update-tracking information to say "we have checked that S-V update X->Y does not affect us". The actual S-V in the actual source packages does not need to be updated right away. The cost of not updating it is that someone else who isn't in the team and doesn't know about the out-of-source-package tracking info might redo some of the policy review, but that's not normally very onerous. The source packages' S-V fields can be updated when it's convenient. > I understand others may find Standards-Version useful as a bookmark for > checking changes to be made (although from my point of view using the > date in the changelog as a starting point and relying on the Lintian > checks is equally good). But I think we should be allowed to not use > this tool. The source package is the interface for your team to collaborate with the rest of Debian. I think there is value in providing this information in a way that everyone knows how to consume. Ian. -- Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own. If I emailed you from an address @fyvzl.net or @evade.org.uk, that is a private address which bypasses my fierce spamfilter.