Thanks a lot for the explanation, Jeremy, now I understand more about the 2
models. There is no much difference between them, except for release
managment, I think. OpenStack use permanent major release(like icehouse,
havana) branches for long term support(i.e., after icehouse is released, a
security fix needs to backport to havana release, then the ideal NVEI
model's one production branch is not enough for tagging).
Since our project is OpenStack related and has LTS requirement, we decide
to choose the community's model.
--
Le Tian Ren
From: Jeremy Stanley <fu...@yuggoth.org>
To: Le Tian Ren/China/IBM@IBMCN,
Cc: openstack-infra@lists.openstack.org, retael...@gmail.com
Date: 2014/06/12 03:38
Subject: Re: [OpenStack-Infra] About openstack branching model and
openstack branch stable/icehouse
On 2014-06-11 18:00:30 +0800 (+0800), Le Tian Ren wrote:
> This thread is about branching model, since my team just put a
> project on stackforge and ready to create a milestone-proposed
> branch for final release to support openstack icehouse release.
This is probably a topic better addressed by the release managers
rather than the systems automation (Infrastructure) team, but
most/all of them subscribe to this mailing list too and may chime in
with better answers...
> Now it's time for us to consider branching stategy(parallel
> development) on github, guess there are 2 options:
>
> a popular NVIE model,
> http://nvie.com/posts/a-successful-git-branching-model/
>
> OpenStack branching model,
> https://wiki.openstack.org/wiki/Branch_Model
[...]
OpenStack's server project branch model is basically a subset of
NVIE, simplified by use of a topic-branch-like code review workflow
and pre-merge automated testing ("trunk gating").
> 1. OpenStack's master branch works as both the development and
> master (production ready) branch of the NVIE model together,
> right? I wonder 2 main branches vs 1 main branch, which one is
> better and why?
Among other reasons, we ultimately want our equivalent of the
"develop" branch to be usable at all times since that improves
developer experience dramatically (trying to develop patches to
broken code makes it much harder to test that your patches actually
work). We try to consider developers as first-class users of the
software in that regard.
> 2. I noticed that there are stable/icheouse, stable/havana
> branches on github web GUI of many openstack projects like nova,
> heat, ironic. To what branches mentioned in the above 2 models can
> these stable/* mapped, supporting release branches? hot fix
> branches?
I would consider them additional separate "master" branches in NVIE
terminology. They never merge back into the trunk master/develop
branch, and are purely a parallel continuation of backported fixes
to previous releases. This provides much cleaner access to reviewed
and tested backports of bug fixes consumable by downstream
distributors and deployers, rather than expecting each to do the
backporting work on their own independently from our developers.
> BTW, if I git clone these projects, I cannot see those stable/*
> branches with git branch.. why?
That's just the way Git works. You need to pass the -a switch to the
branch subcommand if you want to see remote branches you're not
tracking.
> And when were they created in a OpenStack release cycle and what
> for?
[...]
These are the stable support branches for downstreams who don't want
to always consume from trunk and instead want a vetted subset of
fixes for security vulnerabilities and severe usability bugs without
having to consume new features and forced configuration changes.
They are created at each release and track the backported fixes and
stable point release tags associated with those major release
versions.
--
Jeremy Stanley
_______________________________________________
OpenStack-Infra mailing list
OpenStack-Infra@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-infra
