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. Regards, Igor Marnat On Wed, Aug 26, 2015 at 1:04 PM, Thierry Carrez <thie...@openstack.org> wrote: > Dmitry Borodaenko wrote: >> TL;DR was actually hidden in the middle of the email, here's an even >> shorter version: >> >> 0) we're suffering from closing master for feature work for too long >> >> 1) continuously rebased future branch is most likely a no-go >> >> 2) short FF (SCF and stable branch after 2 weeks) is an option for 8.0 >> >> 3) short FF with stable in a separate internal gerrit was also proposed >> >> 4) merits and cost of enabling CI setup for private forks should be >> carefully considered independently from other options > > Should come as no surprise that I encourage you to follow (2), > especially as we work to further align Fuel with OpenStack ways so that > it can be added as an official project team. > > 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. It usually takes 2 to 4 weeks for > OpenStack projects to get to that stage, but you could get there in 2 > days or 5 weeks and it would still work (the key is to publish at least > one release candidate before the end of the cycle). > > It's a balance between the pain of backporting fixes and the pain of > freezing master. At one point the flow of fixes slows down enough and/or > the pressure to unfreeze master becomes too strong: that's when you > should create the release branch. > > Hope this helps, > > -- > Thierry Carrez (ttx) > > __________________________________________________________________________ > 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 __________________________________________________________________________ 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