[Pulp-dev] release process updates

Jeremy Audet jaudet at redhat.com
Mon Jan 23 19:51:45 UTC 2017

David, does my response answer your question?

Ina, same to you: does my response answer your question? Let me recap a few

   - 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.)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170123/9eb0455e/attachment.htm>

More information about the Pulp-dev mailing list