Stories for guiding the Bazaar team's efforts in aid of DistributedDevelopment.

See also: DistributedDevelopment/BzrStoriesQuestions

The term “loom-like-package” on this page is not meant to imply that bzr-loom is the solution. It's just short-hand for “bzr object that can record and manage both the overall history of a package and the history of the individual patch-to-upstream objects it contains”.

Mini-grumpy

Description:
Automatic builds combining upstream tip and current packaging into a PPA.

Required operations/features:

• bzr merge-upstream (sufficiently good that it can be automated)

• reliable and timely automatic imports of upstreams into bzr

Apply upstream bug fix to Ubuntu

Description:
An Ubuntu core developer wants to backport a bug fix from upstream of project Foo into Ubuntu's package of Foo.

Commentary:
This is important, Ubuntu developers do this a lot.

Existing patch systems are a big mess.  We get a patch from somewhere, maybe upstream trunk, maybe bug trackers, whatever... then record that in the packaging.

This story doesn't map neatly to bzr features yet, need to tackle the larger problem before we can break it down completely.

Operations in a nutshell:

• branch (or checkout) a package

• bzr merge -c 1234 lp:project/stable

• record/commit that cherrypick as a new 'patch' in the package
• push/commit new package into ubuntu

What this means for bzr:
better cherrypicking? imports of non-trunk branches of upstream?

Compare package with Debian, merge package from Debian

Description:
An Ubuntu dev/MOTU wants to compare packaging of project Foo in Debian and Ubuntu (both the upstream version and the patches applied by the different packaging).

Commentary:
Having the diff is the main thing.

Packages can vary in multiple ways:

• different upstream version
• different patch sets
  • adds patch(es)
  • drops patch(es)
  • modifies patch(es)

A neat report of those changes would be nice, not vital.

There is a lot of merging from Debian.  You do the merge, then review the changes you want to bring in, then review what's left (so you can make sure the remaining changes are forwarded upstream).

Simple bzr merge is not right for this (at least as-is), so bzr-builddeb now has bzr merge-package.

Operations in a nutshell:

• Overall: bzr merge-package
• individually, this may include:
  • merge-upstream
  • add-patch
  • drop-patch

What this means for bzr:

• loom-like-package
• good imports of debian packages

Branching a package to a PPA

Description:
An enthusiastic user wants to "branch" an existing package from current Ubuntu development (or even a PPA), add a possible bug fix, and distribute, build and test it via a PPA. If the result works well, they will propose it for merging into Ubuntu.

Commentary:
James is keen to get this one right, it's important for first-time contributors. So a Just Works experience is important.  That said, it's more a Launchpad issue than a bzr issue (how to create & host a branch), and more an Ubuntu issue (how to edit a source package).

Ideally there would be a command like “bzr add-a-patch” — taking a existing package and adding one patch to it is a pretty common use case.

I know I would use this story if it were sufficiently simple, and other Canonical folk have said similar things.

Operations in a nutshell:

• Initial checkout of source: bzr branch lp:ubuntu/src-package

• Then add a patch: bzr add-a-patch?

What this means for bzr:

• loom-like-package

Submit diffs upstream

Description:
An Ubuntu dev wants to review changes in a package and feed as many as appropriate back to upstream (which may be Debian and/or the project itself).

Commentary:
Commonly done when syncing a package with its counterpart in Debian, which typically involves checking which patches in Ubuntu can be dropped (because the patch is now in upstream, or perhaps Debian has an equivalent patch), and making sure any remaining patches have been submitted back if appropriate.

It would be good to be able to record notes like “this patch has been forwarded to bug X” — i.e. once a patch has been forwarded upstream it doesn't need to be re-reviewed for forwarding the next time the package is reviewed.

Ideally submission to upstream would be as automated as “bzr send” is for regular bzr patches: bzr knows where to send it, what base to compare against, etc.

Patch submission isn't a fire-and-forget operation, it's the start of a conversation (although venues vary), because it's so rare for a patch to be accepted purely based on an initial submission.  The submission tool may need to take this into account?  Ideally, as devs commit code into bzr they start the conversation (i.e. submit it), so probably the tools should make it easy to submit a patch before it is part of a published package.

Operations in a nutshell:

• bzr send (or similar) that works on a single patch in a loom-like-package

  • configured so that the patch is filed in the Debian bug tracker?
• loom-like-package

  • bzr list-patches ?

What this means for bzr:
What this means for bzr: loggerhead diff viewer for packages? better bzr support for submitting patches to non-bzr (and non-launchpad) upstream? parallel imports? deb patch as first-class branch (loom?)?