Talk:Next Release

From Audacity Wiki
Jump to: navigation, search
James 21Apr15 We have had a discussion about whether this page was useful. It is useful to me, so either we keep it here, or someone moves it to my namespace.
  • Peter wanted to know current status of in/outness (Modules, WDM-KS, Scientific Filters). Whilst Gale called this lobbying, Gale too would like to see in/outness info. This has been now been added to the page.
  • Quality mailing list is IMO probably the best general place to actually lobby about bugs and feature readiness. Not here.
  • I need current status, not something only written close to release.
  • Some changes, like the library changes to Nyquist, need to get a lot of user/developer exercise well before release. We need to see the risky changes right now.
  • 'Decisions' by me/RM here aren't final, but become more and more likely the closer we get to release.


Gale 21Apr15: My concern is mainly about overlapping of tracking and secondly about using this as a lobbying page.
    Tangentially, can Github be lobbied for a "collapsed commit log" that hides or groups merges and any other commits that are code-identical?

James: For me there is no page that does this job yet. I don't see the overlapping. Gitlogs don't summarise. It is not a to-do list Agenda. I've asked Buanzo to at some point before May 15th add wiki bugzilla extension, so we can embed query results in wiki. That would be an improvement

It is not worth lobbying GitHub to change their site. It may make sense to look for a tool to view git logs. Grep could be used to remove merges. Asking developers to use 'squash' and rebase would lead to a much more readable git log.

  • Gale: If RM/others need something now that's fine with me on the understanding that most lobbying is on list. For my personal workflow the long list of "bugs addressed/(probably not reported on)" is redundant tracking, and it's by-hand effort for those adding that tracking. I can see the point in a "keep an eye on" section for special focus.

    Anything that automates production of better release notes or automates a meaningful summary of the git log is welcome to me. It would speed up release and make a page like this more useful. It would never obviate the need to look at the code changes themselves, because the commit message could never be detailed enough to make that un-necessary.


  • Gale: That's covered in the tracking I already do (or some other named individual should volunteer for). The revision # that the tracking has got to is here: http://manual.audacityteam.org/man/Code_Review_2.1.1 .
    • James: (a) That's for the manual, and (b) I need something right now for me and as I write this that page is empty.
Gale 28Jan16: RESOLVED QUICKFIXED was as I understood it reserved for RESOLVED bugs that were not present in previous release. We have no very clear way to query for that below other than by absence of regression flag, which may not be a fully reliable indicator. So should RESOLVED QUICKFIXED apply to a bug that existed for years but was only found out about in a release cycle? That would be a Quick Fix in one sense, not in another.

