Re: [openstack-dev] [qa] Duplicated test effort development
Hi, 2013/10/30 Christopher Yeoh cbky...@gmail.com: Hi, It looks like we have lots of people writing tests at the moment which is great, but the downside is we're starting to see people accidentally writing tests for the same APIs at the same time. There is a google spreadsheet which covers the Nova v2 API where we can reserve what tests we're working on but I don't think we have an easily editable list for the other APIs. I don't think blueprints/bugs work so well at this, and I don't think we have anything else setup at the moment, so as a temporary measure I've created an etherpad here: https://etherpad.openstack.org/p/TempestTestDevelopment which links to the Nova v2 API spreadsheet and to a new etherpad for glance apis (this would ideally be a spreadsheet as well but in the meantime would work as a tool to avoid duplicated effort). Add new links if you're working on new tests for other APIs. I think it'd be a really good idea if we all checked these lists and add what we're about to work on before starting to write new tests to avoid the situation where we have almost identical changesets in the review queue from different people. Thanks for preparing this etherpad page. To avoid the duplicated works of Tempest, I also have added some contents about separation negative tests from positive test files. To separate negative tests, some patches have been queued already in Gerrit. I wrote these patches' URLs on the etherpad. I'm glad if developers check this contents before starting this work. Thanks Ken'ichi Ohmichi ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Duplicated test effort development
a huge +1! thanks, chris, noticed the spreadsheet before, and have add some contents I have been working on. I think more people should know that, avoid conflicting. 2013/10/31 Zhu Bo bo...@linux.vnet.ibm.com hi, Chris thanks for your work. It's a good way. And how about creating a blue-print and putting these link on it? Some guys have been familiar with looking for work items from blue-print, and writing something in hacking guide may be better. On 2013年10月30日 21:10, Christopher Yeoh wrote: On Wed, Oct 30, 2013 at 11:18 PM, Steven Hardy sha...@redhat.com wrote: On Wed, Oct 30, 2013 at 11:00:22PM +1030, Christopher Yeoh wrote: snip I don't think blueprints/bugs work so well at this, and I don't think we have anything else setup at the moment, so as a temporary measure I've created an etherpad here: Can I ask why? Surely blueprints for new features (in this case the feature is test coverage for $api) are exactly what the normal openstack process dictates, and is what most folks are familiar with? Just to be clear - Its not that I think that we shouldn't have blueprints which covers the work being done (we should!), but they don't work so well at allowing people to see a good summary of what test coverage for an API we have (some of which may have been done a long time ago), what needs to be done and the quite fine grained allocation of what people are working on. For example, see the tempest coverage for the Nova v2 API spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc#gid=0 Anyway, I added the keystone test I'm working on (which has a BP) to the etherpad, and definitely +1 on not duplicating effort, by whatever means ;) Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing listOpenStack-dev@lists.openstack.orghttp://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 -- *---* *Lingxian Kong* Huawei Technologies Co.,LTD. IT Product Line CloudOS PDU China, Xi'an Mobile: +86-18602962792 Email: konglingx...@huawei.com; anlin.k...@gmail.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [qa] Duplicated test effort development
Hi, It looks like we have lots of people writing tests at the moment which is great, but the downside is we're starting to see people accidentally writing tests for the same APIs at the same time. There is a google spreadsheet which covers the Nova v2 API where we can reserve what tests we're working on but I don't think we have an easily editable list for the other APIs. I don't think blueprints/bugs work so well at this, and I don't think we have anything else setup at the moment, so as a temporary measure I've created an etherpad here: https://etherpad.openstack.org/p/TempestTestDevelopment which links to the Nova v2 API spreadsheet and to a new etherpad for glance apis (this would ideally be a spreadsheet as well but in the meantime would work as a tool to avoid duplicated effort). Add new links if you're working on new tests for other APIs. I think it'd be a really good idea if we all checked these lists and add what we're about to work on before starting to write new tests to avoid the situation where we have almost identical changesets in the review queue from different people. Regards, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [qa] Duplicated test effort development
On Wed, Oct 30, 2013 at 11:18 PM, Steven Hardy sha...@redhat.com wrote: On Wed, Oct 30, 2013 at 11:00:22PM +1030, Christopher Yeoh wrote: snip I don't think blueprints/bugs work so well at this, and I don't think we have anything else setup at the moment, so as a temporary measure I've created an etherpad here: Can I ask why? Surely blueprints for new features (in this case the feature is test coverage for $api) are exactly what the normal openstack process dictates, and is what most folks are familiar with? Just to be clear - Its not that I think that we shouldn't have blueprints which covers the work being done (we should!), but they don't work so well at allowing people to see a good summary of what test coverage for an API we have (some of which may have been done a long time ago), what needs to be done and the quite fine grained allocation of what people are working on. For example, see the tempest coverage for the Nova v2 API spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc#gid=0 Anyway, I added the keystone test I'm working on (which has a BP) to the etherpad, and definitely +1 on not duplicating effort, by whatever means ;) Steve ___ 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] [qa] Duplicated test effort development
hi, Chris thanks for your work. It's a good way. And how about creating a blue-print and putting these link on it? Some guys have been familiar with looking for work items from blue-print, and writing something in hacking guide may be better. On 2013?10?30? 21:10, Christopher Yeoh wrote: On Wed, Oct 30, 2013 at 11:18 PM, Steven Hardy sha...@redhat.com mailto:sha...@redhat.com wrote: On Wed, Oct 30, 2013 at 11:00:22PM +1030, Christopher Yeoh wrote: snip I don't think blueprints/bugs work so well at this, and I don't think we have anything else setup at the moment, so as a temporary measure I've created an etherpad here: Can I ask why? Surely blueprints for new features (in this case the feature is test coverage for $api) are exactly what the normal openstack process dictates, and is what most folks are familiar with? Just to be clear - Its not that I think that we shouldn't have blueprints which covers the work being done (we should!), but they don't work so well at allowing people to see a good summary of what test coverage for an API we have (some of which may have been done a long time ago), what needs to be done and the quite fine grained allocation of what people are working on. For example, see the tempest coverage for the Nova v2 API spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AmYuZ6T4IJETdEVNTWlYVUVOWURmOERSZ0VGc1BBQWc#gid=0 Anyway, I added the keystone test I'm working on (which has a BP) to the etherpad, and definitely +1 on not duplicating effort, by whatever means ;) Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto: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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
