opendaylight branching analysis stephen kitt, robert varga– 2016-01-11
DESCRIPTION
Basic assumptions All projects divided into three groups Offsets or kernel/protocols/apps How projects are grouped is not relevant Each group has its own development cycle Per-group ‘autorelease’ setup Inter-group dependencies are strictly on released artifacts Intra-group dependencies are strictly on SNAPSHOT artifacts 3TRANSCRIPT
![Page 1: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/1.jpg)
OpenDaylight branching analysisStephen Kitt, Robert Varga– 2016-01-11
![Page 2: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/2.jpg)
2
Intro• Based on https://
lists.opendaylight.org/pipermail/release/2015-October/004147.html• Analysis at https://wiki.opendaylight.org/view/New_workflow_proposal
![Page 3: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/3.jpg)
3
Basic assumptions• All projects divided into three groups
• Offsets or kernel/protocols/apps• How projects are grouped is not relevant
• Each group has its own development cycle• Per-group ‘autorelease’ setup
• Inter-group dependencies are strictly on released artifacts• Intra-group dependencies are strictly on SNAPSHOT artifacts
![Page 4: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/4.jpg)
4
Simplistic* three-project illustrationYangtools master
Yangtools stable/boronYT release
YT release propagation
Mdsal master
MDSAL release
Controller stable/boron
Controller masterCTRL release
YT+MDSAL release propagation
*) Does not account for how the autorelease looks
![Page 5: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/5.jpg)
Per-group autorelease contents• Upstream groups’ artifacts on their released version
• Upstream delivers fixes via stable releases
• This group’s artifacts on SNAPSHOTs• Downstream artifacts on SNAPSHOTs
• Previous version + any modifications to make integration work• ‘integration branch’• Never actually released
![Page 6: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/6.jpg)
The ‘integration branch’• Actually a per-group collection of per-project branches• Created for each new release cycle using latest release artifacts• Contains fixes to make the component work with upstream
development• “Owned” by its group projects
• Similar rules to autorelease participation• Upstream can decide to drop a downstream project to get unblocked
• Retired when the group performs a release• Available for cherry-picks and merges into downstream
![Page 7: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/7.jpg)
Risks• Release artifact propagation occurs between groups
• Propagation blocked until all projects in downstream group complete• … or are thrown out of the release, which affects their downstream
• What is the integration window?• Issues reported by downstream has to be prioritized• If ‘integration-critical’ bugs are raised, upstream dev cycle is interrupted• May be reasonably predictable
• How important is upstream?• Issues encountered by upstream integration need to be analyzed/fixed• Disrupts downstream dev cycle to analyze bugs• Project dropped from integration branch in limbo until fixed, along with all its consumers
![Page 8: OpenDaylight branching analysis Stephen Kitt, Robert Varga– 2016-01-11](https://reader036.vdocument.in/reader036/viewer/2022082510/5a4d1b547f8b9ab0599a8930/html5/thumbnails/8.jpg)
Mitigation• Smaller groups
• Faster integration• Less functionality skew
• Semantic versioning• ‘Free’ minor upgrades
• Faster releases• Less ‘delta’ between integrations
• Different development workflows?