UpstreamDevelopment

Differences between revisions 1 and 6 (spanning 5 versions)
Revision 1 as of 2011-10-04 07:44:03
Size: 2933
Comment:
Revision 6 as of 2011-10-04 16:56:22
Size: 3572
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Intro =
 * for Canonical upstreams only
Line 8: Line 10:
 * distro
Line 12: Line 15:
 * only reviewed branches merged in
 * always builds into a PPA
 * only code-reviewed branches merged in
 * always builds into a PPA automatically
Line 19: Line 22:
 * inlcudes new tests for the feature  * feature is signed off as ready to merge (by product manager, for example)
 * includes new tests for the feature
Line 21: Line 25:
 * if a branch breaks trunk, it gets reverted
Line 24: Line 29:
 * trunks reviewed by distro team before merging
 * always installs
 * tests run automatically
 * trunks reviewed by distro team before uploading
 * always installable
 * distro tests run automatically
 * some distro tests may be manual
Line 35: Line 41:
 * bugs have new regression tests added before fixing  * bugs have new regression tests added before fixing (bug fixes come with a new test)
Line 41: Line 47:
 * manual test plans
 * may require additional testing above and beyong trunk automated testing (for example manual tests in different hardware configurations)
 * manual test plans where necessary
 * may require additional testing above and beyond trunk automated testing (for example manual tests in different hardware configurations)
Line 45: Line 51:
== trunk tests readiness === == trunk readiness ===
Line 47: Line 53:
 * each team has someone to vouch for the readiness of the features
Line 49: Line 56:
 * every merge into trunk is vouched for by someone who is not the developer  * every merge into trunk is vouched for by someone who is not the developer, covers implementation and new tests
Line 52: Line 59:
 * someone on the distro team vouches fo the readiness of a trunk to be merged into the distro, requires upstream bug tracker to be free of High and Critical bugs  * someone on the distro team vouches fo rthe readiness of a trunk to be upload into the distro, requires upstream bug tracker to be free of High and Critical bugs
Line 61: Line 68:
 * someone needs to be responsible for triaging and linking bugs reports in Ubuntu, upstream of Ubuntu Engineering DA
 * Trunks that break Ubuntu will be rolled back
 * 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)
 * QUESTION: how do we deal with bug fixes in trunk when upstream has moved on?
Line 64: Line 72:
= workflow = = Workflow =
Line 73: Line 81:
 * identify feature sign-off owner
Line 76: Line 85:
 * define distro readiness tests  * define distro readiness tests for each upstream
Line 80: Line 89:
 * distro runs distro readiness tests
Line 81: Line 91:
 * branches are reviewed, tests written, bugs fixed until trunk passes all tests*  * going forward new branches are reviewed, tests written, bugs fixed until trunk passes all tests*

Intro

  • for Canonical upstreams only

components

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

branches

trunk

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

branches

  • "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

distro

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

tests

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 fo rthe 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

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

Ubuntu

  • 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)
  • QUESTION: how do we deal with bug fixes in trunk when upstream has moved on?

Workflow

Pre-Development

upstream

  • 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

distro

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

Development

  • starts out with a "clean" trunk for each upstream (all tests pass)*
  • distro runs distro readiness tests
  • distro integrates 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)