<div dir="ltr">Dmitry, thank you for getting our conversations and opinions spread across different communications channels collected here in one cohesive email.<div><br></div><div>I like Ruslan's summary, and I support every line of what Ruslan has written here.</div><div><br></div><div>> <span style="font-size:13.1999998092651px;line-height:19.7999992370605px">Note that the "two weeks" is not really a hard requirement (could be</span></div><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">> more, or less). In this model you need to come up with a release</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">> candidate, which is where we create the release branch, which becomes a</span><br style="font-size:13.1999998092651px;line-height:19.7999992370605px"><span style="font-size:13.1999998092651px;line-height:19.7999992370605px">> stable branch at the end of the cycle. </span><div><br><div>Thierry - I appreciate your feedback. My thinking here is quite similar (if not the same): time required for not merging new functionality should depend on balance between amount of feature-related commits & bugfixes. If there # of bugfixes >> # feature-commits, then I'd say it's too expensive to have two branches with the need to backport every single bugfix.</div><div><br></div><div>One of the things behind of this branching strategy is to change our engineering processes in such a way, that we simply have more commits related to features and less on bugfixes after FF date. In order to achieve this, I'd expect us to be able to form strong bugfix team which will work across release, so bugs are not collected by FF (and do other incremental improvements).</div><div><br></div><div>We might want to consider making a flexible date when we create stable branch, based on # of bugfixes vs # of feature-related commits. But frankly, for simplicity, I'd pick the date and work towards it - so everyone's expectations are aligned upfront.</div><div><br></div><div>Thanks,<br><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Aug 26, 2015 at 8:44 AM Ruslan Kamaldinov <<a href="mailto:rkamaldinov@mirantis.com">rkamaldinov@mirantis.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Aug 26, 2015 at 4:23 AM, Igor <span>Marnat</span> <span dir="ltr"><<a href="mailto:imarnat@mirantis.com" target="_blank"><span>imarnat</span>@<span>mirantis</span>.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thierry, Dmitry,<br>
key point is that we in Fuel need to follow as much community adopted<br>
process as we can, and not to introduce something Fuel specific. We<br>
need not only to avoid forking code, but also to avoid forking<br>
processes and approaches for Fuel.<br>
<br>
Both #2 and #3 allow it, making it easier for contributors to<br>
participate in the Fuel.<br>
<br>
#3 (having internal repos for pre-release preparation, bug fixing and<br>
small custom features) from community perspective is the same as #2,<br>
provided that all the code from these internal repos always ends up<br>
being committed upstream. Purely internal logistics.<br>
<br>
The only one additional note from my side is that we might want to<br>
consider an approach slightly adopted similar to what's there in<br>
Puppet modules. AFAIK, they are typically released several weeks later<br>
than Openstack code. This is natural for Fuel as it depends on these<br>
modules and packaging of Openstack.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I also think we should go with option #2. What it means to me</div><div>* Short FF: create stable branch couple of weeks after FF for upstream Fuel</div><div>* Untie release schedule for upstream Fuel and MOS. This should be two separate schedules</div><div>* Fuel release schedule should be more aligned with <span>OpenStack</span> release schedule. It should be similar to upstream <span>OpenStack</span> Puppet schedule, where Puppet modules are developed during the same time frame as <span>OpenStack</span> and released just a few weeks later</div><div>* Internally vendors can have downstream branches (which is option  #3 from Dmitry’s email)</div><div><br></div><div>Thanks,</div><div><span>Ruslan</span> </div></div></div></div>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>