On Fri, Sep 20, 2013 at 10:46:14AM -0700, Thomas Kluyver wrote: > I try to get involved with Debian packaging. But, to be blunt, it is a slow, Debian works at a slower pace. We make sound technical decisions, over all. It's annoying to people who want results and want them now, but it's something we all have to deal with. > frustrating process, and the effort I put in feels utterly disproportionate to > the results. We are not going to get many Python programmers involved with the > packaging process as it stands. Take the most recent two packages I have worked > on: > > - python3-sympy: The package is sitting in the team SVN, waiting for someone to > review or upload it. I last touched it two months ago to package a new upstream > release. > - python-xlrd: My changes were rejected, although the package was extremely out > of date, because the package had an individual 'Maintainer' who hadn't been > seen for three years. It took another four months (a long time in developer > terms) before the wheels turned and someone actually got an up to date version > packaged. > > I wish I could say this is atypical. But from my limited experience of DPMT, a > slow, tricky process is the norm. There are procedural traps (e.g. to make a > package you must first file a bug by e-mail, then mark your new package as > closing the bug), social traps (annoying a 'maintainer' overprotective of what > is ultimately little bit of metadata to turn a Python package into a Debian > package), and you may simply fail to catch the interest of a Debian > developer--as I seem to have failed with python3-sympy--in which case you're > out of luck. > > I don't wish to criticise without making suggestions as to how this could be > improved: > > - Write a 'how to keep your distro packager happy' guide for developers. E.g. > many Python developers don't know that distros will move data files to /usr/ > share, but when you do know, it's easy to write code so that the patch to > achieve this is trivial. > > - Have a simple way for developers to submit packaging information without > having to join Debian teams, file ITP bugs, and all that cruft. Technically, > Debian mentors is already something like that, but maintainers mostly ignore > it. Which brings me to: > > - Put the emphasis on keeping packages up to date and simple, not on Sorry, no :) It's not about keeping the libraries up to date, it's about keeping the applications up to date. If a library breaks API because the maintainer wanted another toy rewrite, we're not going to upload it and break half the archive. That's silly. Hell, we shouldn't even introduce a module unless it has an app using it. We focus on *user stability*, not bleeding edge, yes, even in Unstable. Perhaps we can consider exerpimental uploads? > 'maintainer rights'. Packaging should not be an art form. If someone uploads a > newer version to Debian mentors (or another submission system), the maintainer > should get an e-mail. If a package is out of date for more than a few days > without a clear reason, people should be prodding the maintainer to ask what's > up. If a maintainer is regularly unresponsive, drop the package to team > maintainership so that other people can work on it. Put another way, focus on > what is best for Debian and for the upstream project being packaged, not what > the person who has appointed themself 'maintainer' of that package wants. While I generally agree, most of the time the maintainer of a package knows the details better than anyone else in the project, and can make better techincal decisions. > - Make it really, really easy to accept changes to packaging. One of the > reasons for the meteoric rise of Github is that when someone submits a change > that clearly improves things, the repository owner literally just has to click > a big green button to accept that. I don't mean DPMT should use Github, but, > for instance, if upstream makes a bugfix release 1.4.3, and Debian has 1.4.2, > it should be as near as possible one click/one command to grab the new version, > update the changelog, commit the change, upload the package, and whatever else > needs doing. (check the license, review the diff for changes that may cause issues or are unsafe, ensure it doesn't break API, ....) > I know this won't go down well with everyone here. I contend that if the > situation continues as is, Debian packaging will be seen as ever more > irrelevant by Python developers. Already, the default assumption is that distro We care more about users than developers. Python developers can use virtualenv and pip on Debian like any other Python development env. > packages will be out of date. The scientific Python community is unhappy with > pip & PyPI, but is looking to yet more packaging tools, such as conda, to > address this (despite Yaroslav Halchenko's excellent work with NeuroDebian). > > Thomas -- .''`. Paul Tagliamonte <paultag@debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
Attachment:
signature.asc
Description: Digital signature