Strongly agree. I'd like to add something. I consider "slowness" a bug. When SAGE does something obviously way too slowly, that's almost as bad as a genuine bug. Some slownesses are easy to fix, some are not.
One of the things that really worries me is that someone who doesn't know the code really intimately, can change something in a way that they think improves the code, but that has a dramatic negative effect on performance in apparently unrelated areas. A common culprit is adding "type-checking" to the beginning of a low-level function. We currently don't have any systematic way of even *noticing* these kinds of things. It would be great if we had some coherent way of managing this. The first thing that occurs to me is some kind of "docprofile" (like doctests, but for checking speed of operations). If this works, it might be a good way of spotting "speed regressions". This is probably quite hard to set up.... for lots of reasons.... but I'm wondering whether people think something like this is feasible. david On Aug 10, 2007, at 9:25 AM, Martin Albrecht wrote: > > Hi there, > > there have been some complaints about the quality of SAGE code > recently, so > this is a proposal how to tackle this problem. > > 1.) Everybody fills a bug report about _anything_ annoying, wrong, > broken in > SAGE. Everything! Really, everything! Its easy to close a bug with > 'wontfix' > or 'cannotreproduce' and no one will be mad. The only condition is to > search > the bug reports first to check whether it has been reported already. > > I don't know how you handle this, but I often don't fill bug reports > because > (a) I don't care enough or (b) I'll have to fix the bug myself anyway. > But I > usually make notes in the code I am writing. This should change: lots > and > lots of bugreports. Also, fill in the features you are planing to > implement > as a feature request and assign yourself. This way it is transparent > who > wants to do what and it is easier to get in touch. > > 2.) We agree on - lets say - one Sunday a month when we all meet on > IRC and > sit down fixing those bugs. No new features only bug squashing! Many > projects > hold events called 'Bug Squashing Party' and this would be our 'party. > I.e. > we go through the bug reports, assign people, fix them and close them > (many > obsolete bug reports on Trac were not properly closed). > > Potential refinements: > > 3.1) The KDE team has the concept of a "Junior Job". That is a bugfix > or a > feature request someone new to the project could be able to handle. > E.g. > finding an obscure SEGFAULT in code related to libSINGULAR on AMD64 > machines > only is definitely no Junior Job, fixing > > http://www.sagemath.org:9002/sage_trac/ticket/415 > > (ZZ.random_element(0) --> crash) is. Btw. I've just fixed and closed > it. > > The KDE devs simply tag junior jobs with ("JJ:") in the bug > description and > have a nice way to tell people how to get involved easily. > > 3.2) Trac should be configured to send out e-mails if something > changes for a > bug that is assigned to me. > > Thoughts? > Martin > > -- > name: Martin Albrecht > _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 > _www: http://www.informatik.uni-bremen.de/~malb > _jab: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
