Difference between revisions of "SubsystemsBranchModel"
m (Text replace - "__NOTOC__" to "") |
|||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| − | + | ||
= Subsystem branch models = | = Subsystem branch models = | ||
| − | == Current == | + | 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 == | ||
| Line 19: | Line 36: | ||
* no staging ground for features that are not release-ready | * no staging ground for features that are not release-ready | ||
* feature freeze between last milestone and RC1 | * feature freeze between last milestone and RC1 | ||
| − | * painful cherry-picks | + | * painful cherry-picks while MP exists |
| − | == | + | == 1. Just add subsystem branches == |
| Line 39: | Line 56: | ||
Drawbacks: | 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 == | ||
| + | |||
| + | |||
| + | <pre><nowiki> | ||
| + | defaultsubsystem -------------------------------------------------- | ||
| + | \ / \ / \ / \ / \ / \ / | ||
| + | release -------------------------------------------------------------- | ||
| + | / \ / \ / \ / \ | ||
| + | subsystem2 -------------------------------------------------------- | ||
| + | </nowiki></pre> | ||
| + | |||
| + | |||
| + | * 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 == | ||
| + | |||
| + | |||
| + | <pre><nowiki> | ||
| + | subsystem -------------------------------------------------- | ||
| + | \ / \ / \ / \ / \ / \ / | ||
| + | master ----------------------------------------------------- | ||
| + | \ / \ / | ||
| + | release ------------------------------------------------------- | ||
| + | </nowiki></pre> | ||
| + | |||
| + | |||
| + | * 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) | * 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) | * feature freeze between last milestone and RC1 (for features not in subsystems) | ||
| + | |||
| + | == 4. Combo subsystem model == | ||
| + | |||
| + | |||
| + | <pre><nowiki> | ||
| + | defaultsubsystem -------------------------------------------------- | ||
| + | \ / \ / \ / \ / \ / \ / | ||
| + | master -------------------------------------------------------------- | ||
| + | / \ \ / \ \ | ||
| + | mp / \ ------ / \ ------- | ||
| + | subsystem2 -------------------------------------------------------- | ||
| + | </nowiki></pre> | ||
| + | |||
| + | |||
| + | * 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 | * painful cherry-picks when you're out of the merge window | ||
| − | * subsystem | + | |
| + | == 5. Vish's supercombo subsystem model == | ||
| + | |||
| + | |||
| + | <pre><nowiki> | ||
| + | subsystem ---------------------------------------------------------- | ||
| + | \ / \ / \ / \ / \ / \ / | ||
| + | master ----------++F1-------------++F2------------++F3***RC1----------- | ||
| + | \ / \ / \ / / | ||
| + | folsom-release \ / \ / --RC2---R | ||
| + | fixes/features ---- ---- \ / | ||
| + | RC bugfixes -- | ||
| + | </nowiki></pre> | ||
| + | |||
| + | |||
| + | * 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 | ||
Latest revision as of 23:30, 17 February 2013
Contents
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
