This is separation from the thread "Those cookies again..." at http://groups.google.com/group/sage-support/browse_thread/thread/a520d6310ceac1b1
Hi David, On Sun, Aug 22, 2010 at 6:56 PM, Dr. David Kirkby <david.kir...@onetel.net> wrote: > In my opinion, (and one I think that is shared by Peter too), Sage needs to > devote *far* more time to testing, and a lot less time to adding features, > if it's ever to become a viable alternative to the 4 M's. As a start, there needs to be a change in how the latest mainline repository is made available. Let me explain what I mean. The current situation is that a release manger has her/his working latest mainline in a private directory somewhere, usually on sage.math. This means that testing of the latest mainline repository is often performed by one person, i.e. the release manager, as new patches are integrated. If you have an account on the machine sage.math and you know where the release manager keeps their working repository, you could constantly test that working repository. But that is not an optimal way of testing the latest mainline. It is after the release manager releases an alpha or rc version that we see a concerted effort to test that new public release. What I'm suggesting is working out some way to encourage a concerted effort in testing the latest mainline, not just after an alpha or rc is publicly released. To understand the difficulty in realizing what I'm suggesting, let's look at how other open source projects are doing to make their latest mainline repository available. Projects like Python, Mercurial, etc. each has a central mainline tree that is publicly accessible. The release manager integrates a patch and hence immediately makes that new addition available in the mainline tree. This means that it is conceivable that one has a script or process that automatically does a nightly or daily build and test run through the whole of the latest mainline tree. Contrast the above situation to the current case of the Sage project. We have discussed over and over again on the issue of making the latest mainline tree of Sage publicly available. So far we have not succeeded in realizing this goal. This might be due to how a Sage source version is managed. Currently, there is the Sage library which is managed by a Mercurial repository, there is a library of scripts which is also managed by Mercurial, there is the base spkg repository that is also managed by Mercurial, the standard spkg repository that is not under source control, and there is SAGE_ROOT which is also not under source control. How can we apply the concept of a mainline tree from other projects to the case of the Sage project? A few months ago, I tried to implement some scripts to push [1] the latest mainline Sage tree to a central place, and to pull [2] the latest mainline from that central place to a local place. My little experiment showed some glimmer of hope of getting the whole Sage source tree into such a state that anyone could pull from that tree for testing purposes, but only a release manager with suitable privileges could push to that tree. This little experiment is far from a complete realization. Other details need to be worked out as well as more time to devote to its realization. > The only possible way Sage might get less buggy, is for more people with > similar views to me, make them known to William. *Perhaps*, if he realises > people like you are reluctant to use Sage for classes because of the bug > rates, he might do something to address the quality control issues. > > One of the release mangers for 4.5.3 has said the first release candidate > for 4.5.3 will be available on Monday and he hopes to release 4.5.3 on > Friday. That's simply insufficient time for testing in my personal personal > opinion. > > I'd like to see regular "bug-fix-only" releases, where no new features are > added, but only code that addresses known bugs is incorporated. > > Whilst Brooks claims in his book > > http://en.wikipedia.org/wiki/The_Mythical_Man-Month#The_tendency_towards_irreducible_number_of_errors > > that > > =================================================================== > in a suitably complex system there is a certain irreducible number of > errors. Any attempt to fix observed errors tends to result in the > introduction of other errors > =================================================================== > > I think Sage is a long way from that point. > > Sage is certainly "suitably complex", but I don't think it's reached the > point where attempts to fix bugs will not reduce the total number of bugs. I > think with some effort, and a change of attitude, the number of bugs in Sage > could be reduced, but this would be at the expense of adding new features. > It might even lose some developers, who can't tolerate such a change of > attitude. A factor which can militate against this is the lack of contributors who care enough about a part of Sage to work on it. Sage is a behemoth. The current crop of contributors is not sufficient to drive down the current number of open bugs. It's difficult as it is for these people to carry about their day job, work on Sage, and manage their private lives. We need to encourage a diverse cohort of people to be passionate about certain parts of Sage. How we do that is a different matter: Sage Days work, social media work, words of mouth work, but not inspiring enough to encourage active contributors as opposed to users. [1] http://sage.math.washington.edu/home/mvngu/apps/sageutil/push.sh [2] http://sage.math.washington.edu/home/mvngu/apps/sageutil/pull.sh -- 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
