Martin v. Löwis wrote: >> That said, there are always strong arguments in >> favour of the distributed model encouraging and fostering community >> dev participation > > Just for the record: Python's development model *is* distributed, > and has been for a long time. We don't all work in the same office, > or even in the same time zone. We rarely meet face-to-face (although > the recent hiring wave at Google has changed some of that - but > then, there also was ZC, BeOpen, CNRI before that).
Without wanting to have a discussion about the semantics of what it is to be "distributed", what it seems (to me at least) that you're saying is that the python community itself is distributed. That's doesn't mean that your versioning is distributed. The model you describe is very much centralised, where many people submit patches to a central source repository - otherwise SVN would already be a distributed RCS. The model you describe isn't quite the distributed method of operation where you have many repos that can be pulled and merged together - I won't attempt to rehash Linus' Google Tech Talk, See here : http://www.youtube.com/watch?v=4XpnKHJAok8) of the distributed model he uses, if only because so many python-dev members work for Google now ;-) > I really don't think that the non-D aspect of the VCS is a burden to > contribution. Many patches are contributed from the released source, > i.e. without bothering to check out anything, or even from the binary > installation, i.e. without bothering to download and build the source. No certainly not, I'm not by any means suggesting that the current way of handling revision control is having a negative impact. I also don't intend to evangelize. But there are arguments to be put that a DRCS can promote more involvement by allowing people to checkout and work on their own copy of the tree. This way they can cut code in a controlled environment using commits, reverts, version diffs etc without the necessity of setting up their own svn repo to commit to, or needing a sandbox in the python repo. > People who don't use subversion to get themselves the latest sources to > contribute against won't start doing so if some other system was > used (they are less likely to if they have to learn it first). Generally I agree with you, for bugfixing etc it's unlikely that if they didn't participate before, an RCS change won't suddenly change their mind. That said, I think the number of people that know SVN beyond update and commit are few and far between as well - I'd suggest the real distinctions between distributed and non-distributed apps at this level are virtually nil for such simple use cases. > Instead, requiring contributors to use the Python VCS would place > a burden, as does the requirement that we already have to contribute > diff files, rather than an edited version of the original file. Also, > having to register with the bugtracker is a burden for some > contributors. The learning curve is definitely one of the key impediments to any change to the RCS used. The last thing you want to do is cause unreasonable difficulty for the people who are already contributing to the project; it's not much use to have encouraged 20 new developers only to lose 20 existing ones. But it's worth considering the balance between costs and benefits, for example being able to branch virtually instantly without modifying the python.org repository is a big win I'd think. Being able to more easily modularise the maintenance and responsibility load for the source tree is another win, especially as the size of the tree grows and new efforts such as Py3k begin. With respect to bugtracking, well that's probably a separate issue really. However if there's a way to integrate a bugtracker with my RCS in a way that lets me create and resolve tickets when I'm offline, someone please tell me :-) Cheers Dave _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
