Re: [Audacity-quality] Bugs that need closing

[Peter S. <pet...@ya...>]

 James wrote:>We can look at having a new status, between DEVEL-FIXMADE and RESOLVED.  I've a feeling it will actually slow things down, but if you want it, let's work out how it would operate in more detail.
No, I don't  want any such new status - the ones we have now are quite sufficient I think.I agree that any such new status would not improve the bug resolution workflow.

>How are you suggesting we get slicker and quicker?
Quicker
What I am driving at is that we could be a lot quicker at testing (on any orall platforms as required) bugs soon after they are marked DEVEL-FIXMADEand the associated nightlies have been produced - thereby enabling usto clear them from the buglist as RESOLVED.
As you will have observed from my analysis of yesterday of the potentiallyblocking P2 bugs most of them were fixed over a month ago, most of themwere tested and passed on the original platform for which the bug was reported.Most of them were tested on one other of the major platforms.  The holdup was that most of them still required testing on the Mac platform to enablesubsequent closure as RESOLVED.
Now I'm fine with us having one careful gatekeeper who manages and controlsthe final resolution/closure of bugs - but if we do restrict it to one person, then That person does have to get on with the job of resolving the bugs as we automatically create a restriction in the workflow of bug handling.  That role should be seenas a very high priority of that person's job on the team as the restriction becomescritical as we approach the final stages of a release cycle.
That person should probably also have the mandate to assign any required testing,but that is hard to achieve in a do-ocracy  ;-)
It's also important to get them cleared away as soon as possible even early ina release cycle as all they do is, as Steve pointed out yesterday, unnecessarily clutter up the bug list and thereby wasting QA time with wasted re-reads of mostly tried-and-tested fixed bugs.

Slicker
It would probably help us from the outset when a bug is first reported on a particularplatform if we established whether or not it applied to just that platform or whetherit affected the other platforms too - and then we could mark, as Steve suggested,which platforms it should be tested on to achieve closure/resolution.
We do already have the flagging mechanism in Bugzilla to indicate which platforms are affected by any particular bug - what we lack is a flag to indicate which platforms they should be tested on.
Of course we may take the view that all fixes should be always tested on all platforms, as the changes wrought to make a fix on the original platform may affect and change behavior on the other platforms?

Peter.





Peter Sampson Tel: +44 (0)1625 524 780
      From: James Crook <cr...@in...>
 To: Peter Sampson <pet...@ya...>; audacity-quality <aud...@li...> 
 Sent: Tuesday, October 6, 2015 5:29 PM
 Subject: Re: [Audacity-quality] Bugs that need closing
   
 On 06/10/2015 14:11, Peter Sampson wrote:
  
   Ok so lets take a long hard look at some of these bugs  
 
 Peter, thanks for your analysis.
 
 
 
 
  http://bugzilla.audacityteam.org/show_bug.cgi?id=437 I'm no sure why this has suddenly come to such prominence.  
 That's down to me.  It's because it is mentioned as a limitation on the Wikipedia page about Audacity and so has bigger impact on the reputation of Audacity than it should.  So I raised it from P3 to P2.  The importance of the Wikipedia page has shot up with the loss of the sourceforge page and our need to boost SEO.
 
 
  We've had this on Bugzilla since 29Jul11 (i.e. over 4 years) Yes it's not good - but anyone who runs a computer with very little  free disk space is a fool and asking for trouble (in the past such  behavior could crash OS's not just applications!  
 Java updates that don't delete the olde version, and even Windows 10 update pre-load can eat space suddenly.  Calling a user a fool rather than looking at what we can do better is not good.
 
 
  Which brings me to the point that Steve was driving at - we really should  be getting much slicker and much quicker at testing bugs on all the appropriate platforms - and thereby proceeding to marking them as "fixed" and getting them off our radar (I can assure you that, as a tester, it becomes very tedious reading and re-reading the same bug report many times over).  
 We can look at having a new status, between DEVEL-FIXMADE and RESOLVED.  I've a feeling it will actually slow things down, but if you want it, let's work out how it would operate in more detail.
 
 How are you suggesting we get slicker and quicker?
 
 
  And which also begs a question:  If a particular bug is just flagged as say W7 is it sufficient that testing is just done on W7 or do we always want to test all bugs on all platforms?    
 I think the problem is, it depends.
 
 It is not so much the problem itself as the fix that determines how much testing is prudent.
 
 Some fixes are very clearly 'right' (low risk) from looking at the code, and a developer could say that if the sanity test on one platform passes the fix is good.  Others are more involved, more likely to be platform dependent and need fuller testing.  It will always be guesswork how low risk a fix is, but in clear cases could save time.
 
 
 
  And to take this further, on all variants of each OS on each platform?  
 Clearly not.
 But I think we will need to test some fixes on Mac OSX, Win 7, Win 10 (once we officially support it) and Ubuntu 14.04 LTS.


 
 --James.