Hey Dmitry, Despite the fact the feature promises performance boost (IIUC) and it's really nice to have it, I agree with Mike's opinion - it's late to continue working on features. Each delay means less time to test it, and we need to focus on quality.
I'm sorry, but I have to say "No" on requested exception. - Igor On Tue, Dec 8, 2015 at 9:55 AM, Mike Scherbakov <mscherba...@mirantis.com> wrote: > Hi Dmitry, > as much as I support the change, and glad that we got time for it, my > opinion is that we should not extend a FFE. I have following reasons to > think this way: > > 1) Feature Freeze is time based milestone, with the rational "FF ensures > that sufficient share of the ReleaseCycle is dedicated to QA, until we > produce the first release candidates. Limiting the changes that affect the > behavior of the software allow for consistent testing and efficient > bugfixing" [1]. Even though this feature will be disabled by default, it is > important to note the first part of this rationale - we need to focus on > stability now, not on features. > 2) 7 FFEs for Fuel [2] I'd subjectively consider as high number, as in total > there are ~25 major blueprints to be delivered. Dmitry, our PTL, > unfortunately is absent for a couple of weeks, but his opinion is quite > similar: "The list of exceptions is much longer than I'd like, and some have > larger impact than I'd like, lets all of us make sure we don't come to > regret granting these exceptions." [3]. Taking any exception further means > moving FF, in fact. That means moving of release date, which I don't think > we should even consider doing. > 3) Exception to exception, in my opinion, should only be allowed in > extremely rare cases for essential features only. When it becomes clear that > the whole release has a major gap or serious issue, which can only be > resolved by finishing an essential feature. I have no evidence to think that > this functionality, which will be disabled by default, can fall into this > category. > 4) Changeset [4] has a change to the packaging spec. Any small change to > packaging after FF imposes additional risk, as there is no good test > automation for such kind of changes. Even if it's just include of a new > file. In case of regression, we may easily lose a day for figuring out what > is wrong and reverting a change. > > I'd like to hear component leads while PTL is absent these days.... > > [1] https://wiki.openstack.org/wiki/FeatureFreeze > [2] > http://lists.openstack.org/pipermail/openstack-dev/2015-December/081131.html > [3] > http://lists.openstack.org/pipermail/openstack-dev/2015-December/081149.html > [4] https://review.openstack.org/#/c/249180/ > > On Mon, Dec 7, 2015 at 2:30 PM Adam Heczko <ahec...@mirantis.com> wrote: >> >> Hello Dmitry, >> I like this idea and very much appreciate it. >> +1 from me :) >> >> A. >> >> On Mon, Dec 7, 2015 at 9:48 PM, Dmitry Mescheryakov >> <dmescherya...@mirantis.com> wrote: >>> >>> Hello folks, >>> >>> I'd like to request extension of current FFE for the feature [1]. During >>> the three FFE days we merged the spec [2] after big discussion and made a >>> couple iterations over the implementation [3]. We had a chat with Bogdan on >>> how to progress and here are the action items still need to be done: >>> * part of the change responsible for RabbitMQ policy need to be >>> upstreamed first to RabbitMQ repo. >>> * the change needs to be review and merged by our library folks. >>> >>> Overall I think that 2-3 more days should be enough to finish it. >>> >>> What do you think folks? >>> >>> Dmitry >>> >>> [1] >>> https://blueprints.launchpad.net/fuel/+spec/rabbitmq-disable-mirroring-for-rpc >>> [2] https://review.openstack.org/247517 >>> [3] https://review.openstack.org/249180 >>> >>> >>> __________________________________________________________________________ >>> 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 >>> >> >> >> >> -- >> Adam Heczko >> Security Engineer @ 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 > > -- > Mike Scherbakov > #mihgen > > __________________________________________________________________________ > 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