Paul Moore wrote: > 2008/11/5 David Ripton <dripton at ripton.net>: >> All timings very approximate: >> >> Time for average user to check out Python sources with bzr: 10 minutes >> >> Time for average user to check out Python sources with git or hg: 1 minute >> >> Time for average user's trivial patch to be reviewed and committed: 1 year >> >> I love DVCS as much as the next guy, but checkout time is so not the >> bottleneck for this use case. > > :-) That's a fair point. But it's not the point I was trying to make, > which is that I'd want whatever DVCS is chosen to make the initial > experience of a casual user / newcomer as easy as possible. Why > discourage them in the first 10 minutes (which, BTW, is much faster > than my experience with bzr last time I tried the Python repo) when we > can make them suffer for a whole year? :-) :-) It does get to the point that the current bottleneck is code review, to the point that people may not submit patches because it seems nearly useless*. And often, when a patch does get reviewed, the diff is obsolete and needs to be redone versus the changed 'current' trunk. I presume that patches as branches would alleviate this last part. So I think easier review should be a prime consideration for infrastructure improvement. If I go to the tracker now and click on a 'patch', I get a sometime easy, usually difficult, and sometimes impossible to read diff. With a wide-screen monitor, I would like a side-by-side display with differences marked, as with Guido's code review tool and other such displays I have seen here and there. *The current quick review and implementation of doc suggestions and patches, on the other hand, has encouraged more submissions from me and, I believe, others.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4