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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
