Open Stack

Hi,
I read the qa-meeting log[1]. And I registered a blueprint[2] for
tracking and avoiding duplication.

I think if we put "Partially Implements: blueprint
add-scenario-tests-in-icehouse" in the commit message,
we can avoid the duplication and tracking the scenarios. Because the
commit subject and the link will be wrote automatically in the
whiteboard.
However, I'm not sure whether we can associate with multiple
blueprints such as BP:lbaas-scenario-tests and
add-scenario-tests-in-icehouse though.
Is this make sense?

[1] http://eavesdrop.openstack.org/meetings/qa/2013/qa.2013-11-14-17.02.log.html
[2] https://blueprints.launchpad.net/tempest/+spec/add-scenario-tests-in-icehouse

Any comments and suggestions are welcome.

Best Regards,
-- Masayuki Igawa


On Mon, Nov 18, 2013 at 10:07 PM, Salvatore Orlando <sorlando at nicira.com> wrote:
>
> I've pushed https://review.openstack.org/#/c/56923/ trying to follow this protocol.
>
> Salvatore
>
>
> On 14 November 2013 16:38, Zhi Kun Liu <liuzhikun at gmail.com> wrote:
>>
>> +1, This is a great idea.  We could consider it as a general process for all tests.
>>
>>
>> 2013/11/14 Koderer, Marc <m.koderer at telekom.de>
>>
>>> Hi all,
>>>
>>> I think we have quite the same issue with the neutron testing. I already put it on the agenda for the QA meeting for today.
>>> Let's make it to a general topic.
>>>
>>> Regards
>>> Marc
>>> ________________________________________
>>> From: Giulio Fidente [gfidente at redhat.com]
>>> Sent: Thursday, November 14, 2013 6:23 AM
>>> To: openstack-dev at lists.openstack.org
>>> Subject: Re: [openstack-dev] [qa] Tracking development of scenario tests
>>>
>>> On 11/14/2013 12:24 AM, David Kranz wrote:
>>> > 1. Developer checks in the zeroth version of a scenario test as work in
>>> > progress. It contains a description of the test, and     possibly work
>>> > items.  This will "claim" the area of the proposed scenario to avoid
>>> > duplication and allow others to comment through gerrit.
>>> > 2. The developer pushes new versions, removing work in progress if the
>>> > code is in working state and a review is desired and/or others will be
>>> > contributing to the scenario.
>>> > 3. When finished, any process-oriented content such as progress tracking
>>> > is removed and the test is ready for final review.
>>>
>>> +1 , the description will eventually contribute to documenting the scenarios
>>>
>>> yet the submitter (step 1) remains in charge of adding to the draft the
>>> reviewers
>>>
>>> how about we map at least one volunteer to each service (via the HACKING
>>> file) and ask submitters to add such a person as reviewer of its drafts
>>> when the tests touch the service? this should help avoid tests duplication.
>>>
>>> I very much like the idea of using gerrit for this
>>> --
>>> Giulio Fidente
>>> GPG KEY: 08D733BA | IRC: giulivo
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>