<div dir="ltr">Hi Anita, et. all, <div><br></div><div style>I understand if the -1 is being voted because of testing framework failures, it is a real pain. </div><div style><br></div><div style>Assuming the framework is working fine, I have noticed that there could be genuine failures because of devstack failing to fully stack up or the test failures. In my specific case, I have observed that test_network_basic_ops() have 70% success rate and devstack fails once in a while as well - and these failures are not because of the patch being reviewed. </div>
<div style>Therefore, being sensitive to patch submitters, and not causing -1 votes, I am not running basic ops test. However, I would eventually like to start running this test. This means we will start to vote -1 once in while (or lots of time - depending upon the test results). </div>
<div style><br></div><div style>My question is as long as a -1 vote is casted with logs of the results, is it OK? - even if the failures are because of known bugs/issues? </div><div style><br></div><div style><br></div><div style>
regards..</div><div style>-Sukhdev</div><div style><br></div><div style><br></div><div style><br></div><div style> </div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 2, 2014 at 6:11 AM, Anita Kuno <span dir="ltr"><<a href="mailto:anteaya@anteaya.info" target="_blank">anteaya@anteaya.info</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On 12/30/2013 09:32 PM, Anita Kuno wrote:<br>
> Please.<br>
><br>
> When your third party testing structure votes on patches and your<br>
> testing structure is not stable, it will vote with a -1 on patches.<br>
><br>
> This results in three consequences:<br>
> 1. The patch it votes on starts a countdown for abandonment, this is<br>
> frustrating for developers.<br>
> 2. Reviewers who use -Verified-1 as a filter criteria will not review a<br>
> patch with a -1 in the verification column in the Gerrit dashboard. This<br>
> prevents developers from progressing in their work, and this also<br>
> prevents reviewers from reviewing patches that need to be assessed.<br>
> 3. Third party testing that does not provide publicly accessible logs<br>
> leave developers with no way to diagnose the issue, which makes it very<br>
> difficult for a developer to fix, leaving the patch in a state of limbo.<br>
><br>
> You can post messages to the patches, including a stable working url to<br>
> the logs for your tests, as you continue to work on your third party tests.<br>
><br>
> You are also welcome to post a success of failure message, just please<br>
> refrain from allowing your testing infrastructure to vote on patches<br>
> until your testing infrastructure is working, reliably, and has logs<br>
> that developers can use to fix problems.<br>
><br>
> The list of third party testing accounts are found here.[0]<br>
><br>
> Right now there are three plugins that need to remove voting until they<br>
> are stable.<br>
><br>
> Please be active in #openstack-neutron, #openstack-qa, and the mailing<br>
> list so that if there is an issue with your testing structure, people<br>
> can come and talk to you.<br>
><br>
> Thank you,<br>
> Anita.<br>
><br>
> [0]<a href="https://review.openstack.org/#/admin/groups/91,members" target="_blank">https://review.openstack.org/#/admin/groups/91,members</a><br>
><br>
</div></div>Keep in mind that the email provided in this list is expected to be an<br>
email people can use to contact you with questions and concerns about<br>
your testing interactions. [0]<br>
<br>
The point of the exercise is to provide useful and helpful information<br>
to developers and reviewers so that we all improve our code and create a<br>
better, more integrated product than we have now.<br>
<br>
Please check the email inboxes of the email addresses you have provided<br>
and please respond to inquires in a timely fashion.<br>
<br>
Please also remember people will look for you on irc, so having a<br>
representative available on irc for discussion will give you some useful<br>
feedback on ensuring your third party testing structure is behaving as<br>
efficiently as possible.<br>
<br>
We have a certain level of tolerance for unproductive noise while you<br>
are getting the bugs knocked out of your system. If developers are<br>
trying to contact you for more information and there is no response,<br>
third party testing structures that fail to comply with the expectation<br>
that they will respond to questions, will be addressed on a case by case<br>
basis.<br>
<br>
Thank you in advance for your kind attention,<br>
<div class="HOEnZb"><div class="h5">Anita.<br>
<br>
[0] <a href="https://review.openstack.org/#/admin/groups/91,members" target="_blank">https://review.openstack.org/#/admin/groups/91,members</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>