Re: on testing Sage

[kcrisman]

Many good comments, Minh.

> 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

R is able to do this with all the various contributed packages, for
instance.

> 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

Though we should point out that identification of bugs is important,
too, and this definitely happens (I mean this in a good way).

> 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

+1

[koffie]

I really like the idea of switching to multiple actively managed
maintained sage versions which is suggested somewhere in this thread.
I just happened to have suggested it also in a response to Williams
blog http://389a.blogspot.com/2010/08/computational-projects-part-1.html.
Where he discusses the issue that there is a large gap between writing
code which gives you the result needed for your research and getting
it up to standard to get it into sage.

Somehow my reply is not jet visible there. But the main point I
suggested there is that there should be some sort of unstable branche
like in the debian development cycle: http://www.debian.org/releases/

This unstable branch could be used as a central place to add all the
code used for people their own research which is meant to go into sage
at some point.