> 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.
_______________________________________________ Pulp-dev mailing list [email protected] https://www.redhat.com/mailman/listinfo/pulp-dev
