UpstreamDevelopment
Differences between revisions 2 and 5 (spanning 3 versions)
|
Size: 3086
Comment:
|
Size: 3525
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 26: | Line 26: |
| * 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 37: | Line 38: |
| * bugs have new regression tests added before fixing | * bugs have new regression tests added before fixing (bug fixes come with a new test) |
| Line 43: | Line 44: |
| * 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 47: | Line 48: |
| == trunk tests readiness === | == trunk readiness === |
| Line 49: | Line 50: |
| * each team has someone to vouch for the readiness of the features | |
| Line 51: | Line 53: |
| * 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 54: | Line 56: |
| * 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 63: | Line 65: |
| * 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 66: | Line 69: |
| = workflow = | = Workflow = |
| Line 75: | Line 78: |
| * identify feature sign-off owner | |
| Line 78: | Line 82: |
| * define distro readiness tests | * define distro readiness tests for each upstream |
| Line 82: | Line 86: |
| * distro runs distro readiness tests | |
| Line 83: | Line 88: |
| * 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* |
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 AToulouse-554-1-7-90)