David, does my response answer your question? Ina, same to you: does my response answer your question? Let me recap a few points:
- Pulp releases currently go out the door with un-verified (but fixed) blocker issues. None of these proposals change that policy. - 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. 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.) -Jeremy
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
