UpstreamDevelopment
2933
Comment:
|
← Revision 10 as of 2011-10-20 13:54:08 ⇥
4104
|
Deletions are marked like this. | Additions are marked like this. |
Line 1: | Line 1: |
[[attachment:acceptance.odp]] = Intro = * for Canonical upstreams only |
|
Line 8: | Line 12: |
* distro | |
Line 11: | Line 16: |
'''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. |
|
Line 12: | Line 19: |
* only reviewed branches merged in * always builds into a PPA |
* only code-reviewed branches merged in * always builds into a PPA automatically |
Line 15: | Line 22: |
* distro can take at any point | * distro can take any tagged release at any point |
Line 18: | Line 25: |
'''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. |
|
Line 19: | Line 28: |
* 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 31: |
* if a branch breaks trunk, it gets reverted | |
Line 23: | Line 34: |
* where all trunks go to be used * trunks reviewed by distro team before merging * always installs * tests run automatically |
'''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 |
Line 35: | Line 49: |
* 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 55: |
* 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 59: |
== trunk tests readiness === | == trunk readiness == |
Line 47: | Line 61: |
* each team has someone to vouch for the readiness of the features | |
Line 49: | Line 64: |
* 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 67: |
* 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 for the 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 76: |
* 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 = workflow = |
* 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 = |
Line 73: | Line 88: |
* identify feature sign-off owner | |
Line 76: | Line 92: |
* define distro readiness tests | * define distro readiness tests for each upstream |
Line 80: | Line 96: |
* distro integrates trunk into Ubuntu* * branches are reviewed, tests written, bugs fixed until trunk passes all tests* |
* 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* |
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
UbuntuEngineering/12.04/UpstreamDevelopment (last edited 2011-10-20 13:54:08 by AToulouse-554-1-7-90)