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 -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130214152922.64bd5...@anarchist.wooz.org
