Re: How does team maintenace of python module works?
On Sat, Feb 16, 2013 at 11:10 AM, Thomas Goirand <zigo@debian.org> wrote:
> Oh! Are you *sure* this is what you think of me? It's quite shocking to
> read that. It's not that at all. It's:
It's what I think are the practical consequences of what you propose.
> team)! Well, if I'm not allowed to use Git within the team, that's
> exactly what is going to happen for these packages. And I think it's a
> shame.
But this is exactly the point; if team members are doing work in SVN,
then your packages in Git are not benefitting from this work.
Conversely, if you are doing work on the packages in Git, other
packages in SVN are not benefitting. Of course, there's nothing that
prevents you to ask for advice / commentary / whatever on the
debian-python mailing list regardless of whether you are discussing a
package maintained in DPMT/PAPT or not; you can also follow the team
guidelines in maintaining these packages if you so choose.
> If others see it that way, then they are missing the main point, which
> is I have absolutely no choice of the VCS, given how much my packaging
> work is intertwined with what upstream is using. Let me enumerate again:
> signed pgp git tags (remember: I live in China, and China played with
> man in the middle attacks with Github...), cherry-pick of patches, "git
> merge -X theirs <tag-name>" for new release tags, "git ls-files" to
> generate the MANIFEST.in, "git archive" to generate the orig.tar.xz, my
> auto-builder script which is fully git based, using the upstream
> repository for the master branch, etc. SVN or git-svn will not allow me
> to do this.
It certainly sounds like maintaining the packages in Git is a
reasonable choice here, and I don't have any reason to second-guess
your choices as maintainer; I just don't see how you hope to benefit
from maintaining the packages "in the team" when you aren't actually
making use of the team infrastructure that provides these benefits.
--
mithrandi, i Ainil en-Balandor, a faer Ambar
Reply to: