Hi Ben, a few comments from a first look
* what is the advantage of migrating away from nose? I don't care one way or another, but I'd like to see advantages for this amount of code churn, particularly code churn that is buggy. * if you are going to commit intermediate entries in d/changelog, please ensure they are correctly formatted; dch fails with this changelog. They are often only added in immediately before the final release, but that's not always great when more than one person is working on the package. * the test suite fails when run from setup.py and from d/rules at build time (there are two classes of failure here) * the autopkgtest tests would also fail * whitespace-only diffs are exceedingly annoying as they prevent any merging/rebasing/cherrypicking operations across them. The codebase might be full of non-pep8-compliant spacing but I've never thought it was worth breaking everyone else's local branches to change it unless was changing that part of a file already. Build-time tooling isn't user facing and so I'd be prepared to consider this for stretch, but that the branch doesn't land cleanly the first time makes me wonder if it's too invasive to be viable for stretch at this stage of the release cycle. cheers Stuart -- Stuart Prescott http://www.nanonanonano.net/ [email protected] Debian Developer http://www.debian.org/ [email protected] GPG fingerprint 90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7 -- http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-python-debian-maint
