On 1/28/2016 9:35 AM, Renat Akhmerov wrote:
On 27 Jan 2016, at 19:14, Matt Riedemann <mrie...@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-requ...@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
__________________________________________________________________________
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
