[Python-Dev] Encouraging developers

Barry Warsaw barry at python.org
Mon Mar 5 20:11:09 CET 2007

Hash: SHA1

On Mar 5, 2007, at 1:58 PM, skip at pobox.com wrote:

>     amk> Tangentially related:
>     amk> At PyCon, there was general agreement that exposing a read- 
> only
>     amk> Bazaar/Mercurial/git/whatever version of the repository  
> wouldn't be
>     amk> too much effort, and might make things easier for external  
> people
>     amk> developing patches.
> I'm not much of a version control wonk.  How would these help?   
> Can't the
> folks who need such stuff do some sort of anonymous svn checkout?

Part of the problem is that you want to be able to publish your  
changes in a form that's much more conducive to collaboration than  
diff files.  An anonymous svn checkout can't effectively be published  
or shared and you don't want to hand out writable access to svn to  

With a dvcs like Bazaar/Mercurial, et all, control of writable  
branches is totally decentralized.  Yes, there's always the blessed  
central branch(es) coming from python.org, but it's very easy for Joe  
Shmoe to create their own writable branches, make their changes,  
publish them as full-fledged branches, etc.

I see adopting a dvcs as beneficial in a number of ways.  First, it  
allows people to participate even without write access, as almost  
first class citizens.  About the only thing they can't do is commit  
back to the blessed branches, but that doesn't stop them from sharing  
their branches exactly the way we do.  Also, it gives core developers  
a better way to review and test other people's branches because you  
can just pull their branch and start using it.  In fact you can even  
branch their branch and publish your own version as a "review  
branch".  Depending on the specific dvcs chosen, there are lots of  
ways to share branches that are much more "live" than diff files.

Finally, because branching is so cheap (even cheaper than with svn),  
a dvcs is great for us even if it doesn't get us more developers.   
It's so much nicer to have a vcs that understands merges natively,  
and can track them across branches, so it lets us create cheap little  
branches for little features.  For example, I'm sitting on a checkout  
of the implementation for a new PEP we worked on at PyCon.  I could  
create an svn branch for this work, but that's fairly heavyweight, / 
and/ it requires me to have access to the server (which I didn't have  
on the train from PyCon, and I screwed up my checkout because of  
that).  With a dvcs, I could publish my changes in any number of ways  
and still just have this one little branch for this one little feature.

Hope that makes sense!  I haven't used a real dvcs for very long, but  
I'm starting to see the fundamental improvements to the development  
process that it makes possible.

- -Barry

Version: GnuPG v1.4.5 (Darwin)


More information about the Python-Dev mailing list