Talk:Release Checklist

From Audacity Wiki
Revision as of 18:57, 24 January 2010 by Edgar (talk | contribs) (Preparing to move to separate page)
Jump to: navigation, search

Guidelines for use of Checklist

Guidelines for using and editing the Checklist:
  • Release Checklist is the de facto active bug list. No one is looking at Bugzilla.
  • Follow the existing layout/style:
    • No colours (some people objected to red for P1's which we did before)
    • Start with a one sentence summary of the issue in bold.
    • Add further succinct information if required. Place "steps to reproduce" in the summary sentence if possible, and link to further information rather than obscure the list with it.
  • P1 Release Blockers and P2/P3 release-noted issues: Decide if the issue is a P1 Release Blocker, as described below: this is an empirical rather than a hard-and-fast process. If the item is not deemed a release blocker, then decide if the issue is important enough to release-note, should it remain unfixed at release time. If yes, these items are automatically P2 or P3. If not, they are P4 or P5.
  • How to decide if an item is P1:
    • A crash is often P1, but regressions are usually P1 (or P2) even if they are not crashes, unless of minor usability impact. A regression gives a user reason not to upgrade.
    • Not all crashes are release blockers. For example, a crash bug due to a known driver problem with a particular device would tend to be P2/P3 while being assessed. If the assessment found no code changes that would help, the issue would be moved from the Checklist to Known Issues pending release-noting.
    • Non-crashing, non-regression bugs can be deemed as P1. This depends not only on the impact on usability and the number of users affected, but also on the ease and benefits of fixing compared to leaving "as-is".
    • Bugs initially allocated to lower priorities may be promoted to P1 if a subsequent assessment finds them easy to fix (or demoted from P1 to a release note if they can't be fixed without disproportionate effort).

  • The current de facto standard is that Gale decides on the P numbers for a bug, subject to lobbying from developers.
  • We expect to be rewording the bug title as it becomes clearer what the real problem is.
  • We expect to sometimes solve part of a bug and hence need rewording and/or rating changes.
  • Bug ratings can go up or down.
  • Deciding between a P2 and P3 rating can be difficult when it is a moonphase bug that is suspected as a symptom of some deeper malaise and/or the standards wanted for a non-Beta release may themselves be subject to interpretation.

Discussion of P2: Ctrl+Mouse Whewel causes Crash (hang)


Ed - Thanks for the stack trace - very helpful.

In Ruler.cpp line 1029, in this line UPP can become a NaN (a 'not-a-number')

    double UPP = (mMax-mMin)/mLength

Most likely that's from mLength being zero. Ed, the way to check that theory is to put a test like:

 if( mLength < 0.000000000000001 )

There, and put a breakpoint on the assignment. In temporary debugging code this works better than an ASSERT because when you hit the breakpoint it is easy to check the values of other variables.

The NaN is passed to the 'FindLinearTickSizes', which does not cope with it gracefully. In XP I can scroll out to 312 hours, or in to about 8 samples across the full screen width. It's intriguing that Win7 should behave differently.

This code TrackPanel.cpp line 4158

     if (steps < 0)
        mViewInfo->zoom = wxMax(mViewInfo->zoom / (2.0 * -steps), gMinZoom);
        mViewInfo->zoom = wxMin(mViewInfo->zoom * (2.0 * steps), gMaxZoom);

Is what limits the range in XP.

  • It's just possible the problem isn't so much the mouse wheel itself, and that the same issue can be got by zooming out too far in Win7 using the magnifier button. It's just that the mouse wheel makes it very easy to do that. In that case it's likely the root cause is that XP is making very big or very small numbers where Vista makes NaNs. Ed, could you try that?
  • Another possibility is that for Vista and Win7 in HandleWheelRotation steps can take values, like negative zero, that are not possible in WinXP. The NaN so produced could defeat the wxMin or wxMax. Again the same trick of creating a place for putting a breakpoint can be used to track that down.


First, I can't reproduce this in Windows 7 (x86-64). I don't know why...

Ruler::mLength is an int. There's a test for (mLength <= 0) earlier up in Ruler::Update(). So I doubt mLength is 0. Furthermore, division by 0 in IEEE floating point should give an infinite value, not NaN (unless the numerator is also zero). I'd guess mMin or mMax was NaN coming in to the calculation.

In TrackPanel::HandleWheelRotation() steps is an int also, so it can't be -0 or NaN. But it could be 0. And that would cause mViewInfo.zoom to be set to 0. That might cause this problem -- Ruler's mMin and mMax are set according to values calculated in AdornedRulerPanel::DoDrawMarks, where mViewInfo.zoom is in the denominator (there are some other calculations that might cause it to go NaN instead of INF). I'll send a patch to Ed to test.

-- Ed 24 January 2010:

I am headed to a client's in a few minutes to do a hardware install -- he has a slow 64-bit Windows 7 laptop; I will install 1.3.11 on it and give it a try.

After applying Al's patch scrolling the mouse wheel while holding down the control button did not crash or Assert but it also did not zoom.

Ruler.cpp near line number 500:

  case RealFormat:
     d = 0.000001;
     // mDigits is number of digits after the decimal point.
     mDigits = 6;
     for(;;) {
        if (units < d) {
           mMinor = d;
           mMajor = d*5.0;
        d *= 5.0;
        if (units < d) {
           mMinor = d;
           mMajor = d*2.0;
        d *= 2.0;

if( mDigits < -9.9999999999991 )/* efm5 debug */

  double Bush=mDigits;
        // More than 10 digit numbers?  Something is badly wrong.
        // Probably units is coming in with too high a value.
        //wxASSERT( mDigits >= -10 );/*     efm5     debug     */

after reverting Al's patch, I commented out the Assert so that instead of entering the debugger I would see the crash which happens when I run the non-debug code. What happened was that the program got stuck in the

     for(;;) {

loop. There might be some interesting information here: d 1.#INF000000000000 double mDigits -101508838 int - this 0x04b3a900 {mbTicksOnly=true mbTicksAtExtremes=false mRect={...} ...} Ruler * const mbTicksOnly true bool mbTicksAtExtremes false bool + mRect {x=0 y=0 width=1779 ...} wxRect + mTickColour {m_pixel=33554432 m_isInit=true m_red=0 ...} wxColour + mPen {...} wxPen mMaxWidth 1779 int mMaxHeight 0 int mLeft 1 int mTop 1 int mRight 1780 int mBottom 25 int mLead 0 int mLength 1779 int mLengthOld 1779 int + mDC 0x01ddf0bc {m_paintdc={...} } wxDC * + mMinorFont 0x04b35370 wxFont * + mMajorFont 0x04b7dcd8 wxFont * + mMinorMinorFont 0x04b3ac60 wxFont * mUserFonts false bool mMin -1.#IND000000000000 double mMax -1.#IND000000000000 double mMajor 1.0000000000000000 double mMinor 0.50000000000000000 double mDigits -101508838 int + mUserBits 0x00000000 int * + mBits 0x04b78528 int * mUserBitLen 0 int mValid false bool mNumMajor 0 int + mMajorLabels 0x04b636ac {pos=132 lx=123 ly=6 ...} Ruler::Label * mNumMinor 0 int + mMinorLabels 0x04b6a62c {pos=24 lx=25 ly=21 ...} Ruler::Label * mNumMinorMinor 0 int + mMinorMinorLabels 0x04b715ac {pos=-842150451 lx=-842150451 ly=-842150451 ...} Ruler::Label * mOrientation 4 int mSpacing 6 int mHasSetSpacing false bool mLabelEdges false bool mFormat TimeFormat Ruler::RulerFormat mLog false bool mFlip false bool mCustom false bool mbMinor true bool mMajorGrid false bool mMinorGrid false bool mGridLineLength 0 int + mUnits {...} wxString units -1.#IND000000000000 double

Edit hint: If the discussion above gets very long let's take it to a new page, Bug:Ctrl_Wheel_Crash.

Discussion of P2: Custom FFmpeg Export Options window oversized

    • LRN: There is no apparent way to control widget size with ShuttleGui, all widgets are created with their default size. I've tried to reduce it by shortening text descriptions (they are explained in tooltips anyway) and by setting nChars restriction on two textboxes. As a result, the dialog does look smaller on Windows. Could you please test it on Ubuntu?
    • GA 02Jan10: On Ubuntu it's a bit less wide, but still about 150 px too tall to display OK and Cancel. You can choose format and codec by looking at the text display, click in an options box, hit ENTER then the choice is saved. But how many format/codec combos work? On Windows, I tried WAV format with wmav1, pcm_alaw, adpcm_ima_wav, mp2 and libmp3lame, and all are 0 bytes (including metadata or not). Ogg with FLAC works. WAV/mp2 is 0 bytes on Ubuntu (didn't try others).
    • MJS 03Jan10: Committed a change that makes it < 600 (vertically) here (XP SP3). I would like it better if the ListBoxes for Formats and Codecs went all the way to the bottom of the available space. I believe that James is the expert on that one?
      • JC 06Jan: I'll have a look at this in the next few days. I can certainly extend the list boxes. In worst case a tabbed divider for Options: General/FLAC/MPEG will free up a lot of space.
    • GA 04Jan10: On XP 800x600 for me, all of width is visible, but naturally you can't see the OK or Cancel buttons unless you hide the Taskbar. On Ubuntu, because of the larger fonts, OK and Cancel still off screen even if Taskbar hidden. If you line up left edge of dialogue with left edge of screen, only three preset buttons are visible although all of the Options static box is visible. Note that the format and codec boxes already go down to the bottom of the visible screen here.
      • MJS 04Jan10: Here on XP 800x600 it now fits above the Taskbar with a few px to spare. Reported as OK on Ubuntu 9.04 800x600 by Steve.
      • GA 05Jan10: For XP, I have default font size and DPI, but Tahoma as system font which is a bit taller - that could be the difference. My Ubuntu version is the current 9.10 out-of-the-box (with GNOME). Whatever the reasons for the differences, IMO space shouldn't be so tight that even a trivial change will break it.
    • LRN: OK, so i see a few options here (not considering accessibility issues):
      • 1) Intensive ShuttleGui hacking in order to gain better control over widgets size (either find it or implement it). Might be pointless, because different GTK themes/options will make widgets with different sizes, and i can shrink the dialog only so far.
      • 2) Ugly layout change: restrict window size to available desktop area, add scrollbars to scroll around.
        • MJS 04Jan10: That would be my choice at this stage in the game, if we need it at all.
        • GA 05Jan10: +1. I think the "Show All Formats" list is just too long for a dropdown.
        • LRN: Dropdown lists can also be scrollable, i believe (if they aren't, i could try to create one). Dropdowns are perfect when user doesn't have to see all the options all the time, and when only one option can be selected at the moment. Which is the case.
      • 3) Complex layout change: build the dialog around a few hideable groups of widgets (3DS Max comes in mind). This way groups can be much larger than they are at the moment, while all widgets will be eventually accessible (with some clicking, and maybe scrolling). I don't know whether WX supports such GUI concepts out of the box or not. ShuttleGui certainly doesn't.
      • 4) Advanced layout: go away from the idea of one-widget-with-label-per-option, add a single big (scrollable) treeview widget with all the options, turn codec and format lists into drop-down lists (probably residing in the same treeview). Use freed up space to better arrange everything else.


  • Gale: I've found one scenario where you can't re-open the old project again - launch Audacity and "Save Project as" first, before adding audio to that project. Audacity deletes the original data folder on overwrite in that case, leaving the .aup isolated. The user may or may not want to keep a duplicate project, and they can't keep a duplicate in that case.

    Agreed "overwriting closed projects" should stop as a P3. I do think this is a reasonable expectation and I haven't (yet) found any problems in the overwritten project. Should we link this P3 to a new (P4?) issue to have some kind of "Project Manager" window where as well as duplicating or renaming closed (or possibly) open projects, you could delete a project by deleting the .aup, _data folder and Recent Files entry in one step? I've seen several explicit and many implicit user comments that something like this would be welcomed (at least until we have some kind of unitary project file like a zip with no _data folder). Possibly Save and Open project would actually go into this manager window, not the OS window.

  • James: The previous ability to overwrite a closed project in 1.3.10 might give no warning (if Audacity had provided the .aup extension). Steps to reproduce:
  • Save a project called "foo.aup" and exit.
  • Re-start Audacity and create some completely new audio and SaveAs "foo".
Audacity will extend the name to "foo.aup" and overwrite the previous "foo.aup" without warning.
Not so in CVS HEAD since Audacity stops you overwriting.
  • James: I was too hasty in my original statement about orphan files being left around. There is an explicit call in the save function to remove orphan files that should do the trick. So I have re-instated the 'regression' R. It's not a regression 'bug', but it is a regression in functionality. Losing the ability to write over a project is certainly less bad than projects freezing due to overwrite, particularly as that could happen without a warning. It certainly would need a release note about loss of function, and might still merit a P2. It's a judgement call now. I would still say P3 myself but only just.
  • James: To do over-write of closed projects well is quite a bit of work as we need to force the .aup suffix in the file selector dialog, check it isn't an open project, and prompt the user if it is an overwrite. That's harder than normal since the file dialog is a system dialog that we do not directly control. More importantly we also need to agree that this is what we want.
Yes. Separately we should have a P4 for a project browser in Audacity. In my view it should allows us to work on projects as a unit and gives us extra information in the browser such as total size on disk of all files, audio format, and allows us to easily rename/copy/delete. The compressed file option does not really fly since we then (I believe) lose the speed advantage that is behind having lots of small files so we don't want it as our main format.

  • November 2009 It was agreed to drop "Nyquist effects join separate clips together" from P3 to P2, on the understanding the P3 was commented that there is pressure to fix it (and a plan noted to do so), and given it's now limited to effects below the divider.