Re: Maintaining a Mathematica bug list
- To: mathgroup at smc.vnet.net
- Subject: [mg97579] Re: Maintaining a Mathematica bug list
- From: "Dr. David Kirkby" <david.kirkby at onetel.net>
- Date: Mon, 16 Mar 2009 04:23:03 -0500 (EST)
- References: <14874019.1237075110231.JavaMail.root@m02> <gpil89$56l$1@smc.vnet.net>
David Park wrote: > I think this is the case of the perfect being the enemy of the useful. It is > not so important that every single bug be in a maintained bug list for > users. It is more important that major new bugs that affect a large number > of users be on a list. I could see a useful bug list being less than a few > dozen items. If some relatively savvy Mathematica user wanted to maintain > such a list they might publish it on MathGroup once a week, say. They might > pick up the bugs from MathGroup, or once they became known, users might send > bugs to them directly. But if it is something obscure and difficult to > verify the list maintainer shouldn't be expected to spend a lot of time > checking it, or put it on the list. Sometimes he might just say that > so-and-so reported trouble with such-and-such a function. Sometimes WRI > might even send him bugs, or comment or correct the list. > > A short list of high impact bugs would be useful. Agreed David However, these high impact bugs are likely to be well publicised already. A Google search will probably find many of these. College lecturers are likely to know of them. I would expect them to be on the WRI support pages too. > A long exhaustive list > with deep analysis and verification would be too much work. It's clear that any attempt to thoroughly analyse a long list of obscure bugs would need a lot of time dedicated by experts, and nobody other than WRI are going to be able to do that. I think it is equally obvious that WRI are not likely to make such a list public. However, there would in my opinion be a use for a collection of 'reported/unverified bugs'. User 'A' just lists what they thinks is a bug, and user 'B' can believe or disbelieve as they see fit. User 'C' could add a comment like "this is a usage error, you should use Sin[x] not sin(x)" or similar. With a bit of luck, someone from WRI might comment, but it could not be expected. I've stuck a few Solaris-specific Mathematica bugs I've come across over the years at http://www.g8wrb.org/mathematica/ Ignoring the first few, which are only telling you what is already in the documentation, I believe 5 of those: 1) Mathematica 5.x using excessive CPU time on Solaris 10. 2) Mathematica uses excessive CPU time on multi-processor machines 3) Mathematica 6.0.1 or 6.0.2 has some characters unreadable 4) Mathematica fails to determine the number of CPUs correctly on SPARC 5) Mathematica crashes on Solaris x86 with an Intel CPU are listed with sufficient detail to enable someone to decide if they believe them or not. The 3rd of these affects Linux too, the 5th is not a bug, but a workaround of how to get Mathematica working on a Solaris x86 system with an Intel CPU, rather than the supported AMD CPU. (I find it amazing Wolfram support AMD CPUs but not Intel, especially as I have made them aware how to solve the Intel issue). In my opinion, bug reports in that form are useful. The problem is that to make best use, they would need being in a searchable database. This would probably be software like Bugzilla with a mySQL backend. I think it is fair to say a typical Mathematica user is likely to be of above average intelligence, so hopefully would be able to write a bug report in a reasonably useful manner. You also need to consider that students working on college licenses don't (officially at least) have direct access to WRI support, but need to go via a university contact. Home use licenses in the US will have limited technical support (no option for premier service). A searchable public list might be particularly useful to that group. If anyone did set up a decent bug database, they would need to consider security and spam issues. * You can be sure someone is going to post an attachment which is a PHP script which attempts to hack your web server. * Someone might post spam. * Someone will try to upload a root-kit (or whatever the Windows equivalent is). * A hacker will attempt to exploit security issues in the bug database software (Bugzilla or similar). So effort would be needed to keep that up to date. * Someone will attempt to exploit bugs in web server software (Apache etc) * Someone will attempt to upload porn. * Someone will attempt to upload viruses. I think setting up the database and subsequent security maintenance would be the time-consuming things - not verifying the bugs, which I believe would be impractical and unnecessary. One final issue, WRI might object to a public bug list. I personally don't feel they should, but they might do, claiming it is hurting their product to have reports of bugs that are not bugs, but user errors. They could threaten legal action if someone did not take it down. I *very* doubt that would happen, as I suspect it would do them more harm than good and give their competitors something to shout about, but it just possibly could happen. Dave