On 17/09/15 at 12:43 +0200, Grigori Fursin wrote: > Package: sponsorship-requests > Severity: wishlist > > Dear mentors, > > I am looking for a sponsor for my package "ck" > > * Package name : ck > Version : 1.6.2 > Upstream Author : Grigori Fursin <grigori.fur...@ctuning.org> > * URL : http://github.com/ctuning/ck > * License : BSD-3-clause > Section : python
Hi, Quick (and probably incomplete) review: Must be fixed: - Given that this software is not specific to Debian, and publishes releases on its homepage, this should not be a native package. instead, its version should be of the form 1.6.2-1, 1.6.2-2, so that the Debian revision (the part after the '-') can be changed when packaging changes are made, without making a new upstream release. - I'm not familiar with python packaging, but when building this package, I only get a python2 package (and no python3 package). There's something wrong here. I wonder if it's related to the fact that the version of python-stdeb that you seem to be using (according to the headers in say debian/rules) is very old. Given that Debian packages are uploaded targetting Debian 'unstable', it's better to do Debian development in unstable or testing (possibly in a chroot). Should probably be fixed: - If I understand ck correctly, it's more an application than a library: users are not really exposed to the fact that it's written in python, and the python lib is not supposed to be used by third parties (it can be used in ipython, but the target is not really to build a third party application on top of it). If that's correct, then it should not be packaged like a python library, but more like an application (that happens to be written in python). - there's another problem: namespace pollution in few-characters commands. It's usually a bad practice to name something (that is not a historical unix tool) with 1 or 2 letters only. Could be fixed: - The description is a bit too long by Debian standards. Lucas
