[openstack-dev] [Fuel] Experimental features and how they affect HCF
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
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
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
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
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
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
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
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
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 nmar...@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 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
+1 On Thu, Sep 11, 2014 at 5:05 PM, Anastasia Urlapova aurlap...@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 nmar...@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 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 ___ OpenStack-dev mailing list OpenStack-dev@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 vkuk...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
+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 vkuk...@mirantis.com wrote: +1 On Thu, Sep 11, 2014 at 5:05 PM, Anastasia Urlapova aurlap...@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 nmar...@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 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 ___ OpenStack-dev mailing list OpenStack-dev@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,
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
On 11 Sep 2014, at 09:19, 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 -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
Mike, i've just want to say, if feature isn't ready for production use and we have no other choice, we should provide detailed limitations and examples of proper use. On Thu, Sep 11, 2014 at 5:58 PM, Tomasz Napierala tnapier...@mirantis.com wrote: On 11 Sep 2014, at 09:19, 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 -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com ___ 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
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
Mike, i've just want to say, if feature isn't ready for production use and we have no other choice, we should provide detailed limitations and examples of proper use. Fully agree, such features should become experimental. We should have this information in release notes. Basically, Patching of OpenStack becomes as such, unfortunately. We still have bugs, and there is no guarantee that we won't find more. So, let's add experimental tag to issues around Zabbix Patching of OpenStack. On Thu, Sep 11, 2014 at 6:19 PM, Anastasia Urlapova aurlap...@mirantis.com wrote: Mike, i've just want to say, if feature isn't ready for production use and we have no other choice, we should provide detailed limitations and examples of proper use. On Thu, Sep 11, 2014 at 5:58 PM, Tomasz Napierala tnapier...@mirantis.com wrote: On 11 Sep 2014, at 09:19, 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 -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com ___ 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
Re: [openstack-dev] [Fuel] Experimental features and how they affect HCF
QA-agree. -- nurla On Thu, Sep 11, 2014 at 6:28 PM, Mike Scherbakov mscherba...@mirantis.com wrote: Mike, i've just want to say, if feature isn't ready for production use and we have no other choice, we should provide detailed limitations and examples of proper use. Fully agree, such features should become experimental. We should have this information in release notes. Basically, Patching of OpenStack becomes as such, unfortunately. We still have bugs, and there is no guarantee that we won't find more. So, let's add experimental tag to issues around Zabbix Patching of OpenStack. On Thu, Sep 11, 2014 at 6:19 PM, Anastasia Urlapova aurlap...@mirantis.com wrote: Mike, i've just want to say, if feature isn't ready for production use and we have no other choice, we should provide detailed limitations and examples of proper use. On Thu, Sep 11, 2014 at 5:58 PM, Tomasz Napierala tnapier...@mirantis.com wrote: On 11 Sep 2014, at 09:19, 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 -- Tomasz 'Zen' Napierala Sr. OpenStack Engineer tnapier...@mirantis.com ___ 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
