On Wed, Aug 26, 2015 at 4:23 AM, Igor Marnat <imar...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev