Re: [sage-devel] Milestones
On Mon, Oct 17, 2016 at 5:00 PM, Ralf Stephan wrote: > On Monday, October 17, 2016 at 11:42:46 AM UTC+2, Erik Bray wrote: >> >> On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey >> wrote: >> > Release early, release often. In my experience in the last 8 years, >> > especially release often - it has slowed down a bit, but it is still >> > often by any means. >> >> I'm afraid that's just not very useful--it's a platitude. > > > Disagree. The higher the release frequency the better streamlined is the > release process because the maintainer has more occasions to think > about it. The less pain is a quick bugfix release, although that > specifically > may not be a problem with Sage. I don't disagree, but see what I just wrote above--it's a mantra not a process. -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 4:48 PM, Jeroen Demeyer wrote: > On 2016-10-17 16:32, Erik Bray wrote: >> >> If a critical >> bug is found in released software it makes absolute sense to >> prioritize a release for that bug. > > > First of all, there have occasionally been bugfix releases of Sage: > * http://www.sagemath.org/changelogs/sage-5.0.1.txt > * http://www.sagemath.org/changelogs/sage-5.4.1.txt > * http://www.sagemath.org/changelogs/sage-6.1.1.txt > * http://www.sagemath.org/changelogs/sage-6.4.1.txt > > Such critical bugs are very rare in Sage. I cannot recall any bug in a > released version of Sage in the last year or so that would justify a bugfix > release. Remember that Sage is tested well before releases, on the patchbot, > on the buildbot and by developers running beta/rc versions. Bug fix releases are good even for non-critical bugs. Just because "Sage is tested well before releases" doesn't mean there are not bugs. It's great to be able to get fixes to users quickly without having to go through a longer release testing process that is necessary for bigger releases with more features, new dependencies, etc. This will be especially important as we move toward trying to better decouple sagelib from its dependencies in how it's developed. I'm also not sure how you're defining "critical bugs". I think all bugs are fairly important to fix within the framework of a manageable maintenance cycle. Having such a cycle means you get those fixes out to users faster--as Francois wrote "release early, and release often". Again, I apologize for dismissing it as a "platitude". It's a good mantra, especially for bug fixes. It's just not a *plan*. -- 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-devel] Milestones
On Monday, October 17, 2016 at 11:42:46 AM UTC+2, Erik Bray wrote: > > On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey > > wrote: > > Release early, release often. In my experience in the last 8 years, > > especially release often - it has slowed down a bit, but it is still > > often by any means. > > I'm afraid that's just not very useful--it's a platitude. Disagree. The higher the release frequency the better streamlined is the release process because the maintainer has more occasions to think about it. The less pain is a quick bugfix release, although that specifically may not be a problem with Sage. -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 4:50 PM, Jeroen Demeyer wrote: > On 2016-10-17 16:32, Erik Bray wrote: >> >> If a critical >> bug is found in released software it makes absolute sense to >> prioritize a release for that bug. > > > Besides, isn't this exactly what I said? That the "release schedule should > depend on the urgency of open issues." If there is a very important bug in a > released version, schedule a bugfix release. Yes, we're in agreement with that. But that doesn't dictate an entire release schedule for *all* releases. That's great that Sage has done patch releases before. What's the process for doing that in general? -- 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-devel] Milestones
On 2016-10-17 16:32, Erik Bray wrote: If a critical bug is found in released software it makes absolute sense to prioritize a release for that bug. Besides, isn't this exactly what I said? That the "release schedule should depend on the urgency of open issues." If there is a very important bug in a released version, schedule a bugfix 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-devel] Milestones
On 2016-10-17 16:32, Erik Bray wrote: If a critical bug is found in released software it makes absolute sense to prioritize a release for that bug. First of all, there have occasionally been bugfix releases of Sage: * http://www.sagemath.org/changelogs/sage-5.0.1.txt * http://www.sagemath.org/changelogs/sage-5.4.1.txt * http://www.sagemath.org/changelogs/sage-6.1.1.txt * http://www.sagemath.org/changelogs/sage-6.4.1.txt Such critical bugs are very rare in Sage. I cannot recall any bug in a released version of Sage in the last year or so that would justify a bugfix release. Remember that Sage is tested well before releases, on the patchbot, on the buildbot and by developers running beta/rc versions. -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 3:44 PM, Jeroen Demeyer wrote: > On 2016-10-17 15:27, Erik Bray wrote: >> >> What problems does it solve? First of all, I already mentioned >> one--nobody but the "release manager" knows when a release is expected >> to come out > > > Who cares when a release is expected to come out? I would think anyone who uses or works on Sage. If they don't, they should. A transparent release cycle is sort of at the heart of software product development--everything else stems from that, including more immediately important things. >> what the purpose of that release is, and what one can >> expect to be in it. That's a problem in of itself. > > > You are talking about a user-centric Changelog here? That's indeed something > that is missing, although I consider that a different issue from a roadmap > (a Changelog is made after the fact, a roadmap before). > >> How do you >> communicate to users how often/when they can expect releases? > > > Do users care? > >> How, >> also, do you communicate that to developers? How is one supposed to >> know the urgency of an issue if one doesn't know the release schedule? > > > I my opinion, the urgency of an issue should never depend on the release > schedule. It should be the other way around: the release schedule should > depend on the urgency of open issues. No, sorry, but that's completely backwards. Or at least it would be if Sage had a sane process for issuing patch releases. If a critical bug is found in released software it makes absolute sense to prioritize a release for that bug. You can't do that if all development is in one linear branch and making a release to fix a bug does not force other, non-critical, non-fix changes on users. It's also harder for developers because it makes a blocker issue becomes a blocker to continuing much any development, as well as releases. A lot of the problems with working on Sage, as we know, is the tight coupling between Sage itself and its build environment and dependency set. It is universally acknowledged that this is a problem and should be worked on. It is difficult to do this without establishing some better procedures. -- 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-devel] Milestones
On Mon, 17 Oct 2016, Jeroen Demeyer wrote: Who cares when a release is expected to come out? I do, but very, very slightly. We have a maintenance break at every monday after second tuesday of the week. (That is, six days after Microsoft patch day.) I could plan upgrades if I know in advance when the new version will be available. -- Jori Mäntysalo
Re: [sage-devel] Milestones
On 2016-10-17 15:27, Erik Bray wrote: What problems does it solve? First of all, I already mentioned one--nobody but the "release manager" knows when a release is expected to come out Who cares when a release is expected to come out? what the purpose of that release is, and what one can expect to be in it. That's a problem in of itself. You are talking about a user-centric Changelog here? That's indeed something that is missing, although I consider that a different issue from a roadmap (a Changelog is made after the fact, a roadmap before). How do you communicate to users how often/when they can expect releases? Do users care? How, also, do you communicate that to developers? How is one supposed to know the urgency of an issue if one doesn't know the release schedule? I my opinion, the urgency of an issue should never depend on the release schedule. It should be the other way around: the release schedule should depend on the urgency of open issues. -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 2:15 PM, Jeroen Demeyer wrote: > On 2016-10-17 11:33, Erik Bray wrote: >> >> I'm mostly just talking about a policy that generates a (rough) >> release schedule. > > > Which problems would that solve? I don't really see the problem with the > current "release whenever it's done" way of doing things, where "whenever > it's done" is largely arbitrary. I mostly brought this up in the first place just because I was confused about how milestones are being used (they aren't). It would be nice if they were used more as intended though. What problems does it solve? First of all, I already mentioned one--nobody but the "release manager" knows when a release is expected to come out, or what the purpose of that release is, and what one can expect to be in it. That's a problem in of itself. How do you communicate to users how often/when they can expect releases? How, also, do you communicate that to developers? How is one supposed to know the urgency of an issue if one doesn't know the release schedule? That's just the actual schedule though. Really that's not my chief concern (though it would be good to have). More broadly, a lack of development formality here leads to various other unnecessary complications and difficulties. I could go on and on here, but you wouldn't be hearing anything new from 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-devel] Milestones
On Mon, Oct 17, 2016 at 2:08 PM, Jeroen Demeyer wrote: > On 2016-10-17 11:38, Erik Bray wrote: >> >> But you're using a "milestone" to set what is effectively a resolution >> status. Why should "normal" users be able to set >> sage-duplicate/invalid/wontfix? That seems like a decision for a >> maintainer to make, at which point they can close the ticket. That would seem fine to me, if > The way I see it: it's a way for a normal user to indicate a *proposal* to > close a ticket as invalid or whatever. Then the actual closing is done by > the release manager. ...that actually happened with any consistency :) -- 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-devel] Milestones
On 2016-10-17 11:33, Erik Bray wrote: I'm mostly just talking about a policy that generates a (rough) release schedule. Which problems would that solve? I don't really see the problem with the current "release whenever it's done" way of doing things, where "whenever it's done" is largely arbitrary. -- 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-devel] Milestones
On 2016-10-17 11:38, Erik Bray wrote: But you're using a "milestone" to set what is effectively a resolution status. Why should "normal" users be able to set sage-duplicate/invalid/wontfix? That seems like a decision for a maintainer to make, at which point they can close the ticket. The way I see it: it's a way for a normal user to indicate a *proposal* to close a ticket as invalid or whatever. Then the actual closing is done by the release manager. -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 12:29 PM, Jori Mäntysalo wrote: > On Mon, 17 Oct 2016, Francois Bissey wrote: > >> To move to the kind of release schedule you are talking about >> we’ll need a new release manager who has the vision for this kind >> of things. > > > What is Volker's vision? I.e. do he have some plan in his head about when to > release 7.6? I suspect probably. I don't believe it's ad-hoc. But I don't know that this is documented. I find it strange, personally, that this is left entirely up to the release manager and not by some larger consensus. > I think that having two branches is just too much. In perfect world we could > have LTS with bugfixes only and so on, but we have not enought manpower for > that. But we could have some kind of decision like "7.6rc0 will be out at > the end of April 2017." I think it's rather bad to not be doing this. What some large projects do, like Python, is to have multiple release managers where each person is in charge of a specific release. So you can have a release manager specifically dedicated to upcoming patch releases who take care of backporting fixes and the like. This isn't often too much work--most fixes are easy to backport--only a few aren't. The release managers work together, but meanwhile you have someone entirely else in charge of getting the next feature release out. -- 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-devel] Milestones
On Mon, 17 Oct 2016, Francois Bissey wrote: To move to the kind of release schedule you are talking about we’ll need a new release manager who has the vision for this kind of things. What is Volker's vision? I.e. do he have some plan in his head about when to release 7.6? I think that having two branches is just too much. In perfect world we could have LTS with bugfixes only and so on, but we have not enought manpower for that. But we could have some kind of decision like "7.6rc0 will be out at the end of April 2017." -- Jori Mäntysalo
Re: [sage-devel] Milestones
On Mon, Oct 17, 2016 at 11:54 AM, Francois Bissey wrote: > >> On 17/10/2016, at 22:42, Erik Bray wrote: >> >> On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey >> wrote: >>> On 17/10/2016, at 22:33, Erik Bray wrote: My point is, as it is I see no way to divine when or why a Sage release is coming out. >>> >>> Release early, release often. In my experience in the last 8 years, >>> especially release often - it has slowed down a bit, but it is still >>> often by any means. >> >> I'm afraid that's just not very useful--it's a platitude. It's >> especially made worse by the lack of maintenance branches and patch >> releases. I agree patch releases should be frequent. For a project >> like sage feature releases should be fairly frequent too, but with >> care not break compatibility. > > Platitude or not, that’s the reality I have been experiencing. > Maintenance branch (or LTS release) have been brought up before, > usually by people coding for a living, but it never got anywhere. > I am fairly certain that it is a factor in said people getting less > active over time. Right--sorry--I didn't mean to sound dismissive. It's not a bad policy either but it helps, both developers and users, to have some guidance. > To move to the kind of release schedule you are talking about > we’ll need a new release manager who has the vision for this kind > of things. Not necessarily--Volker does a good job. This isn't just something for a single person to dictate, but rather something that needs to be worked on as a community to decide what's best. As long as the release manager is active in that discussion, they don't necessarily need to have the "vision". It does help to have someone write a prototype (either based on existing community discussion or just by fiat, to be discussed after). But that can be anyone involved at a high level in the project. -- 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-devel] Milestones
> On 17/10/2016, at 22:42, Erik Bray wrote: > > On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey > wrote: >> >>> On 17/10/2016, at 22:33, Erik Bray wrote: >>> >>> My point is, as it is I see no way to divine when or why a Sage >>> release is coming out. >> >> Release early, release often. In my experience in the last 8 years, >> especially release often - it has slowed down a bit, but it is still >> often by any means. > > I'm afraid that's just not very useful--it's a platitude. It's > especially made worse by the lack of maintenance branches and patch > releases. I agree patch releases should be frequent. For a project > like sage feature releases should be fairly frequent too, but with > care not break compatibility. Platitude or not, that’s the reality I have been experiencing. Maintenance branch (or LTS release) have been brought up before, usually by people coding for a living, but it never got anywhere. I am fairly certain that it is a factor in said people getting less active over time. To move to the kind of release schedule you are talking about we’ll need a new release manager who has the vision for this kind of things. François -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 11:40 AM, Jori Mäntysalo wrote: > On Mon, 17 Oct 2016, Erik Bray wrote: > >> I'm mostly just talking about a policy that generates a (rough) >> release schedule. > > > OK, so you mean something like Fedora release, where it was decided about > half a year ago that version 25 will be out at 2016-11-08 (and that was > later changed to 2016-11-15). > > In principle doable. It would mean that Volker won't change beta to rc until > some predefined date, and will make the change unless there is a very good > reason to release still one beta. Something like that, yes. It doesn't even have to be that precise--experience shows that beta testing/release candidates can hold things up if they expose major issues. One way to deal with that is to estimate, based on experience, how long release testing typically takes (one can even go back through history and get some quantitative evidence for this). Another is to not set exact release dates, but do set dates for cutting off the main branch to a release branch, where from that point forward only fixes will be merged (it's good to make a branch so that normal development can continue in the main branch in the meantime). Regardless, for the dates, it is still very useful to set rough estimates based on a policy like you described. This helps contributors plan how to target work they wish to contribute to a particular release. Sage is fortunate that it is not commercial software and doesn't have paying customers (like RedHat does) who expect things at specific times. But we can still do better to communicate a plan--this can help making the software itself more stable too. Here's an example of a release plan I helped develop for Astropy: https://github.com/astropy/astropy-APEs/blob/master/APE2.rst It isn't set in stone--it's been amended once or twice since its inception as we gained experience with how well previous versions of the plan were working. But for the most part it's been quite stable. -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 11:39 AM, Francois Bissey wrote: > >> On 17/10/2016, at 22:33, Erik Bray wrote: >> >> My point is, as it is I see no way to divine when or why a Sage >> release is coming out. > > Release early, release often. In my experience in the last 8 years, > especially release often - it has slowed down a bit, but it is still > often by any means. I'm afraid that's just not very useful--it's a platitude. It's especially made worse by the lack of maintenance branches and patch releases. I agree patch releases should be frequent. For a project like sage feature releases should be fairly frequent too, but with care not break compatibility. > The release criteria seems to be give a bit of polish after a number > of interesting commits are in. -- 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-devel] Milestones
On Mon, 17 Oct 2016, Erik Bray wrote: I'm mostly just talking about a policy that generates a (rough) release schedule. OK, so you mean something like Fedora release, where it was decided about half a year ago that version 25 will be out at 2016-11-08 (and that was later changed to 2016-11-15). In principle doable. It would mean that Volker won't change beta to rc until some predefined date, and will make the change unless there is a very good reason to release still one beta. -- Jori Mäntysalo
Re: [sage-devel] Milestones
> On 17/10/2016, at 22:33, Erik Bray wrote: > > My point is, as it is I see no way to divine when or why a Sage > release is coming out. Release early, release often. In my experience in the last 8 years, especially release often - it has slowed down a bit, but it is still often by any means. The release criteria seems to be give a bit of polish after a number of interesting commits are in. François -- 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-devel] Milestones
On Fri, Oct 14, 2016 at 5:01 PM, Jeroen Demeyer wrote: > On 2016-10-14 16:23, Erik Bray wrote: >> >> sage-duplicate/invalid/wontfix is a terrible "milestone" and I >> wouldn't mind getting rid of that too. That's a resolution status for >> an issue, not project goal. > > > Normal non-admin users cannot set a resolution, but they can set a > milestone. But you're using a "milestone" to set what is effectively a resolution status. Why should "normal" users be able to set sage-duplicate/invalid/wontfix? That seems like a decision for a maintainer to make, at which point they can close the ticket. -- 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-devel] Milestones
On Mon, Oct 17, 2016 at 11:23 AM, Jori Mäntysalo wrote: > On Mon, 17 Oct 2016, Erik Bray wrote: > >> Does Sage have *any* kind of roadmap planning? > > > No. > > What kind of roadmap it could be? If some developers are interested in graph > theory, how to make them to add more linear algebra code to Sage? It doesn't necessarily need to be in terms of features (e.g. "this release will contain graph theory updates only"). That's not how you plan a release roadmap, especially not one that goes well out into the future. There are lots of ways to do this and there is no one right way. I'm mostly just talking about a policy that generates a (rough) release schedule. Then if you have "some developers interested in graph theory" if they have specific features they wish to work on you can assign that work to an existing planned release. If they don't think they'll be able to finish the work, assuming it's not absolutely critical it doesn't need to hold up the release and can be moved to the next applicable release. My point is, as it is I see no way to divine when or why a Sage release is coming out. -- 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-devel] Milestones
On Mon, 17 Oct 2016, Erik Bray wrote: Does Sage have *any* kind of roadmap planning? No. What kind of roadmap it could be? If some developers are interested in graph theory, how to make them to add more linear algebra code to Sage? -- Jori Mäntysalo
Re: [sage-devel] Milestones
On Fri, Oct 14, 2016 at 5:25 PM, Volker Braun wrote: > I don't really use the milestones except for the > sage-duplicate/invalid/wontfix which indicates that there is nothing to > merge. > > We don't really use trac for roadmap planning so there is no real > significance to milestones, I guess. Does Sage have *any* kind of roadmap planning? > On Friday, October 14, 2016 at 4:07:06 PM UTC+2, Jeroen Demeyer wrote: >> >> As far as I know, the only real use-case for milestone is a milestone >> like `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that >> every milestone of the form `sage-X.Y` is essentially treated >> equivalently. >> >> So, we might as well git rid of the `sage-X.Y` milestones completely. >> But the release manager can correct me if I'm wrong. > > -- > 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-devel] Milestones
On Fri, Oct 14, 2016 at 7:24 PM, Jori Mäntysalo wrote: > On Fri, 14 Oct 2016, Jeroen Demeyer wrote: > >> As far as I know, the only real use-case for milestone is a milestone like >> `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that every >> milestone of the form `sage-X.Y` is essentially treated equivalently. > > > I normally use "sage-N" and mark myself as the author when I plan to do > something in near future, and "sage-(N+1)" rarely when I guess that version > N will be out before I got something done. I have used "sage-wishlist" few > times when I have an idea. If I report a bug, I use "sage-N" and left > author-field empty if I am not sure that I'll make patch myself. > > * * * > > But we don't have any plans like "Version 8 will be out about q1/2018 and > will have mostly more support for numerical linear algebra.", and so > milestones are not really used. Yeah, I guess not. That's too bad... -- 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-devel] Milestones
On Fri, 14 Oct 2016, Jeroen Demeyer wrote: As far as I know, the only real use-case for milestone is a milestone like `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that every milestone of the form `sage-X.Y` is essentially treated equivalently. I normally use "sage-N" and mark myself as the author when I plan to do something in near future, and "sage-(N+1)" rarely when I guess that version N will be out before I got something done. I have used "sage-wishlist" few times when I have an idea. If I report a bug, I use "sage-N" and left author-field empty if I am not sure that I'll make patch myself. * * * But we don't have any plans like "Version 8 will be out about q1/2018 and will have mostly more support for numerical linear algebra.", and so milestones are not really used. -- Jori Mäntysalo
Re: [sage-devel] Milestones
I don't really use the milestones except for the sage-duplicate/invalid/wontfix which indicates that there is nothing to merge. We don't really use trac for roadmap planning so there is no real significance to milestones, I guess. On Friday, October 14, 2016 at 4:07:06 PM UTC+2, Jeroen Demeyer wrote: > > As far as I know, the only real use-case for milestone is a milestone > like `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that > every milestone of the form `sage-X.Y` is essentially treated > equivalently. > > So, we might as well git rid of the `sage-X.Y` milestones completely. > But the release manager can correct me if I'm wrong. > -- 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-devel] Milestones
On 2016-10-14 16:23, Erik Bray wrote: sage-duplicate/invalid/wontfix is a terrible "milestone" and I wouldn't mind getting rid of that too. That's a resolution status for an issue, not project goal. Normal non-admin users cannot set a resolution, but they can set a milestone. -- 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-devel] Milestones
On Fri, Oct 14, 2016 at 4:06 PM, Jeroen Demeyer wrote: > As far as I know, the only real use-case for milestone is a milestone like > `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that every Well I'm not sure how you're defining "real use-case". sage-duplicate/invalid/wontfix is a terrible "milestone" and I wouldn't mind getting rid of that too. That's a resolution status for an issue, not project goal. > milestone of the form `sage-X.Y` is essentially treated equivalently. > > So, we might as well git rid of the `sage-X.Y` milestones completely. But > the release manager can correct me if I'm wrong. Or use them in a useful way to actually associate issues with releases in which we intend to address them. -- 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-devel] Milestones
As far as I know, the only real use-case for milestone is a milestone like `sage-duplicate/invalid/wontfix` or `sage-pending`. I think that every milestone of the form `sage-X.Y` is essentially treated equivalently. So, we might as well git rid of the `sage-X.Y` milestones completely. But the release manager can correct me if I'm wrong. -- 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.
