Open Stack

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