[Python-checkins] PEP 374

[Guido van Rossum]

On Sat, Jan 24, 2009 at 3:40 PM, Raymond Hettinger <python at rcn.com> wrote:
> Somewhere near the top of the PEP, I think there should be a discussion of
> reasons not to change at all.

The possibility of rejection is an implicit part of every PEP. PEP 374
contains a long rationale section. If you disagree, fine, but I don't
think you need to criticize the PEP's form.

> 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.

You forget that many developers are *already* using a DVCS, either for
other projects, or using some kind of bridge. Otherwise the PEP
wouldn't have gotten so much traction already!

> The is a
> huge PITA and it is almost certain that some developers won't bother.

The same can be said for any change, including Python 3000 (or 2.6 for
that matter). You seem to be seeing it as exclusively a PITA with no
payback. That seems rather short-sighted. DVCS can have huge benefits
for cooperative development. (Maybe the PEP could be extended with
some examples? I believe Mozilla uses Mercurial for example. And you
know the Linux kernel uses Git.)

> 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.

Oh come on. I installed Mercurial (from source!) on two different
machines and started being productive in half an hour (including the
research to find where to download it, and how to configure the
username). Learning all the ins and outs will take longer, for sure --
but you get the time back by having a much better way for managing
tentative patches or multiple branches, for example.

> 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.

"Our little community"? I see Python as one of the major open source
projects, with an influence way beyond just the Python language users.
There's probably only a dozen larger projects.

> 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 submissions without
> whitespace normalization add to the admin burden (time spent doing something
> that doesn't actually improve lives for end-users).

(Some) more admin is the price we pay for our success. I recall the
days when there was *no* admin needed and I could do everything
myself. Frankly, I do *not* want to go back there.

> SVN is relatively simple.  DVCS systems are much more process oriented and
> aimed at professional developers.

I think you have this backwards. Most professionals (people coding for
money in a company) are using more centralized VCSes (often because
their management wants to know what the engineers are doing). To the
contrary, it's the open source hobbyists who've taken up DVCSes,
because they facilitate the *distributed* (get it? :-) way of working
in such project.s

> I think we will lose many newbie patches
> if the person is forced to use an unfamiliar version control system.

Newbies by definition don't use VCSes; they patch the source code of a
two-year-old download in place and send us a new file, marked up with
comments indicating where they made changes (and forgetting some other
file they also patched earlier). Or if we're lucky they saved the
original file and send us a diff -- in a format we cannot read.

I was going to say that the one thing that's easier with svn is that
it comes pre-installed on most Linuxes, while hg and bzr don't; but
remember that 70% or moreof our users are on Windows -- the great
equalizer, where they have to install whatever [D]VCS we tell them to
use anyways.

> 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.
>
> My two cents,

Sorry, most of that sounds like FUD to me.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)