On Tue, Oct 27, 2009 at 1:58 PM, Maurizio <maurizio.gran...@gmail.com> wrote: > > What about adopting a simpler strategy? > What do you think about this: every 6 months (or 9, or 12 whatever), > the developers are asked to focus on producing bugfixing instead of > introducing new features.
Asked by whom? For how long? And, who are "the developers"? The Sage project has no fulltime employees: Michael Abshoff was the only one we ever had, and his funding ran out in May. The vast majority of people who work on Sage do so for very specific reasons related to their own research or teaching, and consequently they work on specifically what they want to work on. Moreover, I try my best not to boss anybody around involved in the project (if anybody feels bossed around by me, definitely let me know -- it's not intentional). I personally would be uncomfortable telling "the developers" to focus for a month (say) on producing bugfixes instead of new features. However, I think there is value in thinking about specific ways to improve the quality of Sage overall. There are many things we can all do to help. Here are some concrete suggestions: 1. Improve the doctest coverage. It is currently 79.5%: $ sage -coverageall Overall weighted coverage score: 79.5% Total number of functions: 22734 We need 114 more function to get to 80% coverage. ---------- TAKE ACTION: Anybody reading this right now could sit down and put a dent in that "114 more functions". 2. Report bugs. I checked yesterday and there are 822 known bugs in Sage, according to trac. If you find a bug, make sure to report it and get it into trac. Don't just blow it off. The more bugs we know about (with clean, easy to test reproducible examples!), the better. TAKE ACTION: I bet you know about one bug in Sage that isn't listed in trac -- report it, and make sure it gets listed there! 3. Organize a bug day. A few years ago Martin Albrecht introduced a "Bug Day" idea into Sage development. This is a pre-announced day when people meet on irc and fix bugs. We have had 17 of these, but they stopped for no apparent reason nearly a *year* ago. See the list here: http://wiki.sagemath.org#BugDays TAKE ACTION: Organizing a Bug Day is easy! Just come up with a time, announce it on sage-devel, see if you can get some other people interested, make a list of specific bugs to work on (with some common theme), show up, "keep score", and report on what happened in another sage-devel followup email. 4. Help write a Selenium test suite for the sage notebook. If we had a sufficiently good one, this would have prevented most (all?) of the many recent issues with the notebook. I personally won't do any nontrivial further development on the notebook or merging of patches until there is a test suite. TAKE ACTION: I'm going to do this. > In this way, what happens is that one > release every "n" months could be considered more stable and reliable, > and these releases are kept on the website available for downloading > together with the current release. > In this way, I hope, there's really no overhead in the current work. This is trying to introduce some committee-style rules into the future of Sage development, instead of suggesting specific concrete actions people can take to improve the quality of Sage. This makes me a little bit uncomfortable, as if I'm being told what to do. It also seems idealistic to ask a hundred people to work a few weeks on fixing bugs -- "the developers are asked to focus on producing bugfixing instead of introducing new features" -- and assume that this will result in "no overhead" and a release that is "more stable and reliable". My concerns are that: (1) This suggestion asks many people to do for free a bunch of painful, difficult work that they likely don't want to do, and don't have the time to do. (2) Without a top notch test suite and multiple rounds of alpha/beta testing, often fixing a bunch of bugs can easily results in software that is less stable and more buggy. I think Sage has a good test suite, but honestly it is nowhere near where I want it to be -- which is 100% doctest coverage, plus a large suite of randomized testing that is run 24/7 on a cluster hunting for bugs, like what is done in the MPIR project. I want to emphasize point (2). In my experience, *most* people's attempts to fix a bug results in something they think fixes the bug, but in fact adds several other bugs. This is just the reality of software engineering. This is the case for extremely experienced developers new to a project, for experienced developers who have been involved for a long time, but forget something subtle, etc. I'm all for fixing bugs, but don't consider it necessarily capable of producing a more *stable* Sage release -- indeed it can result in a much less stable one, unless there is a perfect test suite. > Of course, some effort in changing goals twice a year would be > required, so that old problems are solved. > > Thanks for discussing this > > Regards > > Maurizio Thanks to you to. Please try not to take any offense to what I wrote above. I'm just trying to engage in a helpful intellectual way. Honestly, I would rather be doing something else right now, but you've patiently and painstakingly laid out your thoughts in detail repeatedly, so I think it is unfair if I don't respond. -- William --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
