On Fri, 13 Oct 2017, Andreas Tille wrote: > 1. proceed as I suggested here: > https://lists.debian.org/debian-science/2017/10/msg00001.html >... > Is there anybody who is no happy about this?
sorry to be the pain, I am ... And first of all -- thanks for taking care about pandas! I would disagree on the complete disabling of the tests. Selective annotation of failed tests at least allows maintainer's judgement on either any particular failure of critical importance. Disabling ALL tests would let a completely broken package into the Debian for that architecture (not to mention that we did have failures on big-endians signal generic problems in the code, which just weren't triggered on x86s)... then why to have it there in that architecture at all? If ftp masters and porters insist on "better to have a broken one than none", I would argue that unlike typical software, where bugs are usually "obvious" to the user (things just fail), in scientific/data oriented software bugs are more inconspicuous -- you just place data in and get some garbage out possibly without realizing it. In summary my 1c: I am ok with RM for those archs (again), or partial disabling of the tests, but not ok with overall disabling of the test suite > 2. Upload after migrating the package to Debian Science as > we previously agreed upon. do you mean migrating of a Vcs? -- Yaroslav O. Halchenko Center for Open Neuroscience http://centerforopenneuroscience.org Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755 Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419 WWW: http://www.linkedin.com/in/yarik
