Open Stack

> +1, absolutely agree, but we should determine count of allowed bugs for
experimental features against severity.
Anastasia, can you please give an example? I think we should not count them
at all. Experimental features, if they are isolated, they can be in any
stated. May be just very beginning of the development cycle.

On Thu, Sep 11, 2014 at 5:20 PM, Vladimir Kuklin <vkuklin at mirantis.com>
wrote:

> +1
>
> On Thu, Sep 11, 2014 at 5:05 PM, Anastasia Urlapova <
> aurlapova at mirantis.com> wrote:
>
>> > I think we should not count bugs for HCF criteria if they affect only
>> > experimental feature(s).
>>
>> +1, absolutely agree, but we should determine count of allowed bugs for
>> experimental features against severity.
>>
>> On Thu, Sep 11, 2014 at 2:13 PM, Nikolay Markov <nmarkov at mirantis.com>
>> wrote:
>>
>>> Probably, even "experimental feature" should at least pretend to be
>>> working, anyway, or it shouldn't be publically announced. But I think
>>> it's important to describe limitation of this features (or mark some
>>> of them as "untested") and I think list of known issues with links to
>>> most important bugs is a good approach. And tags will just make things
>>> simpler.
>>>
>>> On Thu, Sep 11, 2014 at 1:05 PM, Igor Kalnitsky <ikalnitsky at mirantis.com>
>>> wrote:
>>> >> May be we can use tag per feature, for example "zabbix"
>>> >
>>> > Tags are ok, but I still think that we can mention at least some
>>> > significant bugs. For example, if some feature doesn't work in some
>>> > deployment mode (e.g. simple, with ceilometer, etc) we can at least
>>> > notify users so they even don't try.
>>> >
>>> > Another opinions?
>>> >
>>> >
>>> > On Thu, Sep 11, 2014 at 11:45 AM, Mike Scherbakov
>>> > <mscherbakov at mirantis.com> wrote:
>>> >>> if we point somewhere about knowing issues in those experimental
>>> features
>>> >> there are might be dozens of bugs.
>>> >> May be we can use tag per feature, for example "zabbix", so it will
>>> be easy
>>> >> to search in LP all open bugs regarding Zabbix feature?
>>> >>
>>> >> On Thu, Sep 11, 2014 at 12:11 PM, Igor Kalnitsky <
>>> ikalnitsky at mirantis.com>
>>> >> wrote:
>>> >>>
>>> >>> > I think we should not count bugs for HCF criteria if they affect
>>> only
>>> >>> > experimental feature(s).
>>> >>>
>>> >>> +1, I'm totally agree with you - it makes no sense to count
>>> >>> experimental bugs as HCF criteria.
>>> >>>
>>> >>> > Any objections / other ideas?
>>> >>>
>>> >>> I think it would be great for customers if we point somewhere about
>>> >>> knowing issues in those experimental features. IMHO, it should help
>>> >>> them to understand what's wrong in case of errors and may prevent bug
>>> >>> duplication in LP.
>>> >>>
>>> >>>
>>> >>> On Thu, Sep 11, 2014 at 10:19 AM, Mike Scherbakov
>>> >>> <mscherbakov at mirantis.com> wrote:
>>> >>> > Hi all,
>>> >>> > what about using "experimental" tag for experimental features?
>>> >>> >
>>> >>> > After we implemented feature groups [1], we can divide our
>>> features and
>>> >>> > for
>>> >>> > complex features, or those which don't get enough QA resources in
>>> the
>>> >>> > dev
>>> >>> > cycle, we can declare as experimental. It would mean that those
>>> are not
>>> >>> > production ready features.
>>> >>> > Giving them live still in experimental mode allows early adopters
>>> to
>>> >>> > give a
>>> >>> > try and bring a feedback to the development team.
>>> >>> >
>>> >>> > I think we should not count bugs for HCF criteria if they affect
>>> only
>>> >>> > experimental feature(s). At the moment, we have Zabbix as
>>> experimental
>>> >>> > feature, and Patching of OpenStack [2] is under consideration: if
>>> today
>>> >>> > QA
>>> >>> > doesn't approve it to be as ready for production use, we have no
>>> other
>>> >>> > choice. All deadlines passed, and we need to get 5.1 finally out.
>>> >>> >
>>> >>> > Any objections / other ideas?
>>> >>> >
>>> >>> > [1]
>>> >>> >
>>> >>> >
>>> https://github.com/stackforge/fuel-specs/blob/master/specs/5.1/feature-groups.rst
>>> >>> > [2] https://blueprints.launchpad.net/fuel/+spec/patch-openstack
>>> >>> > --
>>> >>> > Mike Scherbakov
>>> >>> > #mihgen
>>> >>> >
>>> >>> >
>>> >>> > _______________________________________________
>>> >>> > OpenStack-dev mailing list
>>> >>> > OpenStack-dev at lists.openstack.org
>>> >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>> >
>>> >>>
>>> >>> _______________________________________________
>>> >>> OpenStack-dev mailing list
>>> >>> OpenStack-dev at lists.openstack.org
>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Mike Scherbakov
>>> >> #mihgen
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> OpenStack-dev mailing list
>>> >> OpenStack-dev at lists.openstack.org
>>> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>> >>
>>> >
>>> > _______________________________________________
>>> > OpenStack-dev mailing list
>>> > OpenStack-dev at lists.openstack.org
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>>>
>>> --
>>> Best regards,
>>> Nick Markov
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
>
> --
> Yours Faithfully,
> Vladimir Kuklin,
> Fuel Library Tech Lead,
> Mirantis, Inc.
> +7 (495) 640-49-04
> +7 (926) 702-39-68
> Skype kuklinvv
> 45bk3, Vorontsovskaya Str.
> Moscow, Russia,
> www.mirantis.com <http://www.mirantis.ru/>
> www.mirantis.ru
> vkuklin at mirantis.com
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Mike Scherbakov
#mihgen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140911/b2967092/attachment.html>