Review of our Branching and Release model
(Proposed discussion topic for Design Summit)
Nova has become a complex project, with multiple stakeholders that are only loosely aligned. This is a good thing!
However, our current version control branching / release model is perhaps no longer suited to our success. A large motivator for DVCSs such as bazaar and git was to support less centralized development models, but we're not yet taking full advantage.
I'd like to see the following points of tensions resolved:
* It should always be possible to commit a feature if we want to (wherever we are in the release process), rather than having to track it manually
* It should be possible to produce stable releases nonetheless (this is normally solved with a stablization/
* We should allow different stakeholders (Anso, Citrix, NTT, Ozone, others) to have their own branches if they so desire, and this should lead to greater harmony and smoother development, not to forking. (A release could follow a window where those branches are merged together)
* Blueprints and bugs should be collaboration opportunities, not merely boxes which must be ticked before something gets merged. If something sucks, we can revert it / fix it.
* If we break a developer branch, we should not be compelled immediately to revert / hotfix (unless that patch has been promoted to a branch where we are making these guarantees)
There are a number of "well known" models:
The "NVIE" model (dev branch merges from feature branches with stabilization branches):
The linux kernel model (very interesting because it's open source and has undergone some changes in response to problems):
I'm sure there are plenty more - input please!
A few remarks to set the expectations -- our current model is the Linux kernel model, with Linus = nova-core. It doesn't prevent developer branches (I know Anso and citrix have their dev branches). So I'm not sure what we are trying to fix exactly. -- ttx