<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.)<br></p><p>-Jeremy<br></p></div></div>