> 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 <[email protected]> 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 <[email protected]> > 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 >> <[email protected]> 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 >> > [email protected] >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Mike Scherbakov > #mihgen > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
