William Stein 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).
Trying to dictate too much would certainly **** many developers off, given they donate their time free. There is no doubt about that. But that does not mean that you could not declare occasional intervals (every 6 months has suggested by some), when the only changes that will be committed at that time are bug fixes, and bug fixes submitted are not expected to contain enhancements. What I mean by that, is that is very common to try to fix a bug, and notice one could enhance the code too, so doing both at the same time. That's not to say that people do not work on what they want, do not produce patches, but simply that the only changes permitted would be to fix known bugs. As you rightly point out, fixing bugs can sometimes result in introducing other bugs. I do not believe there is any magic bullet which will stop that. The way to never write buggy code is to not write any code. > I personally would be uncomfortable telling "the developers" to focus > for a month (say) on producing bugfixes instead of new features. You do not need to ask them to focus on bugfixes, but just make them away only bug-fixes will be incorporated for a month. I think if the rationale for this is explained, I do not believe many would mind too much. And if they felt unwilling to focus on bug-fixing, then they can carry on with whatever they want to do, but will just have to understand their patches will not be incorporated for a month or so. > 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%: <SNIP> > 2. Report bugs. I checked yesterday and there are 822 known bugs in <SNIP> > 3. Organize a bug day. A few years ago Martin Albrecht introduced a <SNIP> > 4. Help write a Selenium test suite for the sage notebook. >> 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. No problem. They do not need to do it. They can continue to work on what they want, just understanding it will not be incorporated quite as quickly as before. > (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 suspect *part* of the reason bug fixes introduce bugs is the temptation to add enhancements when bugs are fixed. For example, I'm updating 'prereq' again. I see it has specific bugs. 1) My previous version will detect if gcc is used but not g++, but it fails to detect if g++ is used, but gcc is not. 2) There's a portability issue on HP-UX due to the fact that 'uname -p' is not portable. 3) The tests for programs in one script does not work on Solaris, as it thinks the programs exist, even when they do not. But the temptation is not to simply fix the bugs, but add enhancements at the same time. So I added teh following enhancements. 4) Check for 'bash', which is not currently done. 5) Check that 'make' is GNU make. 6) Check 'tar' is GNU tar. I'd say that during a bug-fixing release, only 1,2 and 3 were submitted, and 4, 5 and 6 which add enhancements were not. In fact, as HP-UX is not a supported platform, perhaps (2) should not be incorporated either. > 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. You will never get a perfect test suite. You will never get Sage bug-free. But IMHO there are things that could be done to produce a more stable version, that has less features, but is more stable. > -- William Dave --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
