SubsystemsBranchModel

= 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