Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Thu, Jul 19, 2018 at 11:19 AM Jeroen Demeyer wrote: > > On 2018-07-19 11:04, Sébastien Labbé wrote: > > The definition of "blocker" ticket must be adapted to the release > > calendar we choose to have. > > I really disagree with this. I think it's important that the calender is > adjusted depending on blocker tickets, not the other way around. +1 -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Thu, Jul 19, 2018 at 10:23 AM Volker Braun wrote: > > On Thursday, July 19, 2018 at 10:16:46 AM UTC+2, Erik Bray wrote: >> >> If there's a fix for a known issue there's no reason to exclude it >> from a release. > > > Look at it this way, we are delaying hundreds of tickets by a week to fix > your pet bug 3 months earlier. Of course you can forever argue about the > relative importance of bugs, but if you compare the accumulated > bug-time-in-product then excluding it and releasing earlier is the right > thing to do. > Look at it this way, we are delaying hundreds of tickets by a week I've said this already but that's a process problem. If we made a release branch there would be nothing stopping anyone from continuing to merge into the mainline while a release is tidied up. This is an artificial "crisis" created through process. It reminds me of the US's asinine debt ceiling and the fiscal cliff [1]. [1] https://en.wikipedia.org/wiki/United_States_fiscal_cliff * Also, "your pet bug" implies that it's of no importance, and dismisses the reasons it matters at all with a turn of phrase. I'm not a perfect communicator either but please, spare me. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On 2018-07-19 11:04, Sébastien Labbé wrote: The definition of "blocker" ticket must be adapted to the release calendar we choose to have. I really disagree with this. I think it's important that the calender is adjusted depending on blocker tickets, not the other way around. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
> 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Thursday, July 19, 2018 at 10:16:46 AM UTC+2, Erik Bray wrote: > > If there's a fix for a known issue there's no reason to exclude it > from a release. > Look at it this way, we are delaying hundreds of tickets by a week to fix your pet bug 3 months earlier. Of course you can forever argue about the relative importance of bugs, but if you compare the accumulated bug-time-in-product then excluding it and releasing earlier is the right thing to do. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Thu, Jul 19, 2018 at 12:07 AM Volker Braun 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Wed, Jul 18, 2018 at 11:53 PM Timo Kaufmann wrote: > > As one small data point I can say that I already upgraded cysignals in > nixpkgs (tested Linux, although it could technically be used on other > platforms too). I didn't run into any obvious issues. > > I also think we should merge that upgrade for 8.3. Erik put in a lot of work > to make that platform supported and I think the least we should do is support > him in supporting it :) > > Sage has a lot of tests. It might even test a little too much (making the > test suite brittle). I'm sure they would catch most regressions faster than > 1-2 weeks. > > And worst case, if a regression slips through, why are we not doing bug fix > releases? E.g. sage 8.3.1. I have suggested that many times as well, but have been told it's too much trouble for some reason. I didn't bring it up this time just to keep the topic narrowed. One thing I should be clear about is that I greatly respect the amount of time and effort Volker puts into being release manager as it is. And I know from experience that it's just that much more extra work to maintain bug fix releases (but I also know that it's not *that much* either, I'd say so even for Sage). If we could configure the buildbots to also run tests against a bug fix release branch (separate from develop) and I can figure out how the binary releases are done I would by happy to make bug fix releases on an as-needed basis. > On July 18, 2018 11:44:33 PM GMT+02:00, Volker Braun > wrote: >> >> On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote: >>> >>> All that said, your claim that this is a "high-risk" upgrade is also >>> highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1] >>> which contains a couple bug fixes, the most significant of which (in >>> terms of patch size) impacts Cygwin only. >> >> >> I haven't looked at the diff set, but we did have regressions from minor >> cysignals changes before. Its just that signal handlers, due to their >> asynchronous nature and interactions with the OS, are notoriously hard to >> reason about. > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > -- > 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. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Wed, Jul 18, 2018 at 11:44 PM Volker Braun wrote: > > On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote: >> >> All that said, your claim that this is a "high-risk" upgrade is also >> highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1] >> which contains a couple bug fixes, the most significant of which (in >> terms of patch size) impacts Cygwin only. > > > I haven't looked at the diff set, but we did have regressions from minor > cysignals changes before. Its just that signal handlers, due to their > asynchronous nature and interactions with the OS, are notoriously hard to > reason about. I agree of course, and if you don't believe me you are welcome to look at the diff. However, you could take my word for it that virtually nothing changed w.r.t. actual signal handling. There was one `#define` added as an alias for some platforms, and the rest is completely Cygwin-specific in `#ifdef` blocks, and is well-tested. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Wed, Jul 18, 2018 at 11:21 PM Jeroen Demeyer wrote: > > On 2018-07-18 13:34, Erik Bray wrote: > > This is again specious, and needlessly disparaging and antagonistic. > > I don't believe if takes 2 weeks to run CI tests > > Just replying on this point: the problem is that many things are not > caught by CI, especially things related to the build system and portability. That's certainly true! But that's why we need a window in the first place in which we can discover and find those issues. If what Volker is saying in terms of adding additional 1-2 weeks of just "breathing room" then I agree with that and I apologize if I misunderstood. Though I do disagree with the assertion that the Cysignals update is "high-risk" (I would say that is much more the case with https://trac.sagemath.org/ticket/25857 which is why I mostly agree with Volker's analysis of that one (though I don't like the unilateral "blocker -> major" changes either). What I do believe was disparaging and antagonistic was the wording, not the substance. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
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. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
Le mercredi 18 juillet 2018 23:44:33 UTC+2, Volker Braun: > > I haven't looked at the diff set, but we did have regressions > from minor cysignals changes before. Its just that signal handlers, > due to their asynchronous nature and interactions with the OS, > are notoriously hard to reason about. I would really love #25814 to be merged for Sage 8.3. Can you please give it a try? -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
As one small data point I can say that I already upgraded cysignals in nixpkgs (tested Linux, although it could technically be used on other platforms too). I didn't run into any obvious issues. I also think we should merge that upgrade for 8.3. Erik put in a lot of work to make that platform supported and I think the least we should do is support him in supporting it :) Sage has a lot of tests. It might even test a little too much (making the test suite brittle). I'm sure they would catch most regressions faster than 1-2 weeks. And worst case, if a regression slips through, why are we not doing bug fix releases? E.g. sage 8.3.1. On July 18, 2018 11:44:33 PM GMT+02:00, Volker Braun wrote: >On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote: >> >> All that said, your claim that this is a "high-risk" upgrade is also >> highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1] > >> which contains a couple bug fixes, the most significant of which (in >> terms of patch size) impacts Cygwin only. > > >I haven't looked at the diff set, but we did have regressions from >minor >cysignals changes before. Its just that signal handlers, due to their >asynchronous nature and interactions with the OS, are notoriously hard >to >reason about. > >-- >You received this message because you are subscribed to a topic in the >Google Groups "sage-devel" group. >To unsubscribe from this topic, visit >https://groups.google.com/d/topic/sage-devel/E3pPKrQbBkE/unsubscribe. >To unsubscribe from this group and all its topics, 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. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Wednesday, July 18, 2018 at 1:34:56 PM UTC+2, Erik Bray wrote: > > All that said, your claim that this is a "high-risk" upgrade is also > highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1] > which contains a couple bug fixes, the most significant of which (in > terms of patch size) impacts Cygwin only. I haven't looked at the diff set, but we did have regressions from minor cysignals changes before. Its just that signal handlers, due to their asynchronous nature and interactions with the OS, are notoriously hard to reason about. -- 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.
Re: Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On 2018-07-18 13:34, Erik Bray wrote: This is again specious, and needlessly disparaging and antagonistic. I don't believe if takes 2 weeks to run CI tests Just replying on this point: the problem is that many things are not caught by CI, especially things related to the build system and portability. -- 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.
Sage's release practices (was :Re: [sage-devel] Re: [sage-trac] #25814: Upgrade to cysignals 1.7.2)
On Wed, Jul 18, 2018 at 12:13 AM Volker Braun wrote: There's at least a few things I should say here. > I do appreciate your hard work in making Cygwin work. But IMHO thats a rather > high-risk upgrade with little reward. Nobody stops you from merging that > ticket when building cygwin binaries. > And realistically we don't have anyone developing on Cygwin only at this > point. This isn't a development-related bug it's a runtime bug; so I don't understand your comment "realistically we don't have anyone developing on Cygwin only at this point". And it's a pretty serious bug IMO because it can cause the Sage process to simply *exit* with no error message and an error code of zero; granted this only happens in some extreme stack corruption scenarios, such as a stack overflow or possibly some other situations. In most software, especially plain Python software, that is not something we would have to worry about. However, for something like Sage and much of the mathematics software it wraps this is not as far-fetched a scenario, it's a very painful result to debug. All that said, your claim that this is a "high-risk" upgrade is also highly specious. This is upgrading Cysignals from 1.7.1 to 1.7.2 [1] which contains a couple bug fixes, the most significant of which (in terms of patch size) impacts Cygwin only. So I'm not sure what information you're going on when you call something "high risk". I also think it's worth emphasizing that this bug is a regression: It did not happen in the previous Sage release. Also going back to "developing on Cygwin" it depends on what you mean by "developing". Everyone who uses Sage is "developing" on some level. Are you saying there are no Sage users on Windows? > [ ] I want to delay all other tickets by 1-2 weeks so that this one Cygwin > bug can be fixed. This is again specious, and needlessly disparaging and antagonistic. I don't believe if takes 2 weeks to run CI tests--we are in the process of disproving that in #24655 [2] and related work (and if it does take that long that's a process problem, not something you can use as a cudgel). I hate to sound like a broken record (having to write this phrase yet again is itself repetitive), but there are things we could do differently that would save yourself, me, and others a lot of sense of antagonism every time you're trying to come out with a release. How can you claim that a release would be "delayed by 1-2 weeks" when there is no agreed upon and published release schedule? The purpose of having a release schedule is, among other things, the way to avoid these kinds of struggles. This would not be so important on a smaller-project developed by only one or two people. But for a project consisting of a large community of developers--most of whom also have other priorities and are not always actively working on Sage (even me!)--this kind of communication is absolutely necessary in order to give people a chance to plan and react. It's quite normal--common even--to have someone working an issue that they absolutely plan to have ready for an upcoming release, but need to set aside temporarily over other priorities, with intention to finish before the release. But if they have no idea when that release is going to happen, how can they plan accordingly? Sure, it can occur that a major new feature, or a controversial bug fix simply won't be ready in time for a release, and that's tough luck. But you vastly increase the likelihood of that happening when people don't know when the release is going to be and can't plan ahead for that. Take that scenario times N and it gets that much worse.* Currently, the only obvious indication that a release is imminent is that you unilaterally decide to tag something a "release candidate". When is that going to happen? After there's been a "beta9"? Is there ever a "beta10"? "beta11"? The tag history seems to indicate there could be. This time the "release candidate" came after "beta8". Sometimes it comes after "beta6". I know there is usually some logic behind this, such as an upcoming Sage days, but you can't expect everyone to know that, or to read your mind--I'll come back to that though. After the "release candidate 0" point, there is also no communication as to exactly how soon after you tag that "release candidate" you plan to make the final release. You would think there would be some communication of that at least on sage-devel, the primary channel for Sage developers to communicate with each other and make decisions about the direction of the project. Instead it just sort of "happens" as though it were a force of nature. By contrast: Looking at the past releases (informally; I haven't precisely quantized this) it seems there's a new release roughly every three to five months. So let's say we plan to come out with a release once every four months, which is easy to keep track of. It would be good even to pin exact dates well in advance: This does not m
