[Python-checkins] PEP 374

Barry Warsaw barry at python.org
Sun Jan 25 16:06:09 CET 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 24, 2009, at 6:40 PM, Raymond Hettinger wrote:

> Somewhere near the top of the PEP, I think there should be a  
> discussion of reasons not to change at all.
>
> Everytime we alter the tool chain, it disrupts developers lives.   
> When I was working mainly under Windows, I was at one time the most  
> active contributor by a huge margin.  Then Martin switched the build  
> to VC7 which caused me to go over year before I could make another  
> checkin to CPython.  By then VC8 was out and VC7 was hard to find.   
> It crippled my development.  When we switch tools, *every* developer  
> will have to go through an install, switchover, and learn a new set  
> of commands and checkin practices.  The is a huge PITA and it is  
> almost certain that some developers won't bother.  For many of the  
> developers that do bother, it will cost them a day of their lives  
> getting switched over and working through the learning curve -- that  
> is a day that could have been spent fixing bugs or doing something  
> non-administrative that actually adds value.
>
> Before we boot SVN, I think we need to be damned sure that there  
> will be HUGE offsetting benefits to a DVCS and be pretty sure that  
> our little community is actually ready for a distributed process.
>
> I'm concerned that over time we're moving towards a process that has  
> a lot more admin than we used to.  Changes to PEP 8, rules on  
> indentation, review rules, etc seem to be driven by the least active  
> developers.  Most of the folks who do most of the work rarely ask  
> for more restrictions, more admin, etc.  Even little things like  
> automatically rejecting submissios without whitespace normalization  
> add to the admin burden (time spent doing something that doesn't  
> actually improve lives for end-users).
>
> SVN is relatively simple.  DVCS systems are much more process  
> oriented and aimed at professional developers.  I think we will lose  
> many newbie patches if the person is forced to use an unfamiliar  
> version control system.
>
> I like the quality of the research that you're doing but suspect  
> that the end goal of switching away from SVN may not be worth the  
> disruption and effects on real developers.

I think it's proper and worthwhile to consider development process  
changes that a DVCS would afford or require, and the impact on  
contributions both from current core developers and future ones.   
Let's be sure to examine all aspects though.  I happen to think that a  
dvcs will be only slightly more painful for core developers but that  
pain will be more than offset by providing non-core developers near  
first-class status in the development ecosystem.  Non-core developers  
do not have that now and there are many times the number of potential  
contributors than there are current contributors.

So yes, let's definitely think about the collateral changes that  
moving to a DVCS will entail.  But let's be sure to look at it from  
both sides.

Besides, certain developments like support for the svn wire protocol  
in bzr would make the WFC (we fear change :) argument moot.

Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSXx/4XEjvBPtnXfVAQLDkwP/WI70x1UEjxMsL8YB+3H5ELRMhgaDVbdf
IkodOEb0+NxXalyLfQavZylTV5NFgJ3v0kA76WhfqsNLEc7v7K2O6Ub1UDYL453M
d9Z1+ok+t6U0XqfGbI6t8cMzMoqItIlyrDqpWApKrjnezkpT7x/PgSGzvZNGqrUl
dGXagEqQ2ew=
=SjJn
-----END PGP SIGNATURE-----


More information about the Python-checkins mailing list