Re: running beta of nvda
toggle quoted messageShow quoted text
One counterexample, although not that intuitive, is desktop watermark shown on Windows Insider Preview builds; they are early beta quality builds so folks expect stability when considering small details.
As for changing the debug tone, this will involve changes at the source code, code branch, and deployment level:
Another consideration is communicating errors that developers can catch – not only we get reports from users and try our best to reproduce certain issues, folks use tones as means of debugging and locating errors (whenever we hear a debug tone, we developers would open the NVDA log and read recent tracebacks). This is important as it then allows developers to either fix the issue right away or discuss strategies to do so in the future. For people relying on debug tones for debugging issues, it gives us an early warning so major bugs will not slip to stable releases – this is why when contributors file issues and pull request, if a beta cycle is active and a bug was discovered with a beta build, they are directed to send changes based on latest beta branch commit.
At the moment beta branch is in a “suspended animation” – translators are committing localization updates, and unless critical issues are discovered, the next release from beta channel will be 2020.3 release candidate. As for making debug tones optional or suppressing it in beta releases, it should be something that must be taken care of from alpha channel first i.e. let’s ask NV Access via GitHub.
From: email@example.com <firstname.lastname@example.org> On Behalf Of Brian Vogel
Sent: Monday, September 28, 2020 11:43 AM
Subject: Re: [nvda] running beta of nvda
On Mon, Sep 28, 2020 at 02:32 PM, Joseph Lee wrote:
Brian - Windows 10 Pro, 64-Bit, Version 2004, Build 19041
It’s hard waking up and realizing it’s not always black and white.
~ Kelley Boorn