• for Canonical upstreams only


  • branches
  • trunk
  • tests
  • sign off
  • bug reports
  • distro



Goal: Trunk is considered sacred. For a feature, bug or other to make it into trunk means it is ready to go (tested, signed-off, reviewed etc). Trunk is then tagged so platform can pull easily.

  • typically lp:project-name
  • only code-reviewed branches merged in
  • always builds into a PPA automatically
  • all tests pass
  • distro can take any tagged release at any point


Goal: Features are developed outside of trunk in branches. Only when feature is ready to go and signed-off would it be merged into trunk.

  • "feature branches" because where features are built
  • feature is signed off as ready to merge (by product manager, for example)
  • includes new tests for the feature
  • is code reviewed and all tests pass before merged into trunk
  • if a branch breaks trunk, it gets reverted


Goal: Distro pulls tagged trunk release. Distro always has a viable trunk from which to pull. Tagged trunks mean distro can roll back to previous tagged release if needed.

  • where all tagged releases in trunks go to be used
  • trunks reviewed by distro team before uploading
  • always installable
  • distro tests run automatically
  • some distro tests may be manual


test plans

  • trunk automated testing
  • distro readiness

trunk tests

  • Constantly improving test suite
  • bugs have new regression tests added before fixing (bug fixes come with a new test)
  • tests are run automatically
  • trunk always passes all tests, branches that cause trunk tests to fail are reverted

distro tests

  • automated integration tests run daily
  • manual test plans where necessary
  • may require additional testing above and beyond trunk automated testing (for example manual tests in different hardware configurations)

sign off

trunk readiness

  • each team has someone to vouch for the quality of their trunk tests
  • each team has someone to vouch for the readiness of the features

branch code review

  • every merge into trunk is vouched for by someone who is not the developer, covers implementation and new tests

distro readiness

  • someone on the distro team vouches for the readiness of a trunk to be upload into the distro, requires upstream bug tracker to be free of High and Critical bugs
  • trunks that break Ubuntu will be rolled back

bug reports


  • upstream team is responsible for triaging and fixing upstream bug reports
  • distro will not accept a trunk with High or Critical bugs


  • someone needs to be responsible for triaging and linking bugs reports in Ubuntu, upstream or Ubuntu Engineering, for example a DA
  • Trunks that make Ubuntu unusable will be rolled back (typically critical bugs)




  • define specific trunk
  • identify trunk test owner: who signs off that trunk tests are sufficient
  • write trunk tests, make them run automatically
  • fix bugs until all tests pass
  • make trunk build PPA automatically
  • set up branch code review workflow
  • identify feature sign-off owner


  • identify distro-readiness sign off person for each upstream
  • define distro readiness tests for each upstream


  • starts out with a "clean" trunk for each upstream (all tests pass)*
  • distro runs distro readiness tests
  • distro integrates tagged-trunk into Ubuntu*
  • going forward new branches are reviewed, tests written, bugs fixed until trunk passes all tests*
  • distro readiness tests run on trunk
  • if distro readiness tests fail, bugs are logged upstream
  • bugs are fixed in trunk *without new branches merged*, all High and Critical bugs fixed
  • distro readiness tests re-run
  • distro integrates new branch*

* denotes a step that requires sign off

UbuntuEngineering/12.04/UpstreamDevelopment (last edited 2011-10-20 13:54:08 by rick-rickspencer3)