> We must be using different definitions of "blocker" then. Just > because a bug doesn't prevent development from continuing does not > mean it isn't a *release* blocker. Any bug that introduces > regressions into the test suite should be a blocker if it means not > being able to release a product with the test suite fully passing. >
The definition of "blocker" ticket must be adapted to the release calendar we choose to have. If the definition of blocker ticket is too inclusive, than it is just impossible to respect the rule of 1 release each 3 months approximatively. Then, the impact of many late blocker tickets becomes that we do 2 or 3 releases per year instead of 4. But this does not solves the problem. There will still exist some blocker tickets which will ask again for a lower frequency of releases at the end of each cycle. It may even make things even worse as releasing less often means we stabilize the development branch (rc) less often, which means it is harder to stablize it... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
