Intro
- for Canonical upstreams only
components
- branches
- trunk
- tests
- sign off
- bug reports
- distro
branches
trunk
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
branches
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
distro
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
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 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
- 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)
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 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