James 29Jan16: Yes. My view is it is for bugs we didn't know about (no Bugzilla entry) at start of release cycle. From learning about to fixing was quick.

  • Gale 29Jan16: Sounds more like a performance measurement than QA tool, then. I will soon have forgotten when the new release cycle started so I added that info to the top of Audacity Bugzilla.
  • James 30Jan16: QUICKFIXED does mean that it does not appear in any actual release release notes since it was found and fixed in the same release. For the RM it is also an indication of "are we making inroads on old bugs or not?". A QUICKFIXED that fixes an old bug we didn't previously know about is not helping to clear the backlog of bugs that we did know about.... QUICKFIXED is in some ways encouraging to the fixer, as it means we have been responsive. Gale, if you find it is all hassle and no real gain, just say. As it can be done by query instead, it's an experiment/idea that could be dropped if you want.
  • Gale 31Jan16: I don't mind using QUICKFIXED as a resolution now I understand what you want, though it is of little value to me. Bug fixing should target rating and in some cases Cherry IMO, not the date the bug was created. Except possibly if any bug has been left unfixed for years we should look into why.
  • James 01Feb16: A follow up on this.... I have a slight issue with some 'trivia' bugs that are below the level that I want to be paying attention to as RM - things that are so simple to fix they barely need recording, where it is cheaper to just fix them than make a bug report and fix. There are four naming bugs in the current 2.1.3 release fixes that I am glad will end up being marked QUICKFIXED. When I am looking over bugs fixed, it helps. In a parallel universe they would not have been reported because the reporter would have git rights, be able to make the change, and know he had the authority to do so too. Just as we wouldn't raise a bug report for my spelling 'next release' incorrectly in the wiki. We'd just fix it!
  • Gale 01Feb16: You should still look at the rating, because QA could rate some naming issues quite high. For something like adding "Tags" to the name of "Metadata Editor" (P4 and already had QA consensus) I agree it should have just been done without report. If rated higher than P4 then arguably it should still go on Bugzilla.
  • James 01Feb16: Oh as RM I will still look at QUICKFIXED bugs. I look at all bugs. It just means that in the multiple passes, in some of the passes I can skip to other bugs and spend longer on those. QUICKFIXED generally goes with low worry low anxiety. If a bug from long ago has been fixed, then I am wondering whether the fixer has missed the real reason why it was open for so long and I am likely to spend longer digging. QUICKFIXED generally is a clue the bug fixing is flowing well in that area.
  • Steve 01Feb16: Personally I find it useful for trivial bugs to go onto bugzilla if the bug is found by someone that does not have Git access. Such bugs can be and should be fixed very quickly, but if they are not logged formally it is very easy for them to be forgotten about and end up in the next release. Perhaps it would help by marking as QUICKFIX and being rated P5 so that the RM knows that they don't require his/her attention.
  • Gale 01Feb16: I agree if e.g. Peter found a naming bug such as a typo and there is no discussion elsewhere it will ensure it is not missed if it is logged on Bugzilla. The Metadata Editor naming issue however had discussion and (QA) consensus already on Forum so I think arguably that bug report was churn given Steve was intending to fix it (and I would have done so if not, given it is in front of me on the Forum). The bug should always have an appropriate rating. Some P1's will be QUICKFIXED when RESOLVED.
    • Gale 02Feb16: I just realised why I thought QUICKFIXED was for non-regression bugs that users of releases have never seen. These are denoted by the currently unused "was_fixed_quick" keyword: http://bugzilla.audacityteam.org/describekeywords.cgi. This is of (some) interest to me. But there is some bug preventing us using keywords in the BugzillaReports extension isn't there, and the fix here doesn't work.

Proposed Release Announcement

Problem with Is the release ready

Gale 04Jun15: So is the Code Release Ready? is not an indicator of whether the code is release ready because it assumes all P1's have been resolved. James now shows all P1 and P2 that are not resolved or otherwise closed.

