Re: How does team maintenace of python module works?

[Ansgar Burchardt <ansgar@debian.org>]

On 02/15/2013 01:39, Tristan Seligmann wrote:
> I don't think forming a separate team would be silly at all. If you
> have a group of people working on Python packages in Git, and a
> separate group of people working on Python packages in SVN, what use
> is there in pretending that they're the same group when they're
> effectively separate anyway? Of course, there may be some people who
> are interested in working on both teams, but there's nothing stopping
> you being a member of both teams if you choose to do so.

I think having a separate team just to use another VCS is not good. It
will probably split contibutors between the different teams; having to
follow different polices (for the two teams) for similar packages would
at least annoy me.

pkg-perl had to make similar decisions in the past: all packages were
maintained in Subversion, but some people wanted to try out Git. This
was accepted even though some people said they might not care about the
Git packages, but it worked fairly well. (Eventually we switched to only
Git.)

Maybe a similar policy would work for the Python team as well? At least
if some regular contributors would have to be interested in using Git.

(I don't care too much as I only maintain a single package in the Python
modules team.)

> When you say "I want to maintain my packages in Git, in the team",
> there are really only two possible implications that I can see: 1) "I
> want everyone in the team to comply with this way of doing things,
> even though they don't want to do so", and 2) "I want to do things my
> own way separate from the rest of the team, but claim to be working as
> part of the team". Now, written that way, perhaps you can see why this
> produces a negative reaction from some existing team members, even if
> you did not mean it in that way?

There's more to maintaining packages in a team than having a common VCS.
For me it's fairly important to have people that you can ask questions,
one has a common policy for packages, ...

Ansgar