Bundling more plugins into bzrtools
a.badger at gmail.com
Wed Feb 13 17:15:13 GMT 2008
I'm a packager of bzr and related tools for Fedora. At the moment, I'm
the only packager of bzr and related tools for Fedora. As such, I've
run up against a problem that I think is plaguing other packagers as
well (See dato's posting _ for one instance): There are a huge number
of useful plugins_ for bazaar but it takes an equally huge amount of
manpower to package them.
There are two main reasons for this:
1) Many of the plugins don't have a regular release schedule and are
only available as a bzr branch. For a packager, this means that they
have to poll the upstream branch to check if any significant changes
have occurred since the last snapshot was taken. If changes have
occurred, they have to create a snapshot of the source. Then they can
create the updated package. If the plugins were part of a package that
had regular releases the packager could just subscribe to announcements
for that package or have a script watch for a new tarball to appear in a
download directory and skip directly to step three.
2) Each plugin is a small amount of code but takes practically the same
amount of packaging work as a much larger package. The overhead for
packaging and maintaining each of bzr-webserve, bzr-bisect, bzr-dbus,
bzr-stats, and etc is the same as maintaining the bzr package itself.
The more packages are consolidated into a single base the more time
downstream maintainers have to spend helping to address actual bugs
rather than looking for new versions of each little package.
From a packager's point of view, the solution to these issues is
upstream consolidation. If there is an upstream tarball that provides
ten helpful plugins the packager would be able to package 10x as much
This consolidation is also helpful to the upstream projects. For
instance, if bzr-dbus, bzr-bisect, and bzr-stats tried to solve problem
#1 individually they would each have to implement build scripts to make
their checkout into a ready to consume tarball, each have to write
instructions for installing, and each have to create releases when the
time came. If combined, one set of build scripts and one release
manager could do the job for all of them.
Aaron Bentley's bzrtools package is a nice illustration of the payoff.
bzrtools has releases that coincide with every bzr major release. It
has multiple useful plugins that give it great packager bang for the
buck. Consequently bzrtools is packaged for Debian, Ubuntu, Fedora,
Gentoo, FreeBSD, etc while other useful plugins like stats, bisect, and
dbus are packaged for very few.
Aaron Bentley is also willing to *merge more plugins* into bzrtools if
the plugin authors want that to happen which is the point of this whole
email, really. Please, plugin authors, let's start a conversation about
merging more of these plugins into bzrtools so your hard work is
packaged up for others to use and thank you for creating :-)
.. _: https://lists.ubuntu.com/archives/bazaar/2007q4/036122.html
.. _: http://bazaar-vcs.org/BzrPlugins
Thanks for your time and code,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080213/988766f9/attachment.pgp
More information about the bazaar