Hi Simon, On Mon, Aug 23, 2010 at 8:55 PM, Simon King <simon.k...@nuigalway.ie> wrote: > Hi All! > > Shouldn't this discussion better go to sage-devel?
Yes. I have moved it to sage-devel and opened a separate thread. > On 22 Aug., 22:01, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: >> ... >> http://www.python.org/dev/peps/pep-0006/ > > Quoting from this source: > "In general, only the N-1 release will be under active maintenance at > any time. That is, during Python 2.4's development, Python 2.3 > gets > bugfix releases." > > I see that simultaneously, there is work on Python 2.6.6 final (to > appear tomorrow) and Python 3.2 alpha2 (to appear September 5th). > > My impression is that the Sage development process is quite far from > that way of thinking. > > First of all, is there in Sage the concept of "maintenance" of a > previous version? Usually, if people hit a problem with, say, > sage-4.4, then they are told that they use a bronze age version and > should upgrade to the *latest* version sage-4.5.2. According to the > above quote, one would rather say "upgrade to bugfix release > sage-4.4.3". > > So, in a way, only one Sage version is actively maintained at a time, > namely always the latest version. > > If I remember correctly, there recently was a thread (sage-devel?) > about the role of milestones in the Sage trac. My impression is that > people virtually always choose the earliest possibility in the > "milestone" menue. Having bugfix releases would require a change of > attitude. People should tick 4.5.3 *only* if they have a bugfix. > Otherwise, they should tick 4.6 or 5.0. But then it may even be worth > to change the milestone menu. Perhaps: > "bugfix only" (without mentioning a number, as this will always go > into the earliest possible release), > "minor addition: 4.5.3" (There is no change in existing code and > little new code, so, it may be safe to consider early inclusion - but > care has to be taken, as it is more than a bugfix) > "minor addition: 4.5.4" (dito) > "major addition: 4.6" (There is much testing required, as there is > change in old code or there is much new code) > "critical change: 5.x" (in contrast to an addition, a change might > not be fully compatible with Sage-4.x and will thus not go in before > version 5.0) Developing a symbolic computation system like Sage requires more than skills in higher mathematics. An ideal person is someone who specializes in an area of mathematics, is experienced in mathematical software development, and knows how to straddle between mathematics and computation. Would this require the development of a course of study in order to produce such people? There are degrees in pure mathematics, in applied mathematics, in actuarial studies, in financial mathematics, in statistics and probability. What about a degree in computational mathematics, not just a few semester-long courses, but a full degree? > At this point, a question on the current milestones: What is the > meaning of the milestones "sage-invalid/duplicate/wontfix" The milestone "sage-invalid/duplicate/wontfix" is for any ticket that is invalid (or irrelevant to Sage), a duplicate ticket, or anything that is not considered to be a bug in Sage. You can think of this milestone as the trash bin for certain types of tickets. > and "sage- > i18n"? This milestone is for any wish list ticket concerning internationalization. Once work on an i18n ticket is complete and ready to be merged into the Sage source tree, the ticket can be assigned to the appropriate x.y.z milestone. On Tue, Aug 24, 2010 at 12:01 AM, Simon King <simon.k...@nuigalway.ie> wrote: > PS: > > On 23 Aug., 12:55, Simon King <simon.k...@nuigalway.ie> wrote: >> ... >> My impression is that the Sage development process is quite far from >> that way of thinking. > > ... or perhaps it is not so much the way of thinking? > I would expect that Python has a lot more person power than Sage. How > many people do release management for Python? Usually a few people (less than a dozen) for the various actively maintained Python versions. However, these release managers have their work spread over numerous testers and beta users. A release manager is not expected to test a Python version on all supported platform/hardware combinations. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
