> +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 <[email protected]> wrote: > +1 > > On Thu, Sep 11, 2014 at 5:05 PM, Anastasia Urlapova < > [email protected]> 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 <[email protected]> >> 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 <[email protected]> >>> 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 >>> > <[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 >>> >>> >>> >>> -- >>> Best regards, >>> Nick Markov >>> >>> _______________________________________________ >>> 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 >> >> > > > -- > 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 > [email protected] > > _______________________________________________ > 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