Questions for 2.1.2

  • Gale 18Jul15: I have misgivings about reinstating Classic Noise Removal again. I can't find the G+ discussion but I believe the main problems with the new effect are a) users do not change its settings b) Frequency Smoothing in the new effect should not default off (it did not default off in the old effect and the new effect needs it more than the old). In sum, let's fix the new, not ship the old with unfixed new. Having to reinstate the old looks like a headline failure to me.
    • James (talk) A failure even as an optionally enablable effect? Well, we can enable frequency smoothing by default in the new effect, indeed let's fix the new. I don't see it as a failure to offer an option of an old feature.
    • Gale 21Jul15: There are many bugs in the old feature. The new does give the noise reduction stated on the slider, I believe. The old does not provide a fundamentally different feature, it just happens to sound better at certain settings on certain material. That material sometimes contains non-repetitive noise that is part of the signal, but which can suffer in the new effect at zero smoothing.

      Also there is the "what's in a name" syndrome. If as a naive user you could choose between a tool that claimed to "remove" or only "reduce" something you wanted to remove, which would you use?

    • James (talk) Calling it 'classic noise removal' or 'classic noise reduction' does help a bit with the name issue. It is after all disabled by default so only there for peeps who go looking for it. It's not meant for casual users, but for established users who liked the old effect. I originally thought that by allowing effects disabled by default so they don't appear in the menu we could ship even effects that are very niche / marginal utility. If you think that is not so, then what is the standard required to ship an opt-in effect? I am actually OK with dropping Noise Removal. It is just a user asked for it back. If the new menu feature doesn't really let us do that because of other considerations, it isn't doing as much for us as I thought,
    • Gale 21Jul15: About five users I know of have asked to reinstate Noise Removal. But IMO this is only because they have not experimented with the settings in Noise Reduction. In the cases where we had a sample to listen to, it seemed Noise Reduction could be made to give as good or better result than Noise Removal.

      Yes we could reinstate Noise Removal as opt-in, and could reinstate Hard Limiter, Bass Boost (several requests have been made, on the grounds it permitted clipping with 16-bit audio) and other effects we replaced for mostly good reasons. I think a) there are much better new effects we could add as opt-ins, such as a select few from Download Nyquist Plug-ins or the new ACX audio book suitability plugin that has been developed on the Forum. b) I would like to see a less clunky Plug-in Manager with a one-step way to add all new effects, before having a large scale expansion of shipped opt-in effects.

    • Peter 27Jul15: I totally agree with Gale that if we re-introduce the old, buggy, Noise Removal into 2.1.2 albeit set as "disabled" by default that this will encourage the naïve user to use Noise Removal over Noise Reduction - even if we rebrand it as "Classic Noise Removal", as that's what they want removal not just reduction. The old effect is not really "classic", it is at best "legacy".

      My preference would be for us to make the legacy Noise Removal effect available as a downloadable effect from the Download Nyquist Plug-ins page - and clearly mark it there as "legacy" and advise that it is really superseded by the new Noise Reduction and Isolation effect shipped with Audacity. As Gale points out we are only talking about five users (out of our multi-million user base) here, surely they can live with popping the legacy effect in their plug-ins folder and then enabling it.

    • Gale 27Jul15: There is an explicit page for legacy plugins: Nyquist Plug-in Packs and Legacy Plug-ins.
  • Gale 18Jul15: If we are playing with colors in this release I again recommend a suitably code-fixed http://audacity.238276.n2.nabble.com/PATCH-Clip-Colours-td7560793.html . This should not be incompatible with theming. It could modify whatever the theme wave colour was for those clips where the user chose a different colour than the default.
    • James (talk) That patch is pretty terrible. If the colors persist they will need to be in the project file. See the value of it e.g. for two people in a dialog or visually separating music from talk.

Questions for 2.1.1

  • Peter 21May15: Is Modules going to be left turned on for 2.1.1? If so we need to work on the documentation.
    • Gale 22May15: There are two P2's against modules for James to decide on ("old modules shipped with Audacity 1.3.x crash Audacity after enabling the modules in Preferences", and "mod-nyq-bench fails to build on Mac"). Also not on Bugzilla yet but presumably moonphase P2, mod-script-pipe release version compiled on my machine has an unwanted dependency on wxbase28ud_vc_custom.dll (without which debug DLL it won't load). Then when I execute pipe-test.pl I get a debug assertion. I've told James about these problems off list.
  • Peter 26May14: I have no modules present in alpha 26May15 r46a4c4d or 25May r45e70b6 - in 24May 15rbed441d I had mod-nyq-bench, mod-script-pipe and mod-track-panel
    • James (talk) 14:57, 26 May 2015 (EDT) Were they compiled afresh on the same day?
    • Gale 26May15: Neither Paul Livesey or I are distributing modules in the alpha builds because James said these were not to be part of the regular download. Perhaps it is a merge error with an old Audacity installation on Peter's computer?

Format of Release Notes

