<div dir="ltr"><div><div>Jeremy,<br><br></div>that totally answers my question, I just personally do not fully agree with our current approach.<br>If we decide to improve it - then the blockers should be verified by default, because until they are un-verified we cannot state 100% that it was fixed.<br>And imagine the situation we find same blocker regression in just released version - that would be a double-facepalm.<br><br>I've being silent on purpose for couple of days to see feedback/other point of view(?) from other colleagues as well.<br></div><div><br></div><div><br></div>P.S. I agree with you on refactor/issue/task being verified just on request.<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br><br>--------<br>Regards,<br><br>Ina Panova<br>Software Engineer| Pulp| Red Hat Inc.<br><br>"Do not go where the path may lead,<br> go instead where there is no path and leave a trail."<br></div></div></div>
<br><div class="gmail_quote">On Mon, Jan 23, 2017 at 8:51 PM, Jeremy Audet <span dir="ltr"><<a href="mailto:jaudet@redhat.com" target="_blank">jaudet@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>David, does my response answer your question?<br><br></div>Ina, same to you: does my response answer your question? Let me recap a few points:<br><ul><li>Pulp releases currently go out the door with un-verified (but fixed) blocker issues. None of these proposals change that policy.</li><li>If a developer wants a release to be held up until an issue is verified, they currently must email pulp-qe-list and contact (via IRC? or email?) the release engineer. Furthermore, finding out which issue(s) are holding up a release requires reading an email thread and/or pinging the release engineer, then looking at each affected issue. That's doable, but it would be easier if the information was tracked in redmine: holding up a release until a issue is verified would require nothing more than changing a field on an issue in redmine, and finding out what's holding up a release requires a redmine query.<br></li></ul><p>Also, I appreciate the intent behind requiring that refactors or blockers be verified before a release can go out, but let's bear in mind the consequences of such a decision. Consider the current 2.12 release: QE is preoccupied with fixing automated tests that broke as a result of the repository layout changing, so that we can provide assurance that no regressions occurred. That alone may push back the release by a day or two. Requiring verification for all refactors/blockers/etc regardless of their importance will almost certainly make such delays commonplace. It will also stress QE's ability to be flexible and occasionally take on other projects. (For example: I recently took a course on Ansible through RHU. I definitely spent less time verifying issues while doing that.)<span class="HOEnZb"><font color="#888888"><br></font></span></p><span class="HOEnZb"><font color="#888888"><p>-Jeremy<br></p></font></span></div></div>
<br>______________________________<wbr>_________________<br>
Pulp-dev mailing list<br>
<a href="mailto:Pulp-dev@redhat.com">Pulp-dev@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/pulp-dev" rel="noreferrer" target="_blank">https://www.redhat.com/<wbr>mailman/listinfo/pulp-dev</a><br>
<br></blockquote></div><br></div>