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 <mjbrigh...@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 <e...@openstack.org> wrote: > >> On Nov 11, 2013, at 6:42 PM, Vishvananda Ishaya <vishvana...@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@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
