Review and Planning for Distributed Development

Registered by James Westby

This session is for reviewing the state of Distributed Development, and planning for
the next cycle.

Blueprint information

Not started
Steve Langasek
Barry Warsaw
Martin Pool
Series goal:
Accepted for oneiric
Not started
Milestone target:

Related branches



Work items:
[poolie] get network performance for udd closer to apt-get source: TODO
[poolie] categorize package import failures: TODO
[poolie] make sure bugs are file for all failure classes: TODO
[poolie] fix top two import failures: TODO
[poolie] reduce failures by 50%: TODO
[poolie] bring package imports in-house: TODO

(Maverick Notes Below)
Review and Planning for Distributed Development

 * deleted upstream source files after merge
  * ACTION: Micah needs to file a bug with more details
 * pulled a maintained package
   * package branch and upstream branch had parallel history
 * case where Debian is in bzr is not handled well [garyvdm]
 * upstream in bzr and no common history
   - need to reconcile them together- will cause a bump
 * similar case with Vcs-Bzr and Vcs-* parallel imports in Debian and Ubuntu
    ACTION: Make docs about how to tell the importer to pull from Debian
    branch availible. - GaryvdM
 * Debian imports will become a critical system - importer, gina(?),
   - also who to contact in case of a failure
      - Monitoring of GINA and define SLA on it
   - and what constitutes a critical failure
 * Problems with the version in the bzr branch being older than the
   one in the archive and it wasn't synced back
   - bugs in the importer
 * Tools should be hiding complexity not introducing it
   - just putting one commit into a branch vs just uploading the
     package doesn't seem to help much [scottk]
 * Until it's easier than regular tools, there won't be much uptake (especially
   for the MOTU cases)
   * See
   * Ideally, getting the code via bzr would be as fast & easy as downloading
     the tarball
 * Benefits will not come in the simple case, but by enabling more complex case
    * bzr annotate for example
    * many people working on the package
 * Performance implications of big branches like KDE
    * Long downloads, huge space constraints
    * Hard for new contributors
  * bzr limitations prevents some package import
     * lintian for example
     * 500 failures on about 16k
  * Maintaining patches as patches
    * Upstream Debian KDE maintainers use a patches directory
  * ACTION: add Table of Contents to
    page to reduce confusion
  * Support repacked tarballs (e.g. firefox)
  * Launchpad should mark things as fix released automatically (things that were commited)
  * Launchpad should be able to build the package on mark-uploaded (change name?) - no more dput
  * More (findable!) documentation
    * Don't treat everyone the same way
    * Don't wait until everything is utopia before we start promoting to some
  * Want deb-aware diffs to be shown in code review
  * Want to send a customized diff to debian
    * e.g. xchat is not the default irc server in debian, is in ubuntu
    * e.g. nmu uploads have different requirements for changelogs between U&D
    * sometimes just the changelog needs to be different
    (Possible solutions from bzr: Daggy fixes, or Cherry picks.)
  * Show the diff targeted at upstream in the bug?
  * Want plain testing of
  * ACTION: add hook to bzr to automatically add revision property based on
    commit message
  * Could launchpad not email me the branch info after the upload every time.


Work Items