Hi folks, I thought long and hard as how to not make this an exception and came up with the following.
I would be in favor (+1) of this particular feature addition, on the conditions that: 1. This does not set a precedent that features will be backported by the typical +2/+2/+W 2. Any feature backport to a stable branch requires a vote on the mailing list With the above 1 and 2 in place, this is not an exception; it is a fact of how our project operates. Note OpenStack stable maintenance does not permit backs of features at all :) I really want stable to mean "low rate of change" and if we are backporting features, we will not have a low rate of change. A low rate of change repository generally leads to stability over time. If we continually backport features into the stable branch, the stable branch will be high rate of change, and will not lead to stability. Regards -steve From: Steven Dake <std...@cisco.com<mailto:std...@cisco.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Saturday, February 20, 2016 at 6:38 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty From: Steven Dake <std...@cisco.com<mailto:std...@cisco.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Date: Saturday, February 20, 2016 at 6:28 AM To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>> Subject: [openstack-dev] [kolla][vote] port neutron thin containers to stable/liberty Folks, There were not enough core reviewers to pass a majority approval of the neutron thin container backport idea, so we separated it out from fixing stable/liberty itself. I am going to keep voting open for *2* weeks this time. The reason for the two weeks is I would like a week of discussion before people just blindly vote ;) Voting begins now and concludes March 4th. Since this is a policy decision, no veto votes are permitted, just a +1 and a -1. Abstaining is the same as voting -1. Just kicking this conversation off, this feels a lot like an exception to me. The problem with exceptions is that if we make one, we set a precedent that we will make exceptions in the future. This means stable/* could become free for feature backport requests of all types. For example, Id like reconfigure in stable/liberty. I really need it for $$DAYJOB$$ but I don't think its the right way to manage the stable/liberty branch (backporting reconfigure). In the same way, I think thin neutron containers are in the same category - a feature. We have already made a decision we are going to fix Liberty so its stable because of data loss problems. While we are using new features to do this, the rationale is that we have a highly critical defect with the implementation and design of stable/liberty that needs to be rectified. In my mind, this is a different scenario then a backport of a pure feature for feature's sake. Even backporting reconfgiure would make more sense under a critical defect (the fact that COPY_ONCE doesn't restart containers on redeploy so once a config is deployed, its permanent). I can't think of such argument for neutron thin containers although it is 6:30AM :). I'd like to hear that argument. Regards -steve
__________________________________________________________________________ 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
