Re: [Audacity-quality] [Bug 20] Unreliable Automatic Crash Recovery.

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

| From Vaughan Johnson <va...@au...> 
| Sat, 17 Jul 2010 14:15:36 -0700
| Subject: [Audacity-quality] [Bug 20] Unreliable Automatic Crash Recovery.
|  > On 7/16/2010 5:38 PM, aud...@li... wrote:
> And I'm open to dropping this list altogether, as the volume is so low,
> and volume on audacity-devel is much more reasonable these days.

I think the two things -quality is useful for could be handled other
ways: 

a) Raise a Review issue on Bugzilla if it is not clear if behaviour is a bug
     or just sub-optimal behaviour (or just what "someone doesn't like")

b) Raise a Wiki Proposal:
     http://wiki.audacityteam.org/wiki/Category:Proposal

     for some wider enhancement idea 

That's "if" people are comfortable watching the Wiki and Bugzilla more
closely. "Logically" that approach makes far more sense to me and 
contributes to a reduction in e-mails.  

It still raises the question what to do if the -devel volume does go back up 
again. It could easily happen if a number of new developers arrived who 
were focused on interface issues, or we got into testing a lot of new
features. 

In that case I still favour -devel being only for discussing code and 
technical matters like signal processing, and there is a wider list (much 
wider than the current scope of -quality) for absolutely everything else 
to do with moving Audacity forward.

See below.

> > From: Gale Andrews <ga...@au...> 
> > Subject: Re: [Audacity-quality] [Bug 20] Unreliable Automatic Crash
> > 	Recovery.
> > | From Vaughan Johnson <va...@au...> 
> > | Fri, 09 Jul 2010 11:36:52 -0700
> > | Subject: [Audacity-quality] [Bug 20] Unreliable Automatic Crash Recovery.
> >> <snip>
> >>
> >>> There still are isolated reports of Win 7/Vista crashes on Stop even in Beta
> >>> (always USB devices), but nothing like as many as in 1.2  I think these are
> >>> much more dangerous to a proper recovery than a crash during recording.
> >>> Comments?
> >>>    
> >> Are they replicable? I think a crash bug is probably a separate bug from 
> >> this one, as this was about autosave not being implemented correctly, 
> >> not about whatever causes crashes. If you have a set of steps to 
> >> replicate, I think it should probably be a new bug. I have a few USB 
> >> devices I can play with, if you have a list of problematic devices.
> > 
> > Yes I agree it's a different bug (being the root cause of the recovery failing)
> > but I'm not sure it's yet replicable enough to list it formally. I've seen five 
> > reports reports since April in 1.3.12 (4 x USB turntables, 1 x Samson USB
> > Mic), and the users haven't reported a recurrence (to me). 
> 
> Okay, so I've changed bug 20 to "Resolved - Fixed".

Have you tested the three cases listed for Bug 20:

 o If a crash occurs with two tracks open, multiple projects are recovered
 o Recovery fails if a track is imported then another added after the autosave
interval
  o Complete recovery failures (empty projects) seen on single tracks which 
are only generated tones

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 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.   

Same goes for some other devel-fixed bugs which I'd like to move to "Fixed" 
but they haven't had testing on Mac.  Going without doing that may be more
OK in some cases than others. 


> > The only vague suggestion I have (from comments made for both 1.2 and 
> > 1.3 crashes) is that the problem may be more likely to happen if you Stop 
> > when there are already several recorded tracks on the screen. This can
> > happen even with tracks as short as a few minutes long.
> 
> I'm afraid that's not very actionable, so we'll have to wait for more
> user input. 

No more input to date (in 1.3).   


> > 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. 

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. 

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).  


Thanks




Gale