User: Password:
Subscribe / Log in / New account

Ah yes

Ah yes

Posted Sep 12, 2012 14:01 UTC (Wed) by corbet (editor, #1)
Parent article: Bazaar on the slow track

Pretty amusing to think that I forgot totally about this moment in history while writing the article:

A few years ago the core Mercurial and Bzr developers met in London for a weekend to compare notes and came to a tentative agreement that merging the two projects would be a good idea. This idea was very quickly torpedoed by Mark Shuttleworth's insistence that whatever project resulted would have to have copyright held by Canonical. The stated reason was allowing proprietary feature extensions as part of their Launchpad strategy.

I wrote Mercurial to be Free with a capital 'F' as a reaction to the object lesson of Bitkeeper. So entrusting my work to an organization that had plans to embrace and extend it was just not going to happen.

— Matt Mackall

(Log in to post comments)

Ah yes

Posted Sep 12, 2012 14:55 UTC (Wed) by pboddie (guest, #50784) [Link]

Ben Finney comes closest to the most probable explanation for the lack of developer interest, I think. Canonical chose to do everything in their own walled garden (Launchpad) with their own technologies (Bazaar-NG) and expected people to play along.

It's one thing to have various technology decisions influencing any project that Canonical is involved in, even though this will deter outsiders by itself; it's another to see Canonical wanting to exercise control over the products of such development as well.

You can certainly lean on the community to do the hard work if they benefit as much from it as you do, but as soon as you ask them to benefit less (and here I ignore the excuses about Canonical's unique stewardship role and corresponding privilege - on whom does the hard work of quality assurance and other tedious stewardship matters fall, exactly, if not the community in many cases?) then they will exercise their rights as volunteers and indulge some other projects instead.

Ah yes

Posted Sep 17, 2012 20:18 UTC (Mon) by jspaleta (subscriber, #50639) [Link]

There's a critical point here I think needs to be stressed.

Bzr is primarily used as a tool to interact with It's never really garnered significant adoption as a standalone tool. Yes some people do use it outside of launchpad, I'm not saying there is zero interest in bzr sans launchpad integration, just that i don't see critical mass in bzr community if launchpad integration were lost.

Because of the intimately tied nature with a Canonical controlled service (launchpad) there is less overall incentive for an external to try to create and lead a competing fork for fear of creating an incompatibility with the service requirements. It's forkable, the license on the code assures that is a possible future, but I doubt anyone is going to ever seriously do it.

It's a deep tangle.

I've yet to hear of someone attempting to take the sources and spinning in an alternative site. If someone did that, forked the codebase and spun up a implementation outside of Canonical's control, then a fork of bzr would be an obvious part of that much more involved effort. In for a penny in for a pound.

The irony of course being that the deep integration with launchpad is probably the only reason keeping bzr alive as a project at all at this point. If Canonical threw away launchpad entirely and started from scratch today... I'd wager they'd pick up git as part of the scaffolding. bzr is just a long lived piece of technical debt at this point for the launchpad team inside Canonical.


LP-bzr vs. LP-git?

Posted Sep 17, 2012 23:25 UTC (Mon) by smurf (subscriber, #17840) [Link]

Actually, I'd assume that replacing bzr with git in Launchpad would be reasonably straightforward.

Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds