Open Stack

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