BDFL decision of Python's DVCS

[Russel Winder]

On Tue, 2009-03-31 at 13:34 +0900, Stephen J. Turnbull wrote:
[ . . . ]
> 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!?")

So how does Mercurial evolve -- or did they get the right format first
time and will never have to change it?

Another implication here is that Mercurial has better managed its
relationship with all the distro packaging people -- including I assume
Windows?

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

This is an interesting point.  I suspect that social rather than
technical factors are at work.  I hypothesize that someone well versed
in Mercurial  found a nice way of working for themselves and announced
it.  This got picked up and became a "fact" rather than just one
person's impression.  Social psychology is invariably the main factor in
these sorts of decision, technical issue generally come a far third.

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

I find this conservatism and indeed almost Ludditism very interesting.
A priori I would have thought that Python developers were cutting edge
people, wanting to do the best thing.  Instead I get the impression of
people who don't want to change, are having change forced on them, and
so are rebellious.
 
> 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.

If this point gets picked up and publicized widely then usage of Bazaar
will dwindle.  Not rapidly at first, but with increasing rate.  If the
"fact" (and anything Guido says along these lines generally gets
converted into "fact" by people other than Guido) that Bazaar is for
Canonical employees only, then no-one will ever choose it over Mercurial
or Git for a new FOSS project.  

One thing I am really glad of though is that Python chose something
other than Git.  I am finding far too many people choosing Git for all
the wrong reasons -- usually because Bazaar or Mercurial would be better
for them.  Git somehow managed to get the zeitgeist leading people to
choose it because they felt they should, rather than checking that the
tool fitted their favoured workflow.

I still think Git is great at tracking remote repositories, and that
Bazaar can and should learn that lesson.  I am not sure how good
Mercurial is at that but I guess I am now going to have to learn as more
and more projects will now choose it -- because Guido did.

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

I still think the obviousness to the Bazaar user of format changes are a
big problem for Bazaar, especially if using Launchpad.  Try pushing a
new branch to Launchpad -- you get an error message about storage
formats.  If you push again it all works, but how many people will do
that?

The Big Win for Bazaar for me is still the interworking with Subversion
-- the fact that I can have a Bazaar branch stored in a Subversion
repository.  Python is looking to change its VCS not everyone has the
option.  For me bzr-svn is still the front runner in the interworking
stakes.  If Git or Mercurial attack that problem then Bazaar might
really have issues.
 
FInally (!):  there is another issue here that again is one of social
psychology and perception, not of fact:  people perceive Git and
Mercurial to be FOSS projects, whilst Bazaar is a Canonical product.
The question is how to tap into whatever allowed Eclipse, the well known
IBM product to gain majority market share, and for NetBeans, the well
known Sun product (well they bought the company), to become the young
pretender.  It's all a marketing problem.
 
-- 
Russel.
============================================================
Dr Russel Winder                 Partner

Concertant LLP          t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road,     f: +44 8700 516 084    voip:  sip:russel.winder at ekiga.net
London SW11 1EN, UK.    m: +44 7770 465 077    xmpp: russel at russel.org.uk
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090331/c57d67da/attachment.pgp