Talk:Release Checklist

From Audacity Wiki
Revision as of 19:04, 24 January 2010 by Edgar (talk | contribs) (Move discussion 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)

James:


Edit hint: If the discussion above gets very long let's take it to a new page, Bug:Ctrl_Wheel_Crash. -- Ed 24 January 2010 I moved to this

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.

2009

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