BDFL decision of Python's DVCS

[Stephen J. Turnbull]

Eduardo O. Padoan writes:

 > While I think that his choice wasn't completely unrasonable, I
 > obviously dont agree with must of his impressions about Bzr/Hg; Easier
 > to SVN users? I would like to know why.

I don't know what Guido saw in his private mail and Twitter feedback,
but what I saw on Python-Dev and as one of the PEP authors was that
pretty much everybody who has tried bzr has been bitten by a format
incompatibility, or knows somebody who was.  The sample repo at
code.python.org has already been upgraded once, requiring all users to
upgrade, and it's less than 6 months old!  Now, as it turns out all of
the people testing bzr already had sufficiently high versions, but
that worked *against* bzr because (a) Debian stable doesn't have it
(Lenny's at bzr 1.5!!), and (b) people who work in paranoid corporate
environments don't want to think about what they'd need to do to get
upgraded, and being told by free-lancers "oh, it was painless" doesn't
help ("oy, you don't know what *pain* is, do you!?")

Nor is the issue going to go away soon, lots of work is being done
under Bazaar's hood.  You can say "it's no big deal," and I would
agree ... but the Python devs don't even want to think about it.
Mercurial, like Subversion, doesn't ask them to.

Bzr prides itself on adapting to *your* workflow -- but it requires a
plethora of switches to do so.  The Python devs don't care about disk
space, they *do* want to distinguish the concepts of record (aka
commit) and push, they've all bought in to the "every working tree is
a branch is a repository" model.  Lightweight checkouts, etc, are just
cruft and complexity.  The question they asked is "if I need to do X
as in the current SVN-based workflow, what are the commands I issue?"
I don't agree that, as presented in the PEP, the hg-based workflow
mapped better to SVN than does bzr, but some people apparently thought
so.  I suspect *latent* complexity has something to do with that.

Bzr seems to take pride in adopting cute terminology.  "patch stacks"
in git vs. "patch queues" in Mercurial vs. "looms" in Bazaar.  "Stacks
and queues I get, but looms?"  WTF?  Warp and woof?  "Do I need to
grok the analogy to work with this stuff?  Sounds complex."  That was
a really deep-running reaction.  As git proponent, I had placed some
comments in the usage scenarios explaining what was happening, and got
a *lot* of pushback.  The basic workflow should involve *no* thought
*at all*, that was a common position.  Even comments on theory of
operation are a bad sign.  The closer the workflow scenarios
approximated "no change in thinking" (== no thought at all in the
ideal), the better.  People didn't even care to find out if it *was*
complex, the mere scent of complexity put them off.

Finally, the point about Canonical employees.  AFAIK, Guido has
nothing against Canonical, but the fact that in his experience the
majority of bzr supporters must use it in their day jobs weakens their
claim to represent other Python developers.  A lot of Mercurial users,
OTOH, testify that they chose it freely based on a head to head
comparison of several systems.  That doesn't mean that Bazaar
aficionados wouldn't have chosen Bazaar anyway in a similar situation,
but Bazaar's claims to simplicity are weaker for that reason.

Does any of this represent what Guido is thinking?  Not necessarily.
Feel free to ask him.<wink>

ISTM that Bazaar development is about 3 months too late for the Python
window.  If Bazaar 1.14 (with its cumulative performance improvements)
had been released by Christmas, and 1.12 (or at least 1.9) had made it
into Debian Lenny (avoiding the unfortunate format bump on
code.python.org and allowing conservative Debian users the choice of
using a less functional but drop-dead-easy-to-acquire version of bzr),
the debate would have been very different.