Post on 18-Jan-2018
description
OpenDaylight branching analysisStephen Kitt, Robert Varga– 2016-01-11
2
Intro• Based on https://
lists.opendaylight.org/pipermail/release/2015-October/004147.html• Analysis at https://wiki.opendaylight.org/view/New_workflow_proposal
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
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
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
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
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
Mitigation• Smaller groups
• Faster integration• Less functionality skew
• Semantic versioning• ‘Free’ minor upgrades
• Faster releases• Less ‘delta’ between integrations
• Different development workflows?