Re: How does team maintenace of python module works?
On Feb 20, 2013, at 10:14 PM, Thomas Goirand wrote:
>If sticking to our old habits is not the only valid point, that there
>are real technical reasons why we should never be using a git tag
>as the key for an upstream release, or if you think they might be
>real difference between the "git archive" generated xz file and the
>github/gitorious/etc. tag based tar.gz, please explain.
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. Also, you must ensure that everything necessary to
build and deploy the package is either included in the repository or is easily
generated by something that is in the repository. I bet that's going to cover
a minority of projects still. At least with a tarball, you know you have a
releasable "thing" that upstream has blessed (which could still have problems,
sure, but that's different than not being sure.)
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.).
It's also not true that tarballs can't be signed, they are all the time on
PyPI. Maybe not as often as we'd like, but still.
Cheers,
-Barry
Reply to: