By Jonathan Corbet
September 11, 2012
The
Bazaar (or "bzr") version
control system lacks the visibility of systems like Git or even Mercurial.
That is not to say that it is an insignificant project: it has a dedicated
following of its own, it is the system used
internally at Canonical, and it has been designated as an official GNU
project (meaning that other GNU projects are expected to use it). So one
would not think that Bazaar was a project in danger of running out of steam
and grinding to a halt. But that, it seems, is exactly the scenario that
some of its users are worried about.
Stefan Monnier kicked off the discussion by
noting that the number of commits to Bazaar has been dropping and that
bugs are not getting fixed. The departure of
lead developer Martin Pool from Canonical (and from the Bazaar project)
has certainly not helped the situation. So, Stefan said:
[A]s unfixed bugs accumulate, I'm beginning to feel a bit like in the
bad CVS days where you just had to get used to circumventing its
limitations, for lack of actual development.
Some participants questioned whether there was a problem, noting that
commits continue to flow into the Bazaar repository. But Matthew Fuller ran the numbers and came to a fairly clear
conclusion:
From even a casual glance, falloff in bzr.dev landings is pretty
obvious. Through most of the history (looking at the month level),
bzr.dev averages at least a rev a day, not uncommonly twice that.
But the last 5 months put together don't even reach the single
month average. It's no proof of development stopping by any means,
but it sure is a red flag likely to lead people to that
conclusion.
This slowdown has happened despite the fact that a new major release (2.6)
was expected in August. When that release does happen, the list
of new features seems unlikely to knock the socks off many users.
Bazaar, as a project, may not be dead, but it shows signs of going into a
sort of maintenance mode.
What is going on?
Once one accepts that development on Bazaar is slowing, it is natural to
wonder why that is and what can be done about it. One possibility is that
the distributed version control problem has been solved and that there is
little need for more
development. After all, significant projects like bash and make have not
shown blistering rates of development; there simply is no need at this
point. In the distributed version control system area, though, it would be
hard to say that there are no challenges remaining. Projects like Git and
Mercurial continue to evolve at a high rate. So, in a general sense, it
would be hard to say that Bazaar is slowing down because there's nothing
more to do.
That doesn't mean that Canonical, which has sponsored most of the work on
Bazaar, sees more that needs to be done. Indeed, according to John Arbash Meinel (Martin Pool's
replacement as Bazaar lead developer), Canonical is
happy with the current state of affairs:
I think fundamentally Bazaar does most of what Canonical needs, and
the team has been focusing more on other bits around Bazaar
(Launchpad, package-importer, bzr-svn integration, etc). Also,
Launchpad and Bazaar have never really been meant as products in
their own right, but more as facilities to build Ubuntu. And while
not perfect, they do a pretty darn good job of it, and it makes
sense to focus more on other areas of development.
He added that Bazaar wasn't in danger of disappearing anytime soon.
"It is still being actively maintained, though a little less actively
than last year." That statement was seen by some as an oblique way
of saying that Bazaar is now in maintenance mode — a prospect that was not seen
as particularly reassuring by Bazaar users.
Of course, Bazaar is free software, licensed under the GPL, so anybody is
free to step up and carry it forward. Thus far, though, that has not
happened. Once again, it is worthwhile to think about why that might be.
Possibly Bazaar users got comfortable with Canonical carrying the load of
Bazaar development and have not, yet, felt the need to help out. Over
time, some of these users might decide that it is time to pick up some of
that load going forward. Or they might just switch to another system with
a more active community.
One possibility, raised by Ben Finney, is
that Canonical's much-maligned contributor agreement is a
part of the
problem. This reasoning says that, since Canonical reserves the right to
release contributions to
Bazaar under proprietary licenses, many potential contributors have voted
with their feet and gone elsewhere. It's far from clear that the
contributor agreement is really part of the problem, though. If there were
really a community of developers who would contribute if only the terms
were more fair, an agreement-less Bazaar fork would almost certainly have
emerged by now. The fact that nobody has even attempted such a fork
suggests that Canonical's agreement is not really holding things back.
Stephen Turnbull had an interesting alternative
explanation for what is going on. Bazaar, he says, is a tool aimed at
users who want their version control system to "just work" without them
having to think about it much. Git, he says, is a different matter:
Many of those who chose git also made a deliberate, informed
choice, knowing that use of git requires both an investment in
learning about the tool and, often, day-to-day thought about
workflow. My suggestion is that such people are on average more
likely to contribute to git than the average bzr user is to
contribute to Bazaar.
Some participants saw this suggestion as a sort of insult against Bazaar
users, saying that they lacked the ability or the drive to improve the tool. But that
is not what Stephen was saying; his point is that, by appealing to users who
don't want to have to think about their version control system, Bazaar has
created a user community that is relatively unlikely to want to put their
time into making the system better.
There is an alternative that nobody has mentioned in this discussion:
perhaps Bazaar has simply lost out to competing projects which have managed
to advance further and faster. For sheer functionality, Git is hard to
compete with. For those who are put off by the complexity of Git,
Mercurial offers a gentler alternative without compromising on features.
Perhaps most potential users just do not see anything in Bazaar that is
sufficiently shiny to attract them away from the other tools.
If that is the case, it is hard to imagine what can be done to improve the
situation from the point of view of Bazaar users, especially given that
Canonical has lost interest in adding
features to Bazaar. Perhaps, as Ben suggested, another corporate sponsor could be
found to take up the Bazaar banner. Failing that, Bazaar seems likely to
stay in maintenance mode indefinitely; it will remain a capable tool, but
will find itself increasingly left behind by the other free alternatives.
Comments (118 posted)
Brief items
Distributed version control is so much harder to use when your central server is down. #Github
—
Greg Raiz
Every time I've been involved in a project without a schedule, we've had a
long period of (probably highly satisfying for developers) of 'undirected
hacking' followed by crisis, followed by a rush to 'get it out before people
forget who we are' which inevitably had some fallout (I'm thinking of the
period leading up to KDE 4.0 here ;).
—
Will Stephenson
Comments (none posted)
A new version of the
GNU Source Release Collection (GSRC) is available. GSRC is a utility to "
fetch, build and install the latest GNU software from source via a BSD Ports-like system." This release supports 271 GNU project packages.
Full Story (comments: none)
The PostgreSQL 9.2 release is available. "
Since the beta release was announced in May, developers and
vendors have praised it as a leap forward in performance, scalability
and flexibility. Users are expected to switch to this version in
record numbers." LWN ran
a detailed
look at this release in May.
Full Story (comments: 14)
Version 2.7 of the GNU patch utility — the first release in almost three
years — is out. It offers various improvements to the accepted patch
format including nearly full support for the "
diff --git"
format, a number of security-related fixes, nanosecond-precision timestamp
support, and more.
Full Story (comments: 3)
The Mozilla Hacks blog
announces
that the Opus codec is now an official IETF standard; it is
RFC6716. "
Opus is the
first state of the art, free audio codec to be standardized. We think this
will help us achieve wider adoption than prior royalty-free codecs like
Speex and Vorbis. This spells the beginning of the end for proprietary
formats, and we are now working on doing the same thing for video."
Comments (24 posted)
Version 1.3 of the SyncEvolution data synchronization framework is available. This release adds support for syncing with KDE's Akonadi or Microsoft's ActiveSync, and for synchronizing CalDAV tasks and memos. The project has also moved its infrastructure from meego.com to freedesktop.org.
Full Story (comments: none)
Newsletters and articles
Comments (none posted)
The H takes a look at a report from the US Congressional Research Service about patent trolling and potential fixes to the system. "According to the researchers, it is worth considering whether to generally shorten the periods of protection for software patents because the trolls file most of their litigation claims in the last three years of the 20-year term. A patent could also be invalidated if it hasn't been practised for a number of years, they added."
Comments (23 posted)
On his blog, Juan "Nushio" Rodriguez has been systematically reviewing all of the entries in the OpenGameArt project's
Liberated Pixel Cup (LPC) free software game contest in recent weeks. Reviews of
all 48 games are now available. Note that these are personal assessments, not the results of LPC's official judges. Note also that Rodriguez is an LPC contestant, so he had someone else review his own entry, presumably to add a bit more suspense.
Comments (none posted)
Libre Graphics World
reports
on the release of version 4.4 of the venerable Cinelerra video editing
system. "
The amount of changes is quite modest, and half of them are
in the audio department. the developer claims better live audio processing,
as well as audio gaps removal effect and audio oscilloscope. Apart from
that, you are likely to experience faster startup, more responsive
interface, better recording from webcams, and you definitely get a new
Bright UI theme."
Comments (none posted)
Here's
a
lengthy posting from Michael Meeks on the state of the desktop market. "
The
economics of an excessively cheap product are a difficult fit for the
consumer market, and drain money from the ecosystem necessary to invest in
development. The relentless drive to a zero cost-point to gain market share
in Linux Desktop pre-loading helps to further sterilize the space."
He suggests that the business desktop may be a better target for a
Linux-based solution.
Comments (92 posted)
Page editor: Nathan Willis
Next page: Announcements>>