Re: How does team maintenace of python module works?
Tristan Seligmann wrote:
> I don't think forming a separate team would be silly at all.
I agree with absolutely all of what Ansgar wrote about this.
What is important is people doing the work, and being able to find
advices. In other words: team work.
> 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".
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:
3) Upstream uses Git, and I have already lots of git things inside my
package and workflow (I already explained, I have no choice at all),
plus I know there's others willing to use Git, and not having the
possibility to do team work with them because of some member resisting
would be a bit silly.
It would be really stupid to only want to "claim" to be working as part
of the team, that's not at all what I want to do. I'd like to be able to
help when I can, and receive help when I need, which is the point of a team.
I don't want to impose my workflow on anyone, you could continue to use
your current workflow if you like for the existing packages. I'm not at
all asking for a full switch. But the opposite isn't true, some members
of the team would like to impose the SVN workflow on me... or I should
just leave and maintain these packages on my own (or inside another
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.
Tristan Seligmann wrote:
> 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?
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.
I have absolutely no intention of disturbing the current workflow of the
team, I just want to have the possibility to do the work for these
packages where Git is convenient for me. I am ok to use SVN for the
*other* packages which I maintain / contribute already, but for some it
just wouldn't work. Note that I already did use SVN and pushed some
commits. And wish to add some more packages to the SVN (I just didn't
find out how yet... help would be appreciated so that I can push
python-testtools and python-fixtures!).
I do understand why some would like to keep a single VCS though. But
maybe it could be a more relaxed rule not written into a stone, where
some exceptions would be allowed at least. Recognizing that SVN doesn't
work in some cases (which I already explained above and in other posts)
would be a good step on the right direction IMHO.
Cheers,
Thomas Goirand (zigo)
P.S: I'm truly sorry for breaking the thread, I was reading through the
archive, but now I'm registered to the list. This will not happen again.
Reply to: