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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp