Bug#837650: RFS: cf-python/1.3.1-1 [ITP]

[Ben Finney <bignose@debian.org>]

Howdy Klaus,

Thank you for working on this package.

Here are some comments I have for improving the packaging work:

* When removing code, just remove it. You are tracking the work in a
VCS, there is generally no reason to commit changes that comments out
lines of code.

  So, in ‘debian/patches/’, the
  ‘0001-Remove-check-for-python-version.patch’ and
  ‘0003-Patch-sphinx-config-to-avoid-network-access-and-add-.patch’
  changes (actually, the Git commits you used to generate those files)
  should not comment any code lines but instead remove those lines.

* Wow, hard-coding a man page in a Python string literal is a fragile
way to store the document.

  Have you discussed with upstream the feasibility of moving those to
  their own first-class source documents, and reading from there at run
  time? Python ‘pkg_resources’ has functionality to locate and read a
  file installed as part of the package.

* In ‘debian/copyright’, please don't obfuscate the email addresses of
copyright holders. It's a needless barrier to getting useable contact
information for legal purposes.

* Is there a good reason to omit the “Upstream-Maintainer” field in the
header of the ‘debian-copyright’ file? There seems to be an obvious
single maintainer contact for this code base.

* The ‘cf/etc/udunits/’ tree looks like a bundled third-party work. Per
Debian Policy §4.13, should this work not be packaged separately and
listed as a dependency?

* Can you include a ‘debian/README.source’ explaining how you collated
the various parts and changes you've made from the upstream source?

  In particular, the procedure for making ‘debian/*.1’ and
  ‘debian/test_file.nc’ should be described, along with rationales that
  can be later re-visited if upstream policies change.

-- 
 \
  `\
_o__) Ben Finney <bignose@debian.org>