Re: How does team maintenace of python module works?
On Feb 15, 2013, at 01:25 AM, Thomas Goirand wrote:
>All this is very far from being *forbidden* to send packages to the
>python module team using Git and maintain them this way.
Of the three main dvcs's, I personally dislike git the most, but I'm resigned
to the fact that it's essentially won the dvcs wars. I would accept using it
officially for the team packages because it would make disconnected use
possible, and depending on the organization of packages and branches, could
introduce a much nicer workflow for updating packages, e.g. pull requests,
reviews, cherry picking, etc.
Having said that, I'm strongly against having team packages live in multiple
different vcses. Choice is good, and everyone has the choice to use whatever
vcs and hosting they want for their own packages, outside of the team. But
there is value in team consistency and I'd be loathe to give that up.
When working with any team, and especially of volunteers, you simply will not
get everything you want. Compromise is the only workable solution, especially
when there is no BDFL. I think it's important to accept team decisions and
not waste valuable time arguing about them. Trust me, I've lost my fair share
of arguments in upstream Python - it stings, but life is short :).
That's not to say such discussions can never happen, and in a loose
organization such as this team's it may be difficult to divine what consensus
actually is. I look at the switch to dh_python2 as an example. Not everyone
here agreed with that decision, many still do not. But Piotr and others put
in a considerable amount of hard work to make it a very viable, high quality
option. Rough consensus and working code means that I think you'd find a
majority of team members actively using it, happy with it, pleased at its
advantages over the other options, and experienced enough with it to recommend
it to others.
Switching to git or any other dvcs isn't going to happen just by asking for
it. Someone would have to step up and actually do a lot of hard work to make
it happen. Look at all the work done by upstream Python to get it onto
Mercurial. It was *a lot* of work, making sure the conversions were high
fidelity, that documentation was good, that the workflow made sense for the
use cases, that newbies to distributed vcs were guided through the concepts
and common practices, etc. etc. The folks who cared deeply about Mercurial
made a long term commitment to ensuring a smooth transition. That was an
argument that I lost, but I have to hand it to the winning side - minor rough
edges and initial problems aside, it's a system that is working very well for
the community today.
So if some percentage of team members really really want to switch to git,
step up and do enough of the work on spec (i.e. no guarantees) so that you
have something that is convincing. It doesn't have to have all the rough
edges polished off, but I do think it needs to very clearly demonstrate enough
of a win over svn for the team (or a majority of them) that it would be a good
switch. Please also do be respectful of the concerns of the detractors and
opponents, and try to address them as best you can.
Again, I say this as someone who doesn't mind svn and would accept git, but
feels very strongly that there should be one team vcs and repo.
Cheers,
-Barry
Reply to: