Improving Packaging Workflow With bzr

Registered by Daniel Holbach

        Agenda:
        * come up with current workflows using bzr for packaging
        * investigate what needs to change
        * find out which tools to write, which infrastructure we need
           to slowly approach NoMoreSourcePackages

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Daniel Holbach
Direction:
Needs approval
Assignee:
None
Definition:
Superseded
Series goal:
None
Implementation:
Informational Informational
Milestone target:
None
Completed by
Daniel Holbach

Related branches

Sprints

Whiteboard

Would like to have NoMoreSourcePackages, however Bazaar is too slow to have all packages including upstream in Bazaar.
Bazaar is improving. Focus is currently on a new format which requires reading less data and doing less round trips,
and speeding up the smart server.

There is no standard way to layout a branch. There are 3 ways

  * Version just debian/. further ways to do that.
    - Have debian/ versioned.
    - Have contents in the root of the branch.
  * Import tarballs to get upstream.
  * Use a full upstream branch.
    - Can be too large for some packages.
    - Allows patches to go upstream more easily if they use Bazaar.

Something like the loom plugin could be very useful as patch files in the source package have some benefits.

  * Robert may have some code in this area.
  * It is desirable, but a way off yet.

 * sometimes .orig.tar.gz files will have other tarballs within them
   * OpenOffice has some splitting this way
   * Other packages do this to work around build systems that don't fullly clean up (such as a package with a poorly written scons file)

When debian uses SVN bzr-svn can be useful to work with them.

Making apt-get source get a branch would be favourable as long as you already get a proper source packages as well. To make this work
better having dput aware of this as well. If the uploader is required to commit ten mass transitions could become irritating. There could be a launchpad branch that merely reflects the current package in the archive that the maintainer can just pull from.

Making sure that XS-Vcs-Bzr is changed when Ubuntu makes changes is important.

(maybe metadata about how the branch is managed. OTOH, apt could just check the branch for its type)

Because samba uses git, there may be a bzr-git working properly soon.

Domain specific merge for debian/changelog should be possible.

(?)

Work Items