[Pulp-dev] release process updates

[Ina Panova]

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 <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.)
>
> -Jeremy
>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170123/f3732988/attachment.htm>