I have not taken any offense, on the contrary! Thank you very much for your detailed answer.
Maurizio On Oct 27, 10:41 pm, William Stein <wst...@gmail.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
