I've put this on sage-devel where it belongs. On Aug 24, 5:14 am, "Dr. David Kirkby" <david.kir...@onetel.net> wrote: > On 08/23/10 04:20 PM, kcrisman wrote: > > > Well, in general it seems to me that most Sage bugs come from things/ > > functionality that didn't exist before, and once they exist people > > want to start using them. > > Well, there are an alful lot of open-bugs in trac. Some have been open a very > long time. They are assigned to person X (for example I get the Solaris ones), > but person X does not work on them, but spends time writing new code.
"Assigned to" just means that there is some system default for where a given category of ticket goes. It does not mean "homework for or you can't work on Sage any more". But I agree that this is very confusing. Perhaps someone who has permission to make such changes on Trac could make that more obvious. > > But unlike a commercial system, the only > > realistic way we have to look for these bugs is for people to use the > > system. I just don't see how else to do it; > > There are several packages in Sage which have test suites that we could run > from > spkg-check. But people have not added the spkg-check file to Sage, so we can > not > run the tests. > > http://trac.sagemath.org/sage_trac/ticket/9767# > cliquerhttp://trac.sagemath.org/sage_trac/ticket/9613# > linboxhttp://trac.sagemath.org/sage_trac/ticket/9311# ratpoints That would be great. I think this is somewhat orthogonal to fixing bugs in the Sage library, though; obviously we want to make sure upstream is good, but again this is a different thing. I guess one could add this as a reqt. to any upgrades of spkgs. > and *many* others. Of the 100 or so standard packages in sage, only around 20 > have the ability to run any self-tests of the packages when they are built. In > some cases, those test suites are *far* more comprehensive than the ones in > Sage. (I believe Pari is an exception, where the Sage doctests are more > comprehensive than the Pari tests). > > If you look at the first and second columns of this ticket: > > http://trac.sagemath.org/sage_trac/ticket/9281 > > you will see those where there is an spkg-check file, and there where there is > not one. Not every package in sage has the ability to do any self checks > during > the build process, so we will never be able to get that list complete, but > there > are a lot missing. That's a great ticket. Anyway, I think (as you have correctly noted before) we have a bit of a culture clash between software engineering and mathematics. However, as far as I can tell, the only way to solve it is to vastly increase the user base until enough of them become developers that the load of these things does not fall on just a few people, nearly *all* of whom (including you, and you have done enormous high-quality work) are doing it on a volunteer basis. So we will add what makes Sage better for us. This is definitely not ideal project management in the sort of setting you are talking about, but the alternative is Sage staying completely stagnant, I think. It's a matter of motivating the troops in terms of things like documentation, testing, etc. And I, for one, would rather have Sage add lots of useful content for my courses than have it pass every spkg test - not that those are bad, far from it! It's a long evolution from "William's private replacement for Magma written on top of Python" to "highest-quality possible replacement for M*", and we aren't there yet. But I think if you look at how things have changed over the last three or four years, the release process (for instance) that Mitesh et al. are currently doing is vastly different from the one long ago; five years from now it could be nearly up to your standards, I hope - because you are right, they are the right ones to have. Just have patience with those of us who aren't from a software background - and trust that we are trying hard to internalize your lessons, but that we have more immediate needs to fill as well for our next course or paper. I think that just as Minh's messages about documentation are slowly taking hold in the whole ecosystem, so are yours about software engineering. - kcrisman -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
