Re: [Audacity-quality] [Bug 20] Unreliable Automatic Crash Recovery. (Gale Andrews)

[Gale A. <ga...@au...>]

| From Vaughan Johnson <va...@au...> 
| Tue, 20 Jul 2010 14:50:34 -0700
| Subject: [Audacity-quality] [Bug 20] Unreliable Automatic Crash Recovery. (Gale Andrews)
>  (Responding to part of Gale's response on both lists.)
> 
> Date: Sun, 18 Jul 2010 02:05:00 +0100
> From: Gale Andrews <ga...@au...> 
> 
> >
> > Also has this been done on all OS'es? I am still trying to find
> time/energy to
> > do my bit (including check against other scenarios that have occasionally
> > been suggested).
> 
> I have only Windows, so I can't help on that, but the flaw in the logic
> was quite clear and quite wrong, so I think the Mac-specific items are
> probably fixed.

I agree, "probably" - I said I was not expecting a problem.  


> > I would as the notes say prefer a non-devel tested it on Mac given the
> > historical shakiness of recovery on Mac. That hasn't been possible yet
> given
> > Summer holidays. So I'd much prefer this remained at "devel - fix
> made" just
> > for now given its importance.  
> 
> I think that's unnecessary, but go ahead and revert it.

It can stay unreverted as long as I can get some time on testing it. 
Merely trying to be prudent and thorough.


> >>> In contrast, bugs I'm callling "moonphase P2" are running at 20 -  40
> >>> different people reporting them since April, including multiple
> occurrences
> >>> for many of those people (but still not reproducible to order).
> >>
> >> Likewise, not very actionable, so my opinion is they should be P3, i.e.,
> >> should not hold up "stable" release.
> >
> > There of course I disagree (given the number of occurrences and that
> > these occurrences mostly send people back to 1.2 or a previous, more
> > buggy 1.3).  I believe they could give us a bad press when people move
> > to 2.0 in large numbers.
> 
> You've had 20 - 40 reports since April. That's out of 1,636,597
> downloads from Google Code alone (ignoring mirrors, bundles, etc). So
> even if 80 people (twice the high end of your estimate) have had those
> problems, that's less than 0.005%. We've certainly had stable releases
> with bigger and more prevalent bugs, that we fixed quickly, and had no
> significant damage to our reputation.
> 
> Our reputation is suffering *much* more than that right now because we
> haven't made a stable release since November 2006. And that was just a
> minor version update on 1.2.0 series, which was first released February
> 2004. Truly embarrassing.

No one knows how many occurrences the reports really represent, but
obviously I completely agree about the damage caused by the delay and 
have been saying we need a slightly dirty 2.0 out there for many months.
A long list of release noted issues is also an embarrassment.  

What I would like is an agreed plan to deal with these moonphase P2s
(as I see them) so that they don't get ignored and don't cause (some) 
people including me to carry on using 1.2 when they don't want to. 


> > To downgrade them I'd still be looking for some way of prioritising them
> > among the P3s. "Just a P3" wouldn't cut it for me, nor for the people it
> > happens to.
> 
> Please do so. Make a suggestion.

I have made suggestions before which have not been commented on.
I personally have no problem with the first few releases of a new 
"stable" version having moonphase P2s in it, given the urgent need to
replace 1.2. 

Do we need a new P3 rating for moonphase issues that are demonstrably
driving people back to old versions, so we have six ratings in toto?   

Any other opinions? James, how about you? I would much prefer a 2.0 
that we all want to put our name to. Does everyone think a currently 
P2 moonphase attracting 9 or 10 reports a month (more than some  
repeatable P1s/P2s would) be downgraded on grounds of replicability
rather than severity? If that is the common way on other projects then
maybe we should do the same, but how do such problems ever get 
fixed?


> > I guess these are all actionable if a reporter caught them happening in a
> > debug version and was able to proceed from there. We have never had time
> > to do the extensive "stress-testing" we promised ourselves and I think
> > that is going to be needed sooner or later (early on in 2.0 is OK for me
> > given 2.0 isn't a mature "stable", as long as we do it). 
> 
> You've mentioned stress testing as James's suggestion a few times
> before, but I don't find such a thread on nabble, nor that we promised
> ourselves such a thing. What specifically do you mean? 
> If we haven't done it because of resources, what resources are required?

This has been discussed before, but basically time is required.
.
Run Audacity at small blocksizes, repeatedly doing "things" over the course 
of an hour or more, like running effects, or opening, quick editing and closing
multiple projects. Should about 25% of such projects acquire orphaned
blockfiles as a result of opening, a few edits and closing? This happens for 
me and it makes me feel very uneasy.

Also if a Windows developer is prepared to help me get good call stack 
information from a debug build, that might save some time in the longer
run. 




Gale