On Thu, Jul 19, 2018 at 12:07 AM Volker Braun <vbraun.n...@gmail.com> wrote: > > On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote: >> >> As I wrote previously, I made this fix back in April, >> but tabled getting the fix directly into Sage since I thought it would >> be no big deal to make a Cysignals release and update Sage's >> dependency on it > > > By definition, if fixing a bug can easily wait for a month or two then its > not a blocker.
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. Indeed it would have been convenient to fix it sooner since test runs would have stopped failing earlier. But "known issues" during development are less important that known issues (that are fixed!) at release time. Certainly, if there is a known bug that cannot be reasonably fixed in time for a release then reasonable exceptions have to be made such as marking the test as a "known failure" or disabling it. Sage's test runner would actually probably benefit a lot from a "known failure" flag for tests (though it may have to be platform-specific, which is tricky). In any case, this still only proves my point that if I actually *knew* when a release was coming up I'd have pressed to get that done sooner. If there's a fix for a known issue there's no reason to exclude it from a release. -- 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.
