On Feb 20, 2013, at 10:53 PM, Thomas Goirand wrote: >> You better be darn sure that upstream has excellent QA then, and that you >> know for sure that a tag is correctly assigned to a buildable, tested, QA >> passed snapshot of the project. > >In what way the QA is different because it's a tag instead of a tarball ? >I don't understand your reasoning. In both cases, you must make sure >that what you are packaging is buildable, tested, QA, etc.
Right, but it's a matter of context. If you have a release on PyPI, you know it's been blessed. You don't need any more context. For a git tag, I have to know what is the blessed repo url, how the tagging scheme works, what the latest releasable snapshot is tagged, etc. I need much more context to know what is "a release" (even though upstream might find them quaint, Debian still does releases of packages, i.e. uploads). What if the repo url changes? What if they start using a different tagging scheme? What if someone accidentally assigned a release tag to a non-releasable revision? That might not be so important for someone who has intimate and ongoing knowledge of package maintenance, but it's really important for team maintained packages where I might have to fix a bug or grab a new upstream for a package you primarily maintain. >> Look at it from a Debian Python packager's point of view. If it's on PyPI, >> then there's no guessing. If it's a git tag in some repo, you have to carry >> along much more implicit context (e.g. the workflow of the upstream project, >> do I have the right repo, etc.). > >With many PiPY projects, I can see that the generated tarball are the >exact same thing as what's tagged in the Git repository. Often, the >release process is automated so the tag and the tarball are released >at once. This has been the case, for example, for: > >- python-pecan (https://github.com/dreamhost/pecan) >- python-json-patch (https://github.com/stefankoegl/python-json-patch) >- python-json-pointer (https://github.com/stefankoegl/python-json-pointer) >- python-tablib (https://github.com/kennethreitz/tablib) >- cliff-tablib (https://github.com/dreamhost/cliff-tablib) >- python-warlock (https://github.com/bcwaldon/warlock) That's great, but I bet it's a minority of projects on PyPI. >(non exhaustive list... and not including all of Openstack!) > >I don't understand your reasoning, they are all using setuptools, and >are perfectly buildable, installable, etc. Did I miss something? The point is, I might not want or have the time to know all the intimate details about how upstream does its project management. It will certainly be an impediment to collective, team maintenance. Cheers, -Barry -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130220100912.650cf...@anarchist.wooz.org