Open Stack

On 1/28/2016 9:35 AM, Renat Akhmerov wrote:
>
>> On 27 Jan 2016, at 19:14, Matt Riedemann <mriedem at linux.vnet.ibm.com> wrote:
>>
>> Starting with stable/liberty, each project now owns when to do point releases for their stable branches (rather than a large coordinated stable branch point release that the stable-maint-core team does).
>>
>> There are a couple of core projects which have not done a stable/liberty point release since the liberty GA, and Mistral is one of them.
>>
>> I started looking at how many changes have been merged into stable/liberty and there are quite a few [1]. However, I also see that some of them, e.g. [2], are backporting features, which is in clear violation of the stable branch policy for appropriate fixes [3].
>
> Matt, I must admit that it violates the policy. I guess to some extent it was done by mistake w/o realizing that it was a violation. However, this patch doesn’t bring really a new functionality, actions could be considered rather plugins to the main functionality. Visibly it doesn’t introduce any issues. Anyway, you’re right here, we’ll be more careful about backporting patches.
>
> Thanks for pointing to this.
>
>> There is currently only a 'has-stable-branches' [4] tag in the governance repo which means a project just has stable branches.
>>
>> ttx is planning on proposing a new tag, something like follows-stable-policy, which would basically indicate whether or not a project is following the stable branch policy, which in this case Mistral would not be getting that tag.
>
> Ok
>
>> I guess the question I have at this point is whether or not Mistral should even release a 1.0.1 with these types of changes in stable/liberty, or if they should be reverted before a 1.0.1 release to make the branch align with the stable branch policy. The answer might depend on how many of these types of changes have been backported and merged (I haven't scrubbed the list).
>
> I’ve gone through the list of backported patches again. All other patches are either bug fixes, performance tuning (in fact, bug fixes also) or syncing with requirements. I would personally prefer to keep “Trove actions” patch in stable branch, like I said it doesn’t alter anything serious, it just plugs in more actions into the language and practically doesn’t create any problems. I’m not insisting though.
>
> FYI: We’re also planning to backport some changes related with security to liberty, some of our users need them very much it’s a blocker now for them to go into production. Those changes though are not implemented yet. Technically it will be new functionality but it will be covering gaps with security that we have now. I wonder if it would violate the policy too. Once we implement it I will get in touch with the community and discuss if it is appropriate to backport.
>
>
> Thanks
>
> Renat Akhmerov
> @ Mirantis Inc.
>
>
> __________________________________________________________________________
> 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
>

With regards to the trove 'plugin' stuff, it adds a new dependency on 
python-troveclient which was not in sahara 1.0.0 in liberty GA, so IMO 
it's not valid to release that in 1.0.1 and expect people to have to 
start packaging and picking up python-troveclient in a point release. 
That should be reverted.

WRT the security stuff, I guess I wouldn't consider new functionality 
for security as a feature, but it depends on the implementation I 
suppose, I don't know the details.

-- 

Thanks,

Matt Riedemann