Bundling more plugins into bzrtools

Toshio Kuratomi a.badger at gmail.com
Wed Feb 13 17:15:13 GMT 2008


Hello all,

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 [1]_ for one instance): There are a huge number 
of useful plugins[2]_ 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 
functionality.

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 :-)

.. _[1]: https://lists.ubuntu.com/archives/bazaar/2007q4/036122.html
.. _[2]: http://bazaar-vcs.org/BzrPlugins

Thanks for your time and code,
-Toshio Kuratomi

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080213/988766f9/attachment.pgp 


More information about the bazaar mailing list