Re: Standards-Version field should be deprecated
Markus Koschany writes ("Standards-Version field should be deprecated"):
> > The field is useful because it shows the most recent version of the
> > policy that the package has been checked against. It is useful to
> > occasionally update packages to the latest standards, and the
> > Standards-Version field can be used to spot how long it has been for
> > this particular package. Policy comes with handy summaries of the
> > changes, for use when checking/updating a package.
>
> I agree with Emmanuel and I also think that the Standards-Version
> field should be deprecated. People expect that a package complies
> with the most recent Policy and latest standards when it is updated.
"People" ? Which people ? I certainly don't expect any newly-updated
package to necessarily have been updated for any policy changes in the
meantime.
> If a package doesn't comply with Policy, people start to file bug
> reports
On the contrary, many policy changes are either minor (in which case
they are not likely to cause bug reports) or have a proper transition
plan (which anticipates that packages will not necessarily be updated
right away).
And not every policy violation is detected easily (or detected, in
practice, by tools like lintian). This is particularly true when the
change is one which is expected to be made `eventually'.
In a big project like Debian, we can only make progress by reducing
the need for changes to be made synchronously.
> I'd rather prefer not having to update this field every time. If I want
> to learn more about the work that has been done, Git commits or the
> changelog will be far more informative.
The changelog will not tell me in a consistent, machine-readable way,
what policy updates were last reviewed with the package in mind.
> > You could do your checks, and update the field, much more rarely, if
> > you wanted. There is nothing inherently wrong with having a
> > Standards-Version which refers to a previous version of policy.
>
> But wouldn't that defeat the purpose of the Standards-Version field, if
> I don't update it even if the package complies with the most recent
> Policy version?
You misunderstand. I mean that you could wait with updating your
packages to the latest policy.
> > Is that suggestion any use ?
>
> 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.
Editing the Standards-Version field is surely a small task, compared
to the work of checking the policy updates against the package. If
it's not a small task, it can be amortised by doing the policy updates
less freqently.
Ian.
--
Ian Jackson <ijackson@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.
Reply to: