Re: Standards-Version field should be deprecated
On Fri, 09 Sep 2016 at 18:11:05 +0200, Markus Koschany wrote:
> On 08.09.2016 21:54, Ralf Treinen wrote:
> > That is certainly not true for orphaned packages with minimal maintenance
> > by the QA team. At least when I do a QA upload I usually don't bump the
> > Standards-Version field, simply because I don't know the package that
> > well.
>
> Right, that's also true for NMUs and this is actually one of my point of
> criticisms. Now the Standards-Versions field doesn't tell you anything
> about the fact whether the package is policy compliant or not.
It tells you whether someone was fairly confident that the package is
policy-compliant. If they weren't, then someone (maybe you, maybe not)
eventually needs to audit what, if anything, needs to be done to bring
the package into compliance, and then do it.
For QA uploads and NMUs, I think Ralf's approach is entirely valid: no,
you don't know whether the package is fully compliant or not, so you
shouldn't assert that it is. Many of these uploads are done to fix a
specific release-critical bug, for example a serious policy violation.
There can be non-serious policy violations too - fixing those is a much
lower priority, and indeed during a freeze it would likely get the package
rejected by the release team as having insufficiently minimal changes.
One of the tasks for someone who adopts an orphaned package is to assess
how much technical debt needs fixing. Non-serious policy violations
are an example of technical debt that is likely to exist.
Coming back to the original topic (network access during build), I think
it's a reasonable point of view to say that downloading files that will
get included in the .deb is a serious violation of Policy §4.9, while
attempting name-resolution for thisdoesntexist.invalid is a violation of
Policy §4.9 but not a serious one.
> For instance you can't claim that
> newer additions to the Policy do not apply to your package despite the
> fact that you haven't bumped the Standards-Version.
No, you can't; but you *can* reasonably claim that the ones you're
ignoring are not serious policy violations (or any of the other
justifications for RC bug severities), and hence not release-critical.
It's sometimes also reasonable to upload a known-buggy package,
perhaps even with RC bugs still unfixed - if a package has two RC bugs,
you know how to fix one, you're unable to fix the other, and the upload
isn't going to be disruptive, then fixing the bug that you *do* know
how to fix is a much better contribution to Debian than not doing it!
> Lintian is a far better tool to verify Policy compliance in my opinion
For the things it can detect, sure, it's a great tool.
For the things it can't detect - either because they require looking at
multiple packages, or because the check would have too many false positives
to be useful, or because they're so subjective that you can't write a
check - it's no substitute for a maintainer paying attention. If you want
to write a lintian check for one of the less rigorous parts of Policy,
like "The extended description should describe what the package does and
how it relates to the rest of the system", I wish you luck in your
artificial intelligence research :-)
S
Reply to: