[RFC] bzr-packagers team

Ian Clatworthy ian.clatworthy at canonical.com
Mon Mar 8 06:12:01 GMT 2010


I spend a large amount of last week fighting our Windows installer
scripts to find and correct some problems. In the process, I was
reminded about the technical debt we have in that space. To be more
explicit, the knowledge about what components make up a particular
installer are scattered across multiple places: a buildout.cfg script, a
bat file template (man I hate maintaining bat files) and an installer
configuration file. Adding new plugins, dependencies (e.g. subvertpy)
and help files is currently a fragile, buggy process. :-(

I've started work on a DRY[#], One-Click Build approach: a single file
called bazaar_releases.py that contains the metadata for what
constitutes each installer. When complete, adding new components to our
Windows builds will be as simple as ...

1. edit bazaar_releases.py
2. ./build.py installers [which installers]

Under the covers, buildout, setup.py and Inno will still be used but the
effort required to make changes will be much less. We will then be well
placed to bundle more plugins in Bazaar 2.2. We will also be well placed
to create new installers, e.g. one for loggerhead, nightly builds for
2.1 and trunk, etc.

Given my experiences above, I'm thinking it would be good to create a
packagers team, one where we can get that subset of people working
closer together. At a minimum, I'm hoping we'll get better co-ordination
across platforms, e.g. maybe the OS X installer could use the same
bazaar_releases.py file to drive consistency across what plugins are
bundled? For deb, rpm, ports, portage, etc, maybe we could rationalise
package naming so that

* bzr = core
* bazaar = bazaar+recommended_plugins

Hmm. Maybe that's being *too* ambitious. :-)

Anyhow, any objections to a bzr-packagers team?

Ian C.

[#] DRY = Don't Repeat Yourself



More information about the bazaar mailing list