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 <ikalnit...@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 > <mscherba...@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 <ikalnit...@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 >>> <mscherba...@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@lists.openstack.org >>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> > >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> OpenStack-dev@lists.openstack.org >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> -- >> Mike Scherbakov >> #mihgen >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Best regards, Nick Markov _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
