Open Stack

Dmitry, thank you for getting our conversations and opinions spread across
different communications channels collected here in one cohesive email.

I like Ruslan's summary, and I support every line of what Ruslan has
written here.

> Note that the "two weeks" is not really a hard requirement (could be
> more, or less). In this model you need to come up with a release
> candidate, which is where we create the release branch, which becomes a
> stable branch at the end of the cycle.

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.

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).

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.

Thanks,


On Wed, Aug 26, 2015 at 8:44 AM Ruslan Kamaldinov <rkamaldinov at mirantis.com>
wrote:

> On Wed, Aug 26, 2015 at 4:23 AM, Igor Marnat <imarnat at mirantis.com> wrote:
>
>> Thierry, Dmitry,
>> key point is that we in Fuel need to follow as much community adopted
>> process as we can, and not to introduce something Fuel specific. We
>> need not only to avoid forking code, but also to avoid forking
>> processes and approaches for Fuel.
>>
>> Both #2 and #3 allow it, making it easier for contributors to
>> participate in the Fuel.
>>
>> #3 (having internal repos for pre-release preparation, bug fixing and
>> small custom features) from community perspective is the same as #2,
>> provided that all the code from these internal repos always ends up
>> being committed upstream. Purely internal logistics.
>>
>> The only one additional note from my side is that we might want to
>> consider an approach slightly adopted similar to what's there in
>> Puppet modules. AFAIK, they are typically released several weeks later
>> than Openstack code. This is natural for Fuel as it depends on these
>> modules and packaging of Openstack.
>>
>
> I also think we should go with option #2. What it means to me
> * Short FF: create stable branch couple of weeks after FF for upstream Fuel
> * Untie release schedule for upstream Fuel and MOS. This should be two
> separate schedules
> * Fuel release schedule should be more aligned with OpenStack release
> schedule. It should be similar to upstream OpenStack Puppet schedule,
> where Puppet modules are developed during the same time frame as OpenStack
> and released just a few weeks later
> * Internally vendors can have downstream branches (which is option  #3
> from Dmitry’s email)
>
> Thanks,
> Ruslan
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150827/bbe7b4ba/attachment.html>