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