[Pulp-dev] release process updates

Jeremy Audet jaudet at redhat.com
Thu Jan 19 14:50:22 UTC 2017


> I’m not sure I completely understand why we should not be having QE
verify Refactors. What if we’re worried about introducing regressions with
a Refactor?

Consider the ways in which a refactor might unintentionally change Pulp's
behaviour. A refactor might introduce a race condition, or accidentally
shadow a variable in a different scope, or introduce a typo that causes
tracebacks inside a try/except block, or something else. How do you test
that?

Refactors are an internal change that should have no visible effect, and I
think the best way to test them is to just run the test suite we already
have. It seems more productive for QE to write tests for existing and new
features and bugs than to guess the ways in which a refactor might
unintentionally change Pulp.

> How can we state that the blocker was fixed

The same way we state that any other bug has been fixed: by marking it as
MODIFIED. Fixing a bug is different from having QE verify that it's fixed.
The addition of a "verified" field in redmine would let QE give an explicit
stamp of approval.

> and in addition what's then the point then to make the issue as blocker
and fix it in tight deadlines.

Blocker bugs determine whether or not a release can move forward or not.
It's purely a developer tool. To be clear, QE currently ignores the
'blocker' field. The status quo is to verify all bugs on a best effort
basis. Releases currently go out the door with un-verified blocker bugs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20170119/9018a978/attachment.htm>


More information about the Pulp-dev mailing list