The proposal sounds fine.
On Tue, Jul 18, 2017 at 3:48 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
I'm not in favor of this one. Too many important bugs have been waived in the past (even those easily fixable) just because "it's not a new bug". I don't see why it should matter. Sure, we can use the existing data to better estimate the impact (how often people complain about this, bug duplicates, etc). But that's just better input data. It should not affect the decision process. Or is the thinking process something like "users are already used to suffer from this bug, and perhaps can even work around it, so we don't need to try that hard to fix it"? I don't agree to that.Another consideration that might be relevant: is this a *new* issue or
something that also affects the current release (either as released or
with updates)? If something is a clear-cut blocker criterion violation
but isn't a regression *and* we're running late, using further release
delay as a forcing function feels like cutting off our nose to spite
our face.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
