[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
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
-------------- 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