On 10/20/10 10:37 AM, Martin Albrecht wrote:
The idea of having one piece of a Sage days devoted to
people sharing ideas from books they read in a coordinated way sounds
plausible as well, though probably it would really depend on the Sage
days in question.
That would sound good. If each person read a chapter of a book on a topic,
and gave a short talk to everyone else, it should at least make people
aware of the other issues.
I bought this book
http://www.amazon.com/Software-Engineering-9th-Ian-Sommerville/dp/013703515
2/ref=sr_1_1?ie=UTF8&qid=1287529714&sr=8-1
though I'm not over-impressed with it.
Despite some pretty poor reviews on Amazon, I find an old (3rd edition) of
this book
http://www.amazon.com/Software-Engineering-Practitioners-Roger-Pressman/dp/
0073375977/ref=sr_1_4?ie=UTF8&qid=1287529714&sr=8-4
to be very useful.
You can pick up a used copy of the 6th edition (2004) for less than $2 on
Amazon.
I'd like to return to Burcin's original proposal if possible.
It might have been better to post the followup to his comments not mine, but it
does not matter too much.
He made a
*concrete* proposal for what to do with the growing number of bugs in Sage and
somehow this turned into a threat discussing which books on Software
Engineering we should read and how early one should should fix bugs.
First, without any quantitative data, are we sure the number is growing? We
should consider Sage is growing, adding new functionality, so an increase in the
absolute number of bugs is inevitable. My gut feeling is the situation is
getting "worst", but I've seen no evidence to prove this.
Even the most basic graph (say number of bugs vs date), would be semi-useful.
There are methods of measuring software quality
http://en.wikipedia.org/wiki/Software_quality
http://www.developer.com/tech/article.php/3644656/Software-Quality-Metrics.htm
http://it.toolbox.com/wiki/index.php/Software_Quality_Metrics
but we don't do any of them. Ultimately the best way to manage the situation it
to measure it, and determine the effect of various changes.
Like it or not, the situation does need to be managed - it won't solve itself.
You can see where I am leading with this - back to applying software engineering
principles!
Don't get me wrong, this is a useful discussion to be had but it is a shame
that discussions move from concrete to abstract instead of the other way
around quite often these days ([sage-general] anyone? :))
I would not consider my comments abstract, but individual book recommendations
are less relevant to what Burcin said.
It seems clear to me even if we do employ all kinds of software engineering
techniques that there will still be bugs we'll have to tackle and our current
approach as serious issues. Even OpenBSD has bugs which they have to address
despite the fact that they make quite an effort to scrutinize code.
To get back to Burcin's proposal it seems while there is some support, it
doesn't seem to spur enough interests to have enough people to distribute the
load to or am I mistaken?
To make matters easier to follow, lets look at Burcin's proposals.
http://groups.google.com/group/sage-devel/msg/40d2af34d86586de?hl=en
and consider them, here in an abbreviated and expanded form.
1) Burcin said: "Many of the bugs on trac are duplicates and could be closed."
He is probably right. Some are undoubably wrongly categorised, but from a
personal perspective I often don't have a clue what to file them under anyway.
Perhaps for those of us without maths degrees, the categories could be more
explicit. But even that is not a full solution.
I've got a reasonable understanding about random numbers, as I did quite a bit
of work on it during my Ph.D with Monte Carlo modelling. But I don't really have
a clue what to file #10113 under.
Often bugs should really be in several categories, but one can only chose one.
IMHO it should be a tick-box, not a pull-down. If something with an elliptic
curve causes a doctest failure, on Solaris, do I file it under
* Elliptic curves ?
* Doctests ?
* Solaris ?
If person X files such a report, John Cremola might be in the best position to
fix it, but then I'd probably be able to make comments too. People with
knowledge about doctests might realise its actually a failure in the doctest.
(I'm very untrusting of the doctesing framework, especially for parallel tests).
2) Burcin said: "We might be able to overcome this with a "bug-wrangler" team,
people who volunteer to ..."
IMHO, If the categories could with a tick box, then this step could hopefully be
removed for future bugs. The right people will automatically be notified. We
need however to have a category "I need helping chosing the right categories".
That would be especially useful for those of us with a non-maths background, but
I think to others too, as parts of Sage are so specialised, I doubt I'm the only
one who struggles to know what to categorise things under.
I think the lack of too many "sign me up to do this" shows there's not likely to
be the number of developers taking this on. They might be more attracted to do
it if they realise that it only needs to be done once, and new bugs would
automatically be assigned to the right person.
Even if you understand what the bug is, the chances are you don't know who is
the best person to look at the bug.
Several categories have nobody at all assigned to them. Since I'm an admin on
trac I can see this. These include:
* cygwin
* debian-package
* distribution
* dsage
* experimental package
* factorization (this one *really* surprises me)
* msvc
* optional packages
* packages
* performance
* PLEASE CHANGE
* relocation
* c_lib is assigned to "tba". I'm not sure if that's a real user, or just
mis-named from "tbd". If so, that's another one with nobody assigned to it.
Many have only William assigned to them, but he is concentrating more on Psage
now.
Not to be overly pessimistic, but one metric we do not collect, but Google do
for us, is the number of posts each month to sage-devel. There has been a very
dramatic falloff this year compared to all other years.
http://groups.google.com/group/sage-devel/about?hl=en
Every month except January has had less posts than the same month last year, and
that fraction is declining rapidly. Last month see only 37% of the posts
compared to September 2009.
The same is true for sage-support
http://groups.google.com/group/sage-support/about?hl=en
I think the number of posts to sage-support is more worrying than to sage-devel,
but I believe the combination rather shows that we are unlikely to find a lot of
developers taking on Burcin's proposals.
Cheers,
Martin
Dave
--
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
