Open Stack

To be clear, that was a +1 for Mark's suggestion:

> In cases like that, I'd be of a mind to go "+2 Awesome! Thanks for
> catching this! It would be great to have a unit test for this, but it's
> clear the current code is broken so I'm fine with merging the fix
> without a test". You could say it's now the reviewers responsibility to
> merge a test, but if that requirement then turns off reviewers even
> reviewing such a patch, then that doesn't help either.


On 12 November 2013 11:29, Michael Bright <mjbrightfr at gmail.com> wrote:

>
> +1 also.
> I spent less than half the time on my first fix (so far) understanding the
> problem, reproducing it, coding it and learning about the code review
> system.
>
> Much more than half the time was spent on reverse engineering existing
> tests to be able to add new ones (which had to use features not used by the
> existing tests) and asking for advice even on where to add the tests.
>
> It would have been more efficient for everyone had some test examples been
> proposed to me.
>
>
>
> On 12 November 2013 03:34, Ed Leafe <ed at openstack.org> wrote:
>
>> On Nov 11, 2013, at 6:42 PM, Vishvananda Ishaya <vishvananda at gmail.com>
>> wrote:
>>
>> > It also gives the submitter a specific example of a well-written test,
>> which
>> > can be a faster way to learn than forcing them to get there via trial
>> and error.
>>
>> +1. Implementing a policy that has as the end effect more knowledgeable
>> contributors is a big win.
>>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131112/e4e3c916/attachment.html>