Gale 27Apr15: The normal practice with the Release Notes hitherto was that fixed bugs which had been P3 or higher were listed in a way that would identify them, even if they were grouped e.g. "Fixed crashes when dragging tracks up and down or when dragging the vertical scrollbar". Bugs (even P1) which did not exist at previous release were not mentioned in the release notes.
  • James: I see the logic of not mentioning 'fleeting' bugs fixed that weren't in a released version. I see the automatically generated table (and query) as useful during development, and as an input to the release notes, rather than being part of the release notes.
  • James: I am thinking about (but undecided) on making the release notes shorter. The length they currently are, I think few people will read them. So I am thinking about making the release notes a summary, with links to bugzilla queries for people who want to delve deeper. For example maybe giving more information for the P1/P2 bugs fixed, and less for P3 (but with links). I probably need to try it to see if it will work OK.
  • Gale: I think the "Changes Since" section of the release notes may merit different treatment to the actual list of bugs in the current release. The former is probably not too long and IMO reads well as text (but could benefit from bug # links). The actual list is long without even listing all the bugs. That said, the list of bugs should not be viewed as something that only functions as a document to be read in full. Many sections of the release notes list of bugs are linked to in support answers and so are currently "usefully verbose", avoiding the need to push the user to the potentially uncomfortable environment of Bugzilla.

    My gut feeling is that P2 and P3 current bugs should retain almost their current verbosity but could benefit from a tabled layout (more economical than the alternative table layout we have now). The table layout makes it look more like a database which is assumed to be large.

    For P4 and below, a single line of text with a link to Bugzilla could be OK, all bugs actually embedded here. Perhaps P4/P5 would remain in their functional groupings - users don't care about our rating, they will often see their bug as a showstopper anyway.

    Has the question of whether the release notes "list of current bugs" is "live" been decided? If it was "live", bugs that are discovered after release are added (we almost do that now in the advice divs) and bugs that have been fixed since release are denoted as such (so users who wanted to be free from that bug could use the alpha). For example I assume if a Bugzilla link was embedded using the extension that it would automatically denote itself as fixed?

WDM-KS

  • Gale 21Apr15: I don't have a firm opinion about making WDM-KS available by a mod or a Preference. A lot depends how intuitive a mod is going to be to install for an average user. Also I don't think we should make WDM-KS available even optionally until there is a plan for "how to test" - deciding what debugging we can include, making the output file as likely to survive the machine freeze/crash as we can make it, and having a thought out QA plan in place to help users and where they agree, gather their debugging info.
    • James: Hmm. Almost nothing will survive a BSOD other than 'About to switch WDMKS on'. I agree to the proposal for a 'test plan for how to test' as a prerequisite before even optional enabling. I think our main focus should be on gathering stats of successful/unsuccessful use. We maybe can never fix broken machines.
    • Gale: My understanding was that Leland was more optimistic than you paint it that some useful debug info could be preserved. It may be incorrect to assume that affected machines/drivers are necessarily broken. We know in some cases that machines that fail with Audacity do not fail with other WDM-KS enabled apps.


Spectral Selection

  • James 20Apr15: Let us have a higher priority bug about spectral selection, but not this one. I think I can word a P2 about bad interaction between spectral and non spectral selection that Gale, and you Peter, would agree is a P2. I think there is a fundamental UI issue to fix, but that if fixed it could be OK for spectral selection to be on by default. If not fixed, we block (on the P2).
    • Gale 21Apr15: I'm interested to see what you come up with, James, but I would probably need some lobbying to make it a P2 (so potential release blocker). The actual complaint (that folk making selections in spectrogram view who don't need a spectral selection get an obscuring spectral selection anyway that makes no difference for the deletion they want to make) doesn't seem more than P3 to me. There is a fundamental issue of how spectral selection when turned on should be integrated with other types of selection, what waveform types it should appear in, what tools it works with and how it integrates with effects where a spectral selection is meaningful. That fundamental design decision isn't a P2 either IMO until we start to make decisions and get them wrong or conflictingly implemented.
    • James: I've over egged Bug 917 about as much as I can now. I want Paul to think harder about UI. He systematically is not thinking enough about ordinary users in all his new features. If you (Gale) want to demote it from P2 I won't push it back up.
    • Gale: Thanks for that new bug, James. I feel the practical severity of bug 917 is not higher than P3 so I made it so, arguing my case in the comments. Release Note (tweaked by me) is good as a warning to those who may be confused by the currently limited usefulness of spectral selection.

Plug-Ins folder" nomenclature consistency

  • Steve 20Apr15: 915 is probably quite a simple change but I'm a bit cautious of clashing with Leland's major project, so perhaps I'll wait a little while for this? Definitely agree that we need to update this sooner or later.
    • James: Should be very doable without treading on toes. Leland totally gets it about collaborative development, so it should be no problem at all. Unlikely to hit exactly the same line as Leland even without waiting. Better to do now, and have it cleared.