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 <paul...@debian.org> : :' : Proud Debian Developer `. `'` 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `- http://people.debian.org/~paultag
signature.asc
Description: Digital signature
