Latest revision as of 23:30, 17 February 2013

Subsystem branch models

What is a subsystem?

Plausible subsystem branches are:

• OpenStack APIs
  • EC2 API
  • virt
    • libvirt driver
    • xenapi driver
    • vmware driver
• networking
• volumes
• scheduler
• RPC

Deciding which areas make sense as a subsystem branch is non-trivial.

0. Current model

master -------------------------------------------------------
                 \            \           \
                  \            \           \
mp                 ----         ----        ------------

Use milestone-proposed to control merge windows.

Drawbacks:

• no subsystems with area experts
• no staging ground for features that are not release-ready
• feature freeze between last milestone and RC1
• painful cherry-picks while MP exists

1. Just add subsystem branches

subsystem --------------------------------------------------
             \ /    \ /     \ /        \ /      \ /   \ /
master -------------------------------------------------------
                 \            \           \
                  \            \           \
mp                 ----         ----        ------------

• Add subsystem branch(es) where possible
• Features that do not belong to a subsystem land directly in master
• Use milestone-proposed to control merge windows.

Drawbacks:

• no staging ground for features that are not release-ready (for features not in subsystems)
• feature freeze between last milestone and RC1
• painful cherry-picks while MP exists

2. "Default" subsystem model

defaultsubsystem    --------------------------------------------------
                         \ /    \ /     \ /        \ /      \ /   \ /
release --------------------------------------------------------------
                / \   / \           / \       / \
subsystem2    --------------------------------------------------------

• Only features that are ready land in the release branch
• Default subsystem branch used when feature does not belong to specific

Drawbacks:

• No obvious "master" branch (release branch will be often frozen and therefore out of date)

3. The master subsystem model

subsystem    --------------------------------------------------
               \ /    \ /     \ /        \ /      \ /   \ /
master    -----------------------------------------------------
                         \  /                 \  /
release -------------------------------------------------------

• Subsystem branches get often proposed to master branch
• Other changes get directly to master branch
• Update release branch with master content at merge point, merge back RC bugfixes after release
• RC fixes land in release branch

Drawbacks:

• No release-readiness review (master needs to be release-ready all the time)
• No feature staging ground unless you use subsystems
• no staging ground for features that are not release-ready (for features not in subsystems)
• feature freeze between last milestone and RC1 (for features not in subsystems)

4. Combo subsystem model

defaultsubsystem    --------------------------------------------------
                         \ /    \ /     \ /        \ /      \ /   \ /
master  --------------------------------------------------------------
                 / \          \                        / \  \
mp              /   \          ------                 /   \  -------
subsystem2    --------------------------------------------------------

• Only features that are ready land in the master branch
• Default subsystem branch used when feature does not belong to specific
• Use milestone-proposed to control merge windows

Drawbacks:

• No feature staging ground unless you use subsystems
• painful cherry-picks when you're out of the merge window

5. Vish's supercombo subsystem model

subsystem      ----------------------------------------------------------
                         \ /    \ /     \ /     \ /           \ /   \ /
master  ----------++F1-------------++F2------------++F3***RC1-----------
               \      /                        \      /    \       / /
folsom-release  \    /                          \    /      --RC2---R
fixes/features   ----                            ----         \  /
RC bugfixes                                                    --

• Only features that are ready land in the master branch
• Bugfix branches are proposed to master
• Feature branches can be directly proposed to master, though not recommended
• Soft freezes on master for milestones (+) and between last-milestone and RC1 (*)
• Use a folsom-release branch after RC1 to avoid long freeze

Drawbacks:

• No feature staging ground unless you use subsystems
  • But simpler projects could use an "experimental" subsystem for craziest stuff
• master serves both for release-readiness and "normal" reviews
  • But can use review fields for code review and approval field for release-readiness
• Some amount of feature freeze for features not in subsystem branches