Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150826/8870649d/attachment.html>