Review and Planning for Distributed Development

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
===============================================

Problems:
 * 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 https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2010-January/000373.html
   * 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 http://package-import.ubuntu.com/status/
    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.