Re: How does team maintenace of python module works?
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
Reply to: