bzr for packaging

[Martin Pitt]

Hi,

Matt Zimmerman [2007-03-08 16:41 -0800]:
> Martin and I are interested in feedback about bzr-builddeb, similar tools,
> and any other practices around using bzr for packaging.
> 
> What are you doing?  What works well?  What is painful?  

== keeping source packages in bzr ==

I found having packages in bzr is a great aid for packages which see
heavy development from my side (e. g. apport, postgresql-common,
restricted-manager) for the following reasons:

 * Collaboration - merging from each other works really well, painful
   without RCS.
 * Community testing - "You test, report errors, I fix/commit/push,
   you pull and test again" works just wonderful as well.
 * Developing packages while traveling.
 * Low overhead and high yield for packages which have lots of
   changes relative to the number of uploads (like hal).

On the other hand, the painful things are:

 * Lots of overhead if all you want to do is a single quick fix to a
   package, since we do not have the same abstract tool support as
   apt-get source provides (yay hct :) ).
 * Easy to get out of sync between the archive and the bzr branch
   (transitional mass uploads, forgot to check for bzr branch, etc.)
 * Pushing and pulling from LP still takes quite long. I guess
   deploying smart server will help tremendously?

== common practice that I found to work well ==

* Keeping bzr and Debian changelog in sync. I usually write the Debian
  one and use [1] to automatically generate a bzr one. However, this
  could become a more official and better integrated tool (plugin
  instead of a shell wrapper).
  
* Keeping the changelog release as 'UNRELEASED' while committing
  changes. This makes it easy to see for other people that they must
  not start a new package revision. As a very last step before
  uploading, s/UNRELEASED/feisty/ and 

    bzr commit -m 'release as 1.2-3 to feisty'

  so that it is easy to retrieve older package versions just by
  looking at bzr log.

== tools ==

* http://codebrowse.launchpad.net: REALLY REALLY useful for discussing
  changes with other devs. Kudos to whoever set this up. However, why
  is this such a secret? It should be prominently linked from
  {code,bazaar}.lp.net pages.

* I never used bzr-buildpackage and similar so far. debuild -i -I.bzr
  keeps source packages clean, and as long as we do not have real
  upstream branches, I do not see the benefit of such a thing. But
  you never miss what you don't know, so maybe there are some
  non-obvious goodies in it.

Martin

[1] http://people.ubuntu.com/~pitti/scripts/bzrdc 
    (read it as 'bzr debian commit' and blame my Huffman-coding-like
    script and alias names)

-- 
Martin Pitt        http://www.piware.de
Ubuntu Developer   http://www.ubuntu.com
Debian Developer   http://www.debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20070309/43ae5ccb/attachment.pgp