Open Stack

James E. Blair wrote:
> Vish, Thierry, and I spent some time together this week at UDS trying to
> reconcile their needs and your suggestions.  I believe Thierry is going
> to write that up and send it to the list soon.

While at UDS we took some time to discuss a subsystem branch models that
would work for Vish (PTL/developer), Jim (CI/infra) and me (release
time). We investigated various models and came up with "Vish's
supercombo subsystem model" (see model 5 at the bottom of
http://wiki.openstack.org/SubsystemsBranchModel for a graph).

In this model:

* You have a "master" branch which contains release-ready features and
bugfixes. Milestones are cut directly from it.

* Subsystem branches with area experts are used wherever possible. The
subsystem maintainer should maintain this branch so that it can directly
be merged into master when "ready" (all or nothing). Subsystem
maintainers are allowed to propose a merge commit to master.

* Bugfixes get proposed directly to master

* Features can be directly proposed to master, although they should be
redirected to a subsystem branch when one exists for that area

* Only features that are release-ready should be accepted into master.
Final approval of merges on master will therefore be limited to the
corresponding project release team.

* Milestones are directly cut from master. A couple of days before each
milestone, we will have a soft freeze during which only bugfixes are merged

* Between the last milestone and RC1, a soft freeze is enforced during
which only bugfixes are merged (can last for a couple weeks)

* In order to limit the master freeze, at RC1 and until release, a
specific release branch is cut from master. That specific release branch
directly gets release-critical (targeted) bugfixes, and gets merged back
into master periodically.

Benefits of this model:
* We enable subsystems, which for larger projects let people specialize
on an area of the code and avoids having to be an expert in all things
* Subsystems become a staging ground for features that are not release-ready
* Avoid painful cherry-picks between RC1 and release
* Release part of the model can be used on smaller projects without
necessarily adopting the rest of the model (subsystem and release team
approval on master)

Pain points:
* For smaller projects, you have to use subsystems if you want a staging
ground for features (though you could also advertise given feature
branches). Those projects could certainly use an "experimental"
subsystem and adopt that model, though.
* You still need project-core reviewers on master branch for bugfixes
and features directly proposed
* Master is not always open, there are soft-frozen periods (could be
seen as a benefit to get people to focus on bugfixes though)

-- 
Thierry Carrez (ttx)
Release Manager, OpenStack