[Pulp-dev] release process updates
ipanova at redhat.com
Mon Jan 23 21:04:17 UTC 2017
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
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.
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 <jaudet at redhat.com> 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.)
> Pulp-dev mailing list
> Pulp-dev at redhat.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Pulp-dev