Jeremy, that totally answers my question, I just personally do not fully agree with our current approach. 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. And imagine the situation we find same blocker regression in just released version - that would be a double-facepalm.
I've being silent on purpose for couple of days to see feedback/other point of view(?) from other colleagues as well. P.S. I agree with you on refactor/issue/task being verified just on request. -------- Regards, Ina Panova Software Engineer| Pulp| Red Hat Inc. "Do not go where the path may lead, go instead where there is no path and leave a trail." On Mon, Jan 23, 2017 at 8:51 PM, Jeremy Audet <[email protected]> wrote: > 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 > >
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
