Open Stack

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 <thierry at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev