On Wed, Jul 18, 2018 at 12:13 AM Volker Braun <vbraun.n...@gmail.com> 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 mean those exact dates must be kept--there are not specific market forces holding us to them. Various factors can affect them such as holidays, availability of the principal actors, serious blocker issues, etc. It's okay to slip a couple days to a couple weeks if need be, especially if this is communicated as much in advance if possible. But having some dates planned out well in advance still helps at-a-glance planning and decision making. There is also nothing preventing the occasional faster, intermediate release when appropriate (such as if there is a SageDays coming up for which some new features are desirable). Again, this still needs to be communicated in advance. With a scheduled (but flexible) target release date in place, one then has a basis for setting policies such as cut-off points for disruptive changes in the release branch. Somewhere between 2 weeks to a month a head of time, depending on how often release blockers are found during development. Maybe three weeks is good enough. Knowing that this cutoff point is coming also gives the development community time to cooperatively triage issues (by actually using milestones!) in order to better come up with a list of issues that can reasonably be accomplished by the next release. If done, even a little bit, this helps the release manager by reducing the number of issues we need to consider for planning a release. A triaging process also allows for debate/discussion over the relative importance of an issue further in advance, so it doesn't have to be as much of a panicked "last minute" fight. If there's a question about availability of continuous integration workers, this can also be mitigated (if it isn't already) by giving build priority to changes targeted for a soon-upcoming release. This can be done based on various issue metadata. This may sound idealized, and it is--this will never be perfect--but at least having a process that is documented and agreed upon makes a lot more possible with significantly less stress and antagonism involved. It gives everyone time to have their needs addressed (and does not guarantee that their needs will be met, but at least properly addressed), and leaves less ambiguity and unilateralism about the decision-making process. If setting a release "schedule" is somehow too impractical, there should at the very least be a process for preparing a release, which includes the aforementioned "grace period", triaging that precedes or coincides with the grace period, and above all else *communication* about the release plan. As someone with politically anarchist leanings I appreciate the anarchic structure of the Sage development community (and open source in general). But that doesn't work well if there aren't democratically agreed-upon and documented processes. It also doesn't work well if the development cycle is entirely decided (if even with good reasons) by one person who doesn't communicate their plans or reasoning in a public venue. That just feels more like chaos than anarchy to me. Thanks, E * Case in point: 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; at the time we determined it was a low-risk, low-effort issue that could be handled before the next release--whenever that might be... Given that "release candidate" is the only direct evidence that a release is imminent, I took it upon myself to e-mail you directly to ensure that the release could account for some otherwise ready work that needed to be included. That should at least indicate that it was "important enough". Instead that was summarily ignored, which is mysterious at best. [1] https://github.com/sagemath/cysignals/compare/1.7.1...1.7.2 [2] https://trac.sagemath.org/ticket/24655 -- 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.
