On 14/05/15 20:38, J. Landman Gay wrote:
On 5/14/2015 4:37 AM, Richmond wrote:
RunRev's recent track record seems to be that bugs (at least those
submitted by users) get picked at "random()"
A while back I posted the priorities used for bug fixes. They are not
random; by necessity they are triaged.
That's good to know.
Is it possible to have a list of them ALL and their priorities and
approximate fix-dates?
I think one of the best things RunRev could do at the moment is
release a list of unsolved bugs alongside a schedule for sorting them
out
The amount of effort that would take would substantially reduce the
time available for the actual bug fixes, especially since it would
have to be updated daily. There is also the fact that you never know
how long it will take to fix a bug until you've fixed it.
A once-off list (i.e. not one updated daily) with approx. dates would
inspire more confidence than keeping completely shtum.
However, the team has done a very good job lately of testing and
responding to every report promptly as it is opened. If you want a
list of unresolved bugs so you can view their progress, it is trivial
to get one by simply searching the database.
But don't judge the team by the number of unresolved reports you see.
I'm not: I know that, whatever appearances may be (!!!!!), the folk in
Edinburgh are working very hard.
What my "beef" is about is that the work is not presented in a way that
is easy for end-users to understand.
Before the new review system was implemented, responses were more
haphazard. After the implementation, LC asked everyone with old bugs
in the database to review them and close them if they were no longer
relevant. Many of us did that but many did not. A lot of those ancient
reports are now moot because subsequent engines have made them
non-issues, but they sit there in limbo because the original author
has not dealt with them. Again, the amount of effort required to go
through all those, re-test, and remove them is substantial. Anyone
with unresolved old bugs should test against the new engine and either
close or update the report. The team would like to remove all
nonrelevant material.
The effort may be substantial, but it may be justified.
------------- TANGENTIAL ILLUSTRATIVE PERSONAL ANECDOTE FOLLOWS
-------------------
The computers in my school have been limping along in a way that means
they are perfectly satisfactory for the way I use them at
present . . .
Now, come 8th June I am going to have 2 teams of "Tinies" (age 8 -12),
and 1 team of "not-so-tinies" (age 12-16) learning some basic
stuff with Livecode . . . and the machines as they are 'could' do that
. . . BUT. frankly, they are mainly running 4 and 5 year old Linux
systems, and are a bit "hairy round the nostrils".
So, "Lucky Richmond" has a choice:
1. Just let things roll along for another year.
2. Have a "very dirty weekend" backing up the stuff on the machines,
carting them all home (no internet access available at school),
blanking them, rejigging each one with a long-term support version of
Xubuntu or MINT, putting all the stuff back, making sure they
all have GIMP and InkScape installed, and Livecode 7.0.4. This involves
10 machines, and, as I have only 4 spare monitors at home,
I can only "do" four at once, and each machine will take 4 to 5 hours.
In terms of how much I get paid there is no difference . . .
I'm going to have a "very dirty weekend", better get out my leopard-skin
posing briefs :)
The effort WILL be justified as everything will be ship-shape and
Bristol fashion and the chances of something going
"Icky-Fatang" during the progging classes will be minimised.
---------------- END OF REASONABLY PROLIX TANGENTIALISM
----------------------
Yeah, I know, it's a %&*$#, but a bit of retrenchment is not always a
bad thing.
Richmond.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
