Re: Standards-Version field should be deprecated
On Thu, Sep 08, 2016 at 06:37:33PM +0200, Markus Koschany wrote:
>
> On 08.09.2016 17:39, Russ Allbery wrote:
> >
> > Markus Koschany <apo@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.
Reply to: