Nicolas Dandrimont <ol...@debian.org> writes: > I am strongly of the opinion that the DPMT should be a team, not just > a SVN repository with random packages and a mailing-list where people > shout at each other when they dare touch those packages.
Thanks for expressing these constructive ideas. > This continuing atmosphere of fear, and the constant bad faith > accusations, make it really hard to work in the team efficiently […] I acknowledge your reticence at mentioning VCS. That said, though: I really think this culture of fear and territorialism is exacerbated by using Subversion as the VCS, instead of a VCS with proper merge support. The great difficulty Subversion presents in the task of merging someone's changes leads to the avoidance of casual branching, whereas any modern DVCS positively encourages casual branching and invitations to merge. Using a VCS with such poor merging support means the only feasible way to put work in the VCS is to put it directly on the trunk; which in turn leads to either frustration with discussing a change that isn't in the VCS where everyone can see it, or exasperation when a set of changes goes into the trunk with little discussion. On the other hand, a DVCS with proper merge support makes for a community of developers much more welcoming of “just get in there and try it”. The effort of working on a branch does not entail a great deal of effort at the end of the journey: it is easily examined by anyone else and merged into trunk after discussing whether it's valuable. So I think migrating to a DVCS – any of Bazaar, Git, Mercurial – would make it much easier to think about a problem by committing changes early to a VCS branch. At the same time, it would mean having that branch immediately available in the team's VCS for comparison — without disrupting what's happening on the trunk branch. > (I'm afraid to put this in here, as it's mostly a matter of taste, but) > - Migration to a more modern VCS. So while I agree that *which* DVCS to use is in part a matter of taste, there is great benefit to the development community as a whole to be had from switching away from Subversion to *some* modern popular DVCS. None of that reduces the effort involved in such a migration, nor helps to choose between the competing DVCSes (all three of the main ones I mentioned have good merge support, so this isn't a criterion to choose between them). But it hopefully makes clear how the community issues discussed in this thread are connected with the choice of workflow tools, and thereby increases the perceived benefit of such a change compared to the cost of remaining with an inferior tool. -- \ “Intellectual property is to the 21st century what the slave | `\ trade was to the 16th.” —David Mertz | _o__) | Ben Finney -- 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/854n4qdtqm....@benfinney.id.au