On Thu, Sep 08, 2016 at 06:37:33PM +0200, Markus Koschany wrote: > > On 08.09.2016 17:39, Russ Allbery wrote: > > > > Markus Koschany <a...@debian.org> writes: > > > > > > > > I have written a macro to update the Standards-Version field > > > because it > > > is such a boring task. Declaring compliance with the Policy over > > > and > > > over again by updating this field and mentioning it in the > > > d/changelog, > > > doesn't strike me as being a useful task. There are better ways > > > to > > > determine bit rot IMO. > > > > If Lintian says that the Standards-Version field is out of date, I > > then > > open /usr/share/doc/debian-policy/upgrading-checklist.txt.gz, > > scroll down > > to the current value of Standards-Version, and then read backwards > > to the > > top, checking each item against my knowledge of the package to see > > if > > there's anything I need to update. Then I update Standards-Version > > in the > > packaging. > > > > 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. But if you use it as a bookmark for the > > maintainer so that you know what version you last checked the > > package > > against and therefore what bits of the upgrading checklist you need > > to > > check, I think it's pretty helpful. > > I didn't want to imply that we don't check the Policy before updating > the field, just that it is such a repetitive task for team-maintained > Java packages (which can all look quite similar), that you need some > kind of tool to keep your sanity.
Utilizing a tool is not a problem. I see not a problem in programatically updating the field when it is ensured that the S-V is actually archieved. > > Even for non-Java packages I find that > the Standards-Version field is not useful enough to warrant its > inclusion in debian/control. There are other ways how you can remind > yourself to check your package against a new Policy release with > tools > outside the source package. In my opinion it has more to do with how > you > organize yourself and maintain your packages. I would be very interested how you organize that, especially in a team context and then also more lean that updating that field. > > > > > I will say, though, that it's much more useful for individual > > packages > > than it is for large sets of team-maintained packages where you're > > more > > likely to change Policy-related things across all packages at once. Not utilizing a tool: problematic. For me the S-V field is a very useful tool, one example brought by Russ already; in my opinion (backuped with $LASTJOB being in QA) it is doing its job very good to document the revision last checked; IMHO one of the main advantages is that it is maintained _IN_ the source.* You know, QA tends to ask mean questions like: - How do you ensure that your (out-of-source) S-V marker is always in sync and updated? - How do you make sure that your team mates have access to that information? - How do you make sure that 3rd parties from within and outside of Debian have access to that information; A usecas would be when the package is orphaned and someone wants to adopt is? (This would be a additional hurdle in adopting packages as you effectively have to check the whole package for compliance, and not only look out for the delta pieces) The saving of the S-V field is IMHO neglectible compared to the information value it delivers. Just my 2cents. And if you're 100% sure that the checklist has nothing about your packages, just automate it as you did. * An counter example would be the override disparities. As they are maintained (for their reasons) out of the source you see that it almost impossible to keep them sync for a larger set of pacakges.
