On Thu, Jul 20, 2017 at 4:22 PM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> wrote:
On Thu, Jul 20, 2017 at 10:02:09AM +0200, Kamil Paral wrote:
> But all of that above is a separate problem. What I'd like to understand is
> why you think existing bugs should be treated differently from new bugs.
> What is the rationale? And if you want to treat them differently, then how?
I think they're *clearly* different when it comes to delaying the
release. If a bug is not currently affecting anyone, delaying stops it
from becoming a user problem. If a bug is already a user problem,
delaying doesn't help those people — and just hurts everyone else who
would benefit from the release.
I'd argue that it does help - the bug gets fixed. The cost is maybe delaying the release (if the bug is accepted as a blocker way ahead of the milestone), or surely delaying the release (if the bug is accepted as a blocker close to the milestone). The alternative is rejecting the blocker right off the bat, which means the bug maybe gets fixed.
However, I think I misread your comment. I believed you're proposing we reject bugs existing in stable releases as blockers at any point of the development cycle. But you seem to have suggested we do this only if they're discovered very shortly before the milestone deadline. Is that correct? If so, I'm sorry for the confusion. In this case, I don't really have a problem with this - it's the same approach as for any other bug discovered a few hours before release. The impact is taken into consideration, the difficulty of the fix is taken into consideration, and also whether it already affects stable releases is taken into consideration (why not, sure). If the bug is not critical, it's either pushed to the next milestone, or pushed to the next release. That makes sense to me. If this is the way it's formulated, I don't have a problem with it.
_______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-leave@xxxxxxxxxxxxxxxxxxxxxxx
