<div dir="ltr"><div><span class="gmail-im"><div><div>> 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?<br><br></div></div></span><div>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?<br><br></div><div>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.<br><br></div><span class="gmail-im">> How can we state that the blocker was fixed<br><br></span></div><div>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.<br></div><span class="gmail-im"><div><br>> and in addition what's then 
the point then to make the issue as blocker and fix it in tight 
deadlines. <br><br></div></span>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.</div>