Re: How does team maintenace of python module works?
On 02/20/2013 11:09 PM, Barry Warsaw wrote:
> 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?
For the packages which I worked on, there was always a Git URL in PiPY,
and I didn't have any of the issues you're talking about above. I'm not
saying it can ever happen, but only that I see no difference with making
a tarball: in both cases, you can do mistakes, can't find the correct
URL and have it changed, etc. I haven't yet met a "context" problem like
you describe above, but truth, I have seen multiple tagging scheme, the
most reoccurring one being to add a "v" in front of the version number
(which is easily worked around in the gbp.conf).
> 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.
Team members can read debian/copyright, where you have the Source: field.
>> 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.
Like you, I have no stats available, so I can't tell. But for me, that
was a vast
majority of the packages I worked on.
Anyway, I'm not asking anyone to follow my workflow, I was merely explaining
what I've been doing, and what I was very happy with. It might indeed only
work for a group of packages only.
Do you guys think we should only have *one type* of workflow? I wouldn't
mind switching to some different way of doing things if the team finds it
relevant, and if it is more easy and unified across all packages. If so,
please tell how you would like to work. We would loose most of the cool
features I was used to, but so be it...
Cheers,
Thomas
Reply to: