Quantcast

Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Stevethefiddle
When a bug is first noticed, there are inevitably many 'unknowns',
which may include:
* Which platforms are effected?
* Is it repeatable on other hardware?
* Is it a regression?
* Is it part of a broader problem?
* Does the symptom characterise the cause?
* Which of the steps that originally produced the problem are required
to reproduce the problem?
* Is it dependent on locale?
* ...

Yes it is good to know the answers to all of these questions when
tackling a fix, but determining the answers is part of the process of
fixing the problem.

At what point do we want to log and begin tracking the issue?

Steve

On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:

>
>
> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>
>> Where I am coming from on this is only indirectly about practicalities and
>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>> visibly see a bug progressing towards closure.
>>
>> My first commit, I hoped, was enough to close the bug:
>>
>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>
>> However, I'd certainly agree the bug title is sufficiently general that it
>> does cover more, and the bug, that I was not aware of, of max copying from
>> min fits under that title too.  I think my real issue was that I didn't get
>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>> less important than the original (minor) issue arrived.  My peve about the
>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>> the bug.
>>
>> My second commit fixes that residual issue too:
>>
>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>
>> However, I am expecting not to get the satisfaction of seeing the bug
>> close from that either.  I gave the reasons in a previous email.  There are
>> residuals (the fix does not yet work in German).  Arguably truncating the
>> frequency display rather than showing '------' for invalid/out-of-range is
>> wrong too.
>>
>> So basically the experience of working on bugs is unsatisfying.  I would
>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>> to P5.  I would feel I had made some progress in resolving an issue.
>>
>> I added a new bug about Spectral Selection Toolbar in German.
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>
>> Maybe this new bug will be enough to allow us to close 1633.
>>
>>
>> This isn't about practicalities.  It's about how it feels to fix bugs.
>> Even though there appear to be two bugs in 1634, I think the experience of
>> working on 1634 might be more satisfying than 1633, as there is a real
>> possibility of feeling one is progressing.  The steps to reproduce are there
>> and define what the bug is, rather than the title doing so.  I think if the
>> steps to reproduce are updated significantly to cover other similar issues,
>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>> Then someone reading the comment trail knows that essentially a new or
>> residual issue is being worked on now, and earlier bug trail is not as
>> important as it was originally, and indeed the original bug may have been
>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>> bug fixer.
>>
>> Again this is not so much about practicalities as about how it feels to
>> fix the bugs.
>
>
> It's also about how it feels to test fixed bugs and then not see them close.
>
> But as we know, even if there are clear Steps To Reproduce and testing
> passes those - Gale will
> usually insist on "testing around" and not just relying on steps-passing to
> close the bug, and that
> can take a lot of time.
>
> Peter
>
>
>
>>
>>
>>
>> --James.
>>
>>
>>
>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>
>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>
>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>> wrote:
>>
>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>
>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>
>> Gale, that issue was not in the steps to reproduce
>>
>> Well, isn't that the very point I have been making? I appreciate others
>> helping out by writing a bug report when they see a user report or
>> when a bug is confirmed on a list, but *everyone* should write proper
>> steps to reproduce (in the Steps to Reproduce) box.
>>
>> When I logged the bug, I had no more information than you.
>> I didn't include all of the detail reported by the person that wrote
>> in to feedback@ because it did not appear to be correct, and in my
>> opinion, incorrect information is worse than incomplete information.
>>
>> User information often isn't correct. If we can't reproduce what
>> they say I think it's better to write steps for what we can
>> reproduce, then refer to the user's discrepant account in the
>> description.
>>
>>
>> If you prefer that I don't log bugs until I have time to work out the
>> full scope of the issue, including detailed steps to reproduce, then
>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>> you.
>>
>> That isn't very efficient, and it is something that can be delegated
>> to everyone with Bugzilla access.
>>
>> I'm a "volunteer" not an employee.
>>
>>
>> However a bug report with no steps to reproduce and a partial
>> description might be no better than one with wrong information,
>> as we saw today. If the person reading it has not seen the user
>> report that generated it, or comes to it a long time after the
>> report, lack of steps can be a serious drawback.
>>
>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>> That looks pretty clear to me that there's one or more problems in the
>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>
>> You have said many times that bugs cannot be closed until the full
>> scope of the bug has been investigated, in fact, that was a reason
>> that you gave for not allowing Peter or myself to close bugs.
>>
>>
>> So I would say go ahead and log please, but not until you are
>> able to add steps.
>>
>> We may not immediately have time to fully analyse the problem and work
>> out steps to fully characterise the problem, and that delay before
>> logging the bug may increase the likelihood of it not being logged at
>> all,  but I accept that it's your decision.
>>
>> Steve
>>
>> The only exception might be a P2/P1 that
>> was found close to release. In that case the RM needs to
>> know ASAP and there should be no shortage of willing hands
>> to fill in the blanks.
>>
>> For bugs that are not time sensitive, perhaps you could say to
>> feedback@ as I sometimes do, that you will add it to the bug
>> tracker when you have completed testing.
>>
>>
>> Thanks
>>
>>
>> Gale
>>
>>
>> See, it's even caught you out now. :=)
>>
>>
>> and my fallback when there are no steps to reproduce is to read comment 0.
>> The issue was not described there either. The email is saying that VI
>> users
>> can't use spectral selection with porpoise (or bat) sounds, and now they
>> can.
>>
>> I only tested with KHz (and MHz).  The bug you report here has a
>> different cause.  One possible fix is to make the number of digits in
>> the Hz display variable, rather than truncate, but that might prove
>> unintuitive for VI users?
>>
>> Can you say then how we would display in Hz, a spectral selection of
>> 120 000 Hz to 180 000 Hz?
>>
>> I can't discuss what technically could be done, but I think it "should"
>> behave as Selection Toolbar does when the format can't show a
>> unique value for the position. That would be consistent.
>>
>>
>> Gale
>>
>>
>> --James.
>>
>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>
>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>
>> So that our VI users who work with bat and/or porpoise sounds are not
>> inconvenienced, I have addressed this issue with following commit:
>>
>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>
>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>> that goes above 100 000 Hz. I think that will be much appreciated, but
>> I don't see that I could resolve the bug just with that.
>>
>> In Hz format, the display of High Frequency remains incorrect above
>> 100 000 Hz. It's the same as Low Frequency.
>>
>> Surely it should show the correct High and Low frequencies with leading
>> truncation, just as when you select in a 38 hour track using samples
>> format,
>> Selection Start and End in Selection Toolbar show different but truncated
>> values.
>>
>>
>> Gale
>>
>>
>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>
>> Steve wrote in:
>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>
>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>> and truncate the leading "1" when 100 kHz or higher (because this is
>> an exceptional case for audio)".
>>
>> For display I might agree, but this does mean that Spectral Selection
>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>> there is no way for VI users to create spectral selections above
>> 100 000 Hz.
>>
>> I don't know if any VI users work with bat or porpoise sounds, but if
>> we compare the case of long audio (say 48 hours) VI users can use
>> Selection Toolbar to create selections or move the cursor because
>> there is a dd:hh:mm:ss format. They won't be able to use samples
>> format because the leading values are truncated, which I agree is
>> reasonable.
>>
>> So, might not at least the kHz format in Spectral Selection Toolbar
>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>> (still only P4) unless there is a technical reason why not.
>>
>>
>> Gale
>>
>>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

James Crook

> At what point do we want to log and begin tracking the issue?
For me, it is when there is enough information that a developer can make
progress on it and feel that they are doing so.  That's pretty early on.

--James.



On 4/17/2017 1:31 PM, Steve the Fiddle wrote:

> When a bug is first noticed, there are inevitably many 'unknowns',
> which may include:
> * Which platforms are effected?
> * Is it repeatable on other hardware?
> * Is it a regression?
> * Is it part of a broader problem?
> * Does the symptom characterise the cause?
> * Which of the steps that originally produced the problem are required
> to reproduce the problem?
> * Is it dependent on locale?
> * ...
>
> Yes it is good to know the answers to all of these questions when
> tackling a fix, but determining the answers is part of the process of
> fixing the problem.
>
> At what point do we want to log and begin tracking the issue?
>
> Steve
>
> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>
>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>> Where I am coming from on this is only indirectly about practicalities and
>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>> visibly see a bug progressing towards closure.
>>>
>>> My first commit, I hoped, was enough to close the bug:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> However, I'd certainly agree the bug title is sufficiently general that it
>>> does cover more, and the bug, that I was not aware of, of max copying from
>>> min fits under that title too.  I think my real issue was that I didn't get
>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>> less important than the original (minor) issue arrived.  My peve about the
>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>> the bug.
>>>
>>> My second commit fixes that residual issue too:
>>>
>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>
>>> However, I am expecting not to get the satisfaction of seeing the bug
>>> close from that either.  I gave the reasons in a previous email.  There are
>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>> frequency display rather than showing '------' for invalid/out-of-range is
>>> wrong too.
>>>
>>> So basically the experience of working on bugs is unsatisfying.  I would
>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>
>>> I added a new bug about Spectral Selection Toolbar in German.
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>
>>> Maybe this new bug will be enough to allow us to close 1633.
>>>
>>>
>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>> Even though there appear to be two bugs in 1634, I think the experience of
>>> working on 1634 might be more satisfying than 1633, as there is a real
>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>> and define what the bug is, rather than the title doing so.  I think if the
>>> steps to reproduce are updated significantly to cover other similar issues,
>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>> Then someone reading the comment trail knows that essentially a new or
>>> residual issue is being worked on now, and earlier bug trail is not as
>>> important as it was originally, and indeed the original bug may have been
>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>> bug fixer.
>>>
>>> Again this is not so much about practicalities as about how it feels to
>>> fix the bugs.
>>
>> It's also about how it feels to test fixed bugs and then not see them close.
>>
>> But as we know, even if there are clear Steps To Reproduce and testing
>> passes those - Gale will
>> usually insist on "testing around" and not just relying on steps-passing to
>> close the bug, and that
>> can take a lot of time.
>>
>> Peter
>>
>>
>>
>>>
>>>
>>> --James.
>>>
>>>
>>>
>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>
>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>
>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>
>>> Gale, that issue was not in the steps to reproduce
>>>
>>> Well, isn't that the very point I have been making? I appreciate others
>>> helping out by writing a bug report when they see a user report or
>>> when a bug is confirmed on a list, but *everyone* should write proper
>>> steps to reproduce (in the Steps to Reproduce) box.
>>>
>>> When I logged the bug, I had no more information than you.
>>> I didn't include all of the detail reported by the person that wrote
>>> in to feedback@ because it did not appear to be correct, and in my
>>> opinion, incorrect information is worse than incomplete information.
>>>
>>> User information often isn't correct. If we can't reproduce what
>>> they say I think it's better to write steps for what we can
>>> reproduce, then refer to the user's discrepant account in the
>>> description.
>>>
>>>
>>> If you prefer that I don't log bugs until I have time to work out the
>>> full scope of the issue, including detailed steps to reproduce, then
>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>> you.
>>>
>>> That isn't very efficient, and it is something that can be delegated
>>> to everyone with Bugzilla access.
>>>
>>> I'm a "volunteer" not an employee.
>>>
>>>
>>> However a bug report with no steps to reproduce and a partial
>>> description might be no better than one with wrong information,
>>> as we saw today. If the person reading it has not seen the user
>>> report that generated it, or comes to it a long time after the
>>> report, lack of steps can be a serious drawback.
>>>
>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>> That looks pretty clear to me that there's one or more problems in the
>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>
>>> You have said many times that bugs cannot be closed until the full
>>> scope of the bug has been investigated, in fact, that was a reason
>>> that you gave for not allowing Peter or myself to close bugs.
>>>
>>>
>>> So I would say go ahead and log please, but not until you are
>>> able to add steps.
>>>
>>> We may not immediately have time to fully analyse the problem and work
>>> out steps to fully characterise the problem, and that delay before
>>> logging the bug may increase the likelihood of it not being logged at
>>> all,  but I accept that it's your decision.
>>>
>>> Steve
>>>
>>> The only exception might be a P2/P1 that
>>> was found close to release. In that case the RM needs to
>>> know ASAP and there should be no shortage of willing hands
>>> to fill in the blanks.
>>>
>>> For bugs that are not time sensitive, perhaps you could say to
>>> feedback@ as I sometimes do, that you will add it to the bug
>>> tracker when you have completed testing.
>>>
>>>
>>> Thanks
>>>
>>>
>>> Gale
>>>
>>>
>>> See, it's even caught you out now. :=)
>>>
>>>
>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>> The issue was not described there either. The email is saying that VI
>>> users
>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>> can.
>>>
>>> I only tested with KHz (and MHz).  The bug you report here has a
>>> different cause.  One possible fix is to make the number of digits in
>>> the Hz display variable, rather than truncate, but that might prove
>>> unintuitive for VI users?
>>>
>>> Can you say then how we would display in Hz, a spectral selection of
>>> 120 000 Hz to 180 000 Hz?
>>>
>>> I can't discuss what technically could be done, but I think it "should"
>>> behave as Selection Toolbar does when the format can't show a
>>> unique value for the position. That would be consistent.
>>>
>>>
>>> Gale
>>>
>>>
>>> --James.
>>>
>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>
>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>
>>> So that our VI users who work with bat and/or porpoise sounds are not
>>> inconvenienced, I have addressed this issue with following commit:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>> I don't see that I could resolve the bug just with that.
>>>
>>> In Hz format, the display of High Frequency remains incorrect above
>>> 100 000 Hz. It's the same as Low Frequency.
>>>
>>> Surely it should show the correct High and Low frequencies with leading
>>> truncation, just as when you select in a 38 hour track using samples
>>> format,
>>> Selection Start and End in Selection Toolbar show different but truncated
>>> values.
>>>
>>>
>>> Gale
>>>
>>>
>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>
>>> Steve wrote in:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>
>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>> an exceptional case for audio)".
>>>
>>> For display I might agree, but this does mean that Spectral Selection
>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>> there is no way for VI users to create spectral selections above
>>> 100 000 Hz.
>>>
>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>> we compare the case of long audio (say 48 hours) VI users can use
>>> Selection Toolbar to create selections or move the cursor because
>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>> format because the leading values are truncated, which I agree is
>>> reasonable.
>>>
>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>> (still only P4) unless there is a technical reason why not.
>>>
>>>
>>> Gale
>>>
>>>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Gale
Administrator
Do you agree then James that 1633 was posted too early for you
to make progress on it? Let's assume I had not e-mailed about
the separate issue Steve raised in the description, and all you
had to go on was the description.



Gale


On 17 April 2017 at 13:36, James Crook <[hidden email]> wrote:

>
>> At what point do we want to log and begin tracking the issue?
> For me, it is when there is enough information that a developer can make
> progress on it and feel that they are doing so.  That's pretty early on.
>
> --James.
>
>
>
> On 4/17/2017 1:31 PM, Steve the Fiddle wrote:
>> When a bug is first noticed, there are inevitably many 'unknowns',
>> which may include:
>> * Which platforms are effected?
>> * Is it repeatable on other hardware?
>> * Is it a regression?
>> * Is it part of a broader problem?
>> * Does the symptom characterise the cause?
>> * Which of the steps that originally produced the problem are required
>> to reproduce the problem?
>> * Is it dependent on locale?
>> * ...
>>
>> Yes it is good to know the answers to all of these questions when
>> tackling a fix, but determining the answers is part of the process of
>> fixing the problem.
>>
>> At what point do we want to log and begin tracking the issue?
>>
>> Steve
>>
>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>
>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>> Where I am coming from on this is only indirectly about practicalities and
>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>> visibly see a bug progressing towards closure.
>>>>
>>>> My first commit, I hoped, was enough to close the bug:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>> less important than the original (minor) issue arrived.  My peve about the
>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>> the bug.
>>>>
>>>> My second commit fixes that residual issue too:
>>>>
>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>
>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>> wrong too.
>>>>
>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>
>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>
>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>
>>>>
>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>> Then someone reading the comment trail knows that essentially a new or
>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>> important as it was originally, and indeed the original bug may have been
>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>> bug fixer.
>>>>
>>>> Again this is not so much about practicalities as about how it feels to
>>>> fix the bugs.
>>>
>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>
>>> But as we know, even if there are clear Steps To Reproduce and testing
>>> passes those - Gale will
>>> usually insist on "testing around" and not just relying on steps-passing to
>>> close the bug, and that
>>> can take a lot of time.
>>>
>>> Peter
>>>
>>>
>>>
>>>>
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>
>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>> wrote:
>>>>
>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>
>>>> Gale, that issue was not in the steps to reproduce
>>>>
>>>> Well, isn't that the very point I have been making? I appreciate others
>>>> helping out by writing a bug report when they see a user report or
>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>
>>>> When I logged the bug, I had no more information than you.
>>>> I didn't include all of the detail reported by the person that wrote
>>>> in to feedback@ because it did not appear to be correct, and in my
>>>> opinion, incorrect information is worse than incomplete information.
>>>>
>>>> User information often isn't correct. If we can't reproduce what
>>>> they say I think it's better to write steps for what we can
>>>> reproduce, then refer to the user's discrepant account in the
>>>> description.
>>>>
>>>>
>>>> If you prefer that I don't log bugs until I have time to work out the
>>>> full scope of the issue, including detailed steps to reproduce, then
>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>> you.
>>>>
>>>> That isn't very efficient, and it is something that can be delegated
>>>> to everyone with Bugzilla access.
>>>>
>>>> I'm a "volunteer" not an employee.
>>>>
>>>>
>>>> However a bug report with no steps to reproduce and a partial
>>>> description might be no better than one with wrong information,
>>>> as we saw today. If the person reading it has not seen the user
>>>> report that generated it, or comes to it a long time after the
>>>> report, lack of steps can be a serious drawback.
>>>>
>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>> That looks pretty clear to me that there's one or more problems in the
>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>
>>>> You have said many times that bugs cannot be closed until the full
>>>> scope of the bug has been investigated, in fact, that was a reason
>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>
>>>>
>>>> So I would say go ahead and log please, but not until you are
>>>> able to add steps.
>>>>
>>>> We may not immediately have time to fully analyse the problem and work
>>>> out steps to fully characterise the problem, and that delay before
>>>> logging the bug may increase the likelihood of it not being logged at
>>>> all,  but I accept that it's your decision.
>>>>
>>>> Steve
>>>>
>>>> The only exception might be a P2/P1 that
>>>> was found close to release. In that case the RM needs to
>>>> know ASAP and there should be no shortage of willing hands
>>>> to fill in the blanks.
>>>>
>>>> For bugs that are not time sensitive, perhaps you could say to
>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>> tracker when you have completed testing.
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> See, it's even caught you out now. :=)
>>>>
>>>>
>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>> The issue was not described there either. The email is saying that VI
>>>> users
>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>> can.
>>>>
>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>> different cause.  One possible fix is to make the number of digits in
>>>> the Hz display variable, rather than truncate, but that might prove
>>>> unintuitive for VI users?
>>>>
>>>> Can you say then how we would display in Hz, a spectral selection of
>>>> 120 000 Hz to 180 000 Hz?
>>>>
>>>> I can't discuss what technically could be done, but I think it "should"
>>>> behave as Selection Toolbar does when the format can't show a
>>>> unique value for the position. That would be consistent.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> --James.
>>>>
>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>
>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>
>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>> inconvenienced, I have addressed this issue with following commit:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>> I don't see that I could resolve the bug just with that.
>>>>
>>>> In Hz format, the display of High Frequency remains incorrect above
>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>
>>>> Surely it should show the correct High and Low frequencies with leading
>>>> truncation, just as when you select in a 38 hour track using samples
>>>> format,
>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>> values.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>
>>>> Steve wrote in:
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>
>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>> an exceptional case for audio)".
>>>>
>>>> For display I might agree, but this does mean that Spectral Selection
>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>> there is no way for VI users to create spectral selections above
>>>> 100 000 Hz.
>>>>
>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>> Selection Toolbar to create selections or move the cursor because
>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>> format because the leading values are truncated, which I agree is
>>>> reasonable.
>>>>
>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>> (still only P4) unless there is a technical reason why not.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Gale
Administrator
In reply to this post by Stevethefiddle
I am not proposing to duplicate my previous reply, beyond this.

At a minimum, post at least one set of reproducible steps that
a tester or developer could follow, and set the platform to
whatever platform you tested on.

You can include another platform that a user reported the issue
on if you can partly reproduce what the user said, but mention
the part-reproducibility in the description.



Gale


On 17 April 2017 at 13:31, Steve the Fiddle <[hidden email]> wrote:

> When a bug is first noticed, there are inevitably many 'unknowns',
> which may include:
> * Which platforms are effected?
> * Is it repeatable on other hardware?
> * Is it a regression?
> * Is it part of a broader problem?
> * Does the symptom characterise the cause?
> * Which of the steps that originally produced the problem are required
> to reproduce the problem?
> * Is it dependent on locale?
> * ...
>
> Yes it is good to know the answers to all of these questions when
> tackling a fix, but determining the answers is part of the process of
> fixing the problem.
>
> At what point do we want to log and begin tracking the issue?
>
> Steve
>
> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>
>>
>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>
>>> Where I am coming from on this is only indirectly about practicalities and
>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>> visibly see a bug progressing towards closure.
>>>
>>> My first commit, I hoped, was enough to close the bug:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> However, I'd certainly agree the bug title is sufficiently general that it
>>> does cover more, and the bug, that I was not aware of, of max copying from
>>> min fits under that title too.  I think my real issue was that I didn't get
>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>> less important than the original (minor) issue arrived.  My peve about the
>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>> the bug.
>>>
>>> My second commit fixes that residual issue too:
>>>
>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>
>>> However, I am expecting not to get the satisfaction of seeing the bug
>>> close from that either.  I gave the reasons in a previous email.  There are
>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>> frequency display rather than showing '------' for invalid/out-of-range is
>>> wrong too.
>>>
>>> So basically the experience of working on bugs is unsatisfying.  I would
>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>
>>> I added a new bug about Spectral Selection Toolbar in German.
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>
>>> Maybe this new bug will be enough to allow us to close 1633.
>>>
>>>
>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>> Even though there appear to be two bugs in 1634, I think the experience of
>>> working on 1634 might be more satisfying than 1633, as there is a real
>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>> and define what the bug is, rather than the title doing so.  I think if the
>>> steps to reproduce are updated significantly to cover other similar issues,
>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>> Then someone reading the comment trail knows that essentially a new or
>>> residual issue is being worked on now, and earlier bug trail is not as
>>> important as it was originally, and indeed the original bug may have been
>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>> bug fixer.
>>>
>>> Again this is not so much about practicalities as about how it feels to
>>> fix the bugs.
>>
>>
>> It's also about how it feels to test fixed bugs and then not see them close.
>>
>> But as we know, even if there are clear Steps To Reproduce and testing
>> passes those - Gale will
>> usually insist on "testing around" and not just relying on steps-passing to
>> close the bug, and that
>> can take a lot of time.
>>
>> Peter
>>
>>
>>
>>>
>>>
>>>
>>> --James.
>>>
>>>
>>>
>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>
>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>
>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>
>>> Gale, that issue was not in the steps to reproduce
>>>
>>> Well, isn't that the very point I have been making? I appreciate others
>>> helping out by writing a bug report when they see a user report or
>>> when a bug is confirmed on a list, but *everyone* should write proper
>>> steps to reproduce (in the Steps to Reproduce) box.
>>>
>>> When I logged the bug, I had no more information than you.
>>> I didn't include all of the detail reported by the person that wrote
>>> in to feedback@ because it did not appear to be correct, and in my
>>> opinion, incorrect information is worse than incomplete information.
>>>
>>> User information often isn't correct. If we can't reproduce what
>>> they say I think it's better to write steps for what we can
>>> reproduce, then refer to the user's discrepant account in the
>>> description.
>>>
>>>
>>> If you prefer that I don't log bugs until I have time to work out the
>>> full scope of the issue, including detailed steps to reproduce, then
>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>> you.
>>>
>>> That isn't very efficient, and it is something that can be delegated
>>> to everyone with Bugzilla access.
>>>
>>> I'm a "volunteer" not an employee.
>>>
>>>
>>> However a bug report with no steps to reproduce and a partial
>>> description might be no better than one with wrong information,
>>> as we saw today. If the person reading it has not seen the user
>>> report that generated it, or comes to it a long time after the
>>> report, lack of steps can be a serious drawback.
>>>
>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>> That looks pretty clear to me that there's one or more problems in the
>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>
>>> You have said many times that bugs cannot be closed until the full
>>> scope of the bug has been investigated, in fact, that was a reason
>>> that you gave for not allowing Peter or myself to close bugs.
>>>
>>>
>>> So I would say go ahead and log please, but not until you are
>>> able to add steps.
>>>
>>> We may not immediately have time to fully analyse the problem and work
>>> out steps to fully characterise the problem, and that delay before
>>> logging the bug may increase the likelihood of it not being logged at
>>> all,  but I accept that it's your decision.
>>>
>>> Steve
>>>
>>> The only exception might be a P2/P1 that
>>> was found close to release. In that case the RM needs to
>>> know ASAP and there should be no shortage of willing hands
>>> to fill in the blanks.
>>>
>>> For bugs that are not time sensitive, perhaps you could say to
>>> feedback@ as I sometimes do, that you will add it to the bug
>>> tracker when you have completed testing.
>>>
>>>
>>> Thanks
>>>
>>>
>>> Gale
>>>
>>>
>>> See, it's even caught you out now. :=)
>>>
>>>
>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>> The issue was not described there either. The email is saying that VI
>>> users
>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>> can.
>>>
>>> I only tested with KHz (and MHz).  The bug you report here has a
>>> different cause.  One possible fix is to make the number of digits in
>>> the Hz display variable, rather than truncate, but that might prove
>>> unintuitive for VI users?
>>>
>>> Can you say then how we would display in Hz, a spectral selection of
>>> 120 000 Hz to 180 000 Hz?
>>>
>>> I can't discuss what technically could be done, but I think it "should"
>>> behave as Selection Toolbar does when the format can't show a
>>> unique value for the position. That would be consistent.
>>>
>>>
>>> Gale
>>>
>>>
>>> --James.
>>>
>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>
>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>
>>> So that our VI users who work with bat and/or porpoise sounds are not
>>> inconvenienced, I have addressed this issue with following commit:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>> I don't see that I could resolve the bug just with that.
>>>
>>> In Hz format, the display of High Frequency remains incorrect above
>>> 100 000 Hz. It's the same as Low Frequency.
>>>
>>> Surely it should show the correct High and Low frequencies with leading
>>> truncation, just as when you select in a 38 hour track using samples
>>> format,
>>> Selection Start and End in Selection Toolbar show different but truncated
>>> values.
>>>
>>>
>>> Gale
>>>
>>>
>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>
>>> Steve wrote in:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>
>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>> an exceptional case for audio)".
>>>
>>> For display I might agree, but this does mean that Spectral Selection
>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>> there is no way for VI users to create spectral selections above
>>> 100 000 Hz.
>>>
>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>> we compare the case of long audio (say 48 hours) VI users can use
>>> Selection Toolbar to create selections or move the cursor because
>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>> format because the leading values are truncated, which I agree is
>>> reasonable.
>>>
>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>> (still only P4) unless there is a technical reason why not.
>>>
>>>
>>> Gale
>>>
>>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Stevethefiddle
A user "kensmbour" posted a bug report to feedback@ three days ago in
a post titled "small noticeable occurence" (sic)
Have you logged that somewhere Gale? If you have, where? If not, how
do we prevent it from getting lost?

Steve

On 17 April 2017 at 16:31, Gale Andrews <[hidden email]> wrote:

> I am not proposing to duplicate my previous reply, beyond this.
>
> At a minimum, post at least one set of reproducible steps that
> a tester or developer could follow, and set the platform to
> whatever platform you tested on.
>
> You can include another platform that a user reported the issue
> on if you can partly reproduce what the user said, but mention
> the part-reproducibility in the description.
>
>
>
> Gale
>
>
> On 17 April 2017 at 13:31, Steve the Fiddle <[hidden email]> wrote:
>> When a bug is first noticed, there are inevitably many 'unknowns',
>> which may include:
>> * Which platforms are effected?
>> * Is it repeatable on other hardware?
>> * Is it a regression?
>> * Is it part of a broader problem?
>> * Does the symptom characterise the cause?
>> * Which of the steps that originally produced the problem are required
>> to reproduce the problem?
>> * Is it dependent on locale?
>> * ...
>>
>> Yes it is good to know the answers to all of these questions when
>> tackling a fix, but determining the answers is part of the process of
>> fixing the problem.
>>
>> At what point do we want to log and begin tracking the issue?
>>
>> Steve
>>
>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>
>>>
>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>
>>>> Where I am coming from on this is only indirectly about practicalities and
>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>> visibly see a bug progressing towards closure.
>>>>
>>>> My first commit, I hoped, was enough to close the bug:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>> less important than the original (minor) issue arrived.  My peve about the
>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>> the bug.
>>>>
>>>> My second commit fixes that residual issue too:
>>>>
>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>
>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>> wrong too.
>>>>
>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>
>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>
>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>
>>>>
>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>> Then someone reading the comment trail knows that essentially a new or
>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>> important as it was originally, and indeed the original bug may have been
>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>> bug fixer.
>>>>
>>>> Again this is not so much about practicalities as about how it feels to
>>>> fix the bugs.
>>>
>>>
>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>
>>> But as we know, even if there are clear Steps To Reproduce and testing
>>> passes those - Gale will
>>> usually insist on "testing around" and not just relying on steps-passing to
>>> close the bug, and that
>>> can take a lot of time.
>>>
>>> Peter
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>
>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>> wrote:
>>>>
>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>
>>>> Gale, that issue was not in the steps to reproduce
>>>>
>>>> Well, isn't that the very point I have been making? I appreciate others
>>>> helping out by writing a bug report when they see a user report or
>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>
>>>> When I logged the bug, I had no more information than you.
>>>> I didn't include all of the detail reported by the person that wrote
>>>> in to feedback@ because it did not appear to be correct, and in my
>>>> opinion, incorrect information is worse than incomplete information.
>>>>
>>>> User information often isn't correct. If we can't reproduce what
>>>> they say I think it's better to write steps for what we can
>>>> reproduce, then refer to the user's discrepant account in the
>>>> description.
>>>>
>>>>
>>>> If you prefer that I don't log bugs until I have time to work out the
>>>> full scope of the issue, including detailed steps to reproduce, then
>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>> you.
>>>>
>>>> That isn't very efficient, and it is something that can be delegated
>>>> to everyone with Bugzilla access.
>>>>
>>>> I'm a "volunteer" not an employee.
>>>>
>>>>
>>>> However a bug report with no steps to reproduce and a partial
>>>> description might be no better than one with wrong information,
>>>> as we saw today. If the person reading it has not seen the user
>>>> report that generated it, or comes to it a long time after the
>>>> report, lack of steps can be a serious drawback.
>>>>
>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>> That looks pretty clear to me that there's one or more problems in the
>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>
>>>> You have said many times that bugs cannot be closed until the full
>>>> scope of the bug has been investigated, in fact, that was a reason
>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>
>>>>
>>>> So I would say go ahead and log please, but not until you are
>>>> able to add steps.
>>>>
>>>> We may not immediately have time to fully analyse the problem and work
>>>> out steps to fully characterise the problem, and that delay before
>>>> logging the bug may increase the likelihood of it not being logged at
>>>> all,  but I accept that it's your decision.
>>>>
>>>> Steve
>>>>
>>>> The only exception might be a P2/P1 that
>>>> was found close to release. In that case the RM needs to
>>>> know ASAP and there should be no shortage of willing hands
>>>> to fill in the blanks.
>>>>
>>>> For bugs that are not time sensitive, perhaps you could say to
>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>> tracker when you have completed testing.
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> See, it's even caught you out now. :=)
>>>>
>>>>
>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>> The issue was not described there either. The email is saying that VI
>>>> users
>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>> can.
>>>>
>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>> different cause.  One possible fix is to make the number of digits in
>>>> the Hz display variable, rather than truncate, but that might prove
>>>> unintuitive for VI users?
>>>>
>>>> Can you say then how we would display in Hz, a spectral selection of
>>>> 120 000 Hz to 180 000 Hz?
>>>>
>>>> I can't discuss what technically could be done, but I think it "should"
>>>> behave as Selection Toolbar does when the format can't show a
>>>> unique value for the position. That would be consistent.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> --James.
>>>>
>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>
>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>
>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>> inconvenienced, I have addressed this issue with following commit:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>> I don't see that I could resolve the bug just with that.
>>>>
>>>> In Hz format, the display of High Frequency remains incorrect above
>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>
>>>> Surely it should show the correct High and Low frequencies with leading
>>>> truncation, just as when you select in a 38 hour track using samples
>>>> format,
>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>> values.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>
>>>> Steve wrote in:
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>
>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>> an exceptional case for audio)".
>>>>
>>>> For display I might agree, but this does mean that Spectral Selection
>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>> there is no way for VI users to create spectral selections above
>>>> 100 000 Hz.
>>>>
>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>> Selection Toolbar to create selections or move the cursor because
>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>> format because the leading values are truncated, which I agree is
>>>> reasonable.
>>>>
>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>> (still only P4) unless there is a technical reason why not.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

James Crook
In reply to this post by Gale
On 4/17/2017 4:22 PM, Gale Andrews wrote:
> Do you agree then James that 1633 was posted too early for you
> to make progress on it? Let's assume I had not e-mailed about
> the separate issue Steve raised in the description, and all you
> had to go on was the description.

The description had just enough in it for me to DEVEL-FIX the bug.

So in that sense it was ready to work on..

However, correctly, my 'fix' did not close the bug, because there was a
bug still.  That made me feel I hadn't made progress.

So in that sense the bug was not 'ready to be worked on'.


This bug is not really bugging me.  It's only 6 items in the comment
trail so far.  The bugs that frustrate me have constantly mutating steps
to reproduce.  I hadn't seen before that that is the key thing that
makes them frustrating.  If we accept that we often re-use an original
bug for 'residuals', possibly updating the steps to reproduce and the
title when we do, then we need to do something more.

I propose that when a developer marks a bug as DEVEL-FIXED they should
post steps to reproduce if there were none such already.  By saying
DEVEL-FIXED the developer is claiming, as a minimum, that the steps to
reproduce no longer reproduce the issue.  If they are wrong, a straight
REOPEN is fine.  If they are right, but updated steps show there is
still a bug, then ***Steps-Updated*** in the log would make a huge
difference.  When reading the comment trail I only HAVE to read down to
the first ***Steps Updated***.  Testers know there is a reason why their
'tested' flags are being cancelled, developer knows why there
DEVEL-FIXED isn't closing it, and so on. ***Steps Updated*** becomes a
clear mark of progress.  [Not needed when going from empty steps to some
steps, of course].

IF we do that, then this bug was ready to work on when Steve posted the
description.


--James.

>
>
>
> Gale
>
>
> On 17 April 2017 at 13:36, James Crook <[hidden email]> wrote:
>>> At what point do we want to log and begin tracking the issue?
>> For me, it is when there is enough information that a developer can make
>> progress on it and feel that they are doing so.  That's pretty early on.
>>
>> --James.
>>
>>
>>
>> On 4/17/2017 1:31 PM, Steve the Fiddle wrote:
>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>> which may include:
>>> * Which platforms are effected?
>>> * Is it repeatable on other hardware?
>>> * Is it a regression?
>>> * Is it part of a broader problem?
>>> * Does the symptom characterise the cause?
>>> * Which of the steps that originally produced the problem are required
>>> to reproduce the problem?
>>> * Is it dependent on locale?
>>> * ...
>>>
>>> Yes it is good to know the answers to all of these questions when
>>> tackling a fix, but determining the answers is part of the process of
>>> fixing the problem.
>>>
>>> At what point do we want to log and begin tracking the issue?
>>>
>>> Steve
>>>
>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>> visibly see a bug progressing towards closure.
>>>>>
>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>
>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>> the bug.
>>>>>
>>>>> My second commit fixes that residual issue too:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>
>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>> wrong too.
>>>>>
>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>
>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>
>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>
>>>>>
>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>> important as it was originally, and indeed the original bug may have been
>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>> bug fixer.
>>>>>
>>>>> Again this is not so much about practicalities as about how it feels to
>>>>> fix the bugs.
>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>
>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>> passes those - Gale will
>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>> close the bug, and that
>>>> can take a lot of time.
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>>>
>>>>> --James.
>>>>>
>>>>>
>>>>>
>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>
>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>
>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>
>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>
>>>>> Gale, that issue was not in the steps to reproduce
>>>>>
>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>> helping out by writing a bug report when they see a user report or
>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>
>>>>> When I logged the bug, I had no more information than you.
>>>>> I didn't include all of the detail reported by the person that wrote
>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>
>>>>> User information often isn't correct. If we can't reproduce what
>>>>> they say I think it's better to write steps for what we can
>>>>> reproduce, then refer to the user's discrepant account in the
>>>>> description.
>>>>>
>>>>>
>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>> you.
>>>>>
>>>>> That isn't very efficient, and it is something that can be delegated
>>>>> to everyone with Bugzilla access.
>>>>>
>>>>> I'm a "volunteer" not an employee.
>>>>>
>>>>>
>>>>> However a bug report with no steps to reproduce and a partial
>>>>> description might be no better than one with wrong information,
>>>>> as we saw today. If the person reading it has not seen the user
>>>>> report that generated it, or comes to it a long time after the
>>>>> report, lack of steps can be a serious drawback.
>>>>>
>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>
>>>>> You have said many times that bugs cannot be closed until the full
>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>
>>>>>
>>>>> So I would say go ahead and log please, but not until you are
>>>>> able to add steps.
>>>>>
>>>>> We may not immediately have time to fully analyse the problem and work
>>>>> out steps to fully characterise the problem, and that delay before
>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>> all,  but I accept that it's your decision.
>>>>>
>>>>> Steve
>>>>>
>>>>> The only exception might be a P2/P1 that
>>>>> was found close to release. In that case the RM needs to
>>>>> know ASAP and there should be no shortage of willing hands
>>>>> to fill in the blanks.
>>>>>
>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>> tracker when you have completed testing.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> See, it's even caught you out now. :=)
>>>>>
>>>>>
>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>> The issue was not described there either. The email is saying that VI
>>>>> users
>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>> can.
>>>>>
>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>> different cause.  One possible fix is to make the number of digits in
>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>> unintuitive for VI users?
>>>>>
>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>> 120 000 Hz to 180 000 Hz?
>>>>>
>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>> behave as Selection Toolbar does when the format can't show a
>>>>> unique value for the position. That would be consistent.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> --James.
>>>>>
>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>
>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>
>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>
>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>> I don't see that I could resolve the bug just with that.
>>>>>
>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>
>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>> format,
>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>> values.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>
>>>>> Steve wrote in:
>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>
>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>> an exceptional case for audio)".
>>>>>
>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>> there is no way for VI users to create spectral selections above
>>>>> 100 000 Hz.
>>>>>
>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>> Selection Toolbar to create selections or move the cursor because
>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>> format because the leading values are truncated, which I agree is
>>>>> reasonable.
>>>>>
>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>> (still only P4) unless there is a technical reason why not.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Gale
Administrator
In reply to this post by Stevethefiddle
I believe you are misleading this list, Steve. I replied promptly and
asked for more details because I was not able to reproduce the
issue (because I was testing fitting into tight spaces, where I was
often using CTRL).

The user came back 10 hours ago with a video, then further after
that, you said you could reproduce the issue on Linux. So the
timescales are not as you describe.

I can (about half the time) reproduce the issue now, but for me it
is definitely moonphase. There are good workarounds.

I store bugs that I can't add reasonably promptly to Bugzilla
(for whatever reason) on my local file system. So they don't get
lost, but that does not even apply in this case.

Anything I do or don't do in Bugzilla is subject to health. If I can
barely stand or keep my eyes open, as was the case for a week
or so at the end of March, then local storage may be all that
happens.



Gale


On 17 April 2017 at 16:51, Steve the Fiddle <[hidden email]> wrote:

> A user "kensmbour" posted a bug report to feedback@ three days ago in
> a post titled "small noticeable occurence" (sic)
> Have you logged that somewhere Gale? If you have, where? If not, how
> do we prevent it from getting lost?
>
> Steve
>
> On 17 April 2017 at 16:31, Gale Andrews <[hidden email]> wrote:
>> I am not proposing to duplicate my previous reply, beyond this.
>>
>> At a minimum, post at least one set of reproducible steps that
>> a tester or developer could follow, and set the platform to
>> whatever platform you tested on.
>>
>> You can include another platform that a user reported the issue
>> on if you can partly reproduce what the user said, but mention
>> the part-reproducibility in the description.
>>
>>
>>
>> Gale
>>
>>
>> On 17 April 2017 at 13:31, Steve the Fiddle <[hidden email]> wrote:
>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>> which may include:
>>> * Which platforms are effected?
>>> * Is it repeatable on other hardware?
>>> * Is it a regression?
>>> * Is it part of a broader problem?
>>> * Does the symptom characterise the cause?
>>> * Which of the steps that originally produced the problem are required
>>> to reproduce the problem?
>>> * Is it dependent on locale?
>>> * ...
>>>
>>> Yes it is good to know the answers to all of these questions when
>>> tackling a fix, but determining the answers is part of the process of
>>> fixing the problem.
>>>
>>> At what point do we want to log and begin tracking the issue?
>>>
>>> Steve
>>>
>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>
>>>>
>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>
>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>> visibly see a bug progressing towards closure.
>>>>>
>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>
>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>> the bug.
>>>>>
>>>>> My second commit fixes that residual issue too:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>
>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>> wrong too.
>>>>>
>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>
>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>
>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>
>>>>>
>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>> important as it was originally, and indeed the original bug may have been
>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>> bug fixer.
>>>>>
>>>>> Again this is not so much about practicalities as about how it feels to
>>>>> fix the bugs.
>>>>
>>>>
>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>
>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>> passes those - Gale will
>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>> close the bug, and that
>>>> can take a lot of time.
>>>>
>>>> Peter
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> --James.
>>>>>
>>>>>
>>>>>
>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>
>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>
>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>> wrote:
>>>>>
>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>
>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>
>>>>> Gale, that issue was not in the steps to reproduce
>>>>>
>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>> helping out by writing a bug report when they see a user report or
>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>
>>>>> When I logged the bug, I had no more information than you.
>>>>> I didn't include all of the detail reported by the person that wrote
>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>
>>>>> User information often isn't correct. If we can't reproduce what
>>>>> they say I think it's better to write steps for what we can
>>>>> reproduce, then refer to the user's discrepant account in the
>>>>> description.
>>>>>
>>>>>
>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>> you.
>>>>>
>>>>> That isn't very efficient, and it is something that can be delegated
>>>>> to everyone with Bugzilla access.
>>>>>
>>>>> I'm a "volunteer" not an employee.
>>>>>
>>>>>
>>>>> However a bug report with no steps to reproduce and a partial
>>>>> description might be no better than one with wrong information,
>>>>> as we saw today. If the person reading it has not seen the user
>>>>> report that generated it, or comes to it a long time after the
>>>>> report, lack of steps can be a serious drawback.
>>>>>
>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>
>>>>> You have said many times that bugs cannot be closed until the full
>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>
>>>>>
>>>>> So I would say go ahead and log please, but not until you are
>>>>> able to add steps.
>>>>>
>>>>> We may not immediately have time to fully analyse the problem and work
>>>>> out steps to fully characterise the problem, and that delay before
>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>> all,  but I accept that it's your decision.
>>>>>
>>>>> Steve
>>>>>
>>>>> The only exception might be a P2/P1 that
>>>>> was found close to release. In that case the RM needs to
>>>>> know ASAP and there should be no shortage of willing hands
>>>>> to fill in the blanks.
>>>>>
>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>> tracker when you have completed testing.
>>>>>
>>>>>
>>>>> Thanks
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> See, it's even caught you out now. :=)
>>>>>
>>>>>
>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>> The issue was not described there either. The email is saying that VI
>>>>> users
>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>> can.
>>>>>
>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>> different cause.  One possible fix is to make the number of digits in
>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>> unintuitive for VI users?
>>>>>
>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>> 120 000 Hz to 180 000 Hz?
>>>>>
>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>> behave as Selection Toolbar does when the format can't show a
>>>>> unique value for the position. That would be consistent.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> --James.
>>>>>
>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>
>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>
>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>
>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>
>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>> I don't see that I could resolve the bug just with that.
>>>>>
>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>
>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>> format,
>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>> values.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>
>>>>> Steve wrote in:
>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>
>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>> an exceptional case for audio)".
>>>>>
>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>> there is no way for VI users to create spectral selections above
>>>>> 100 000 Hz.
>>>>>
>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>> Selection Toolbar to create selections or move the cursor because
>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>> format because the leading values are truncated, which I agree is
>>>>> reasonable.
>>>>>
>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>> (still only P4) unless there is a technical reason why not.
>>>>>
>>>>>
>>>>> Gale
>>>>>
>>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Stevethefiddle
On 17 April 2017 at 20:00, Gale Andrews <[hidden email]> wrote:
> I believe you are misleading this list, Steve. I replied promptly and
> asked for more details because I was not able to reproduce the
> issue (because I was testing fitting into tight spaces, where I was
> often using CTRL).

I am not misleading, I am asking a question for the purpose of
clarifying how we log and track bugs.

>
> The user came back 10 hours ago with a video, then further after
> that, you said you could reproduce the issue on Linux. So the
> timescales are not as you describe.
>
> I can (about half the time) reproduce the issue now, but for me it
> is definitely moonphase. There are good workarounds.

For the purpose of "software quality", workarounds are irrelevant. We
need to log and track bugs so that they can be fixed.

>
> I store bugs that I can't add reasonably promptly to Bugzilla
> (for whatever reason) on my local file system. So they don't get
> lost, but that does not even apply in this case.

Thank you for the answer.
Personally I think that it would be far more helpful if bugs are
logged from the start on a tracker to which we all have access rather
than on your local file system.

Steve

>
> Anything I do or don't do in Bugzilla is subject to health. If I can
> barely stand or keep my eyes open, as was the case for a week
> or so at the end of March, then local storage may be all that
> happens.
>
>
>
> Gale
>
>
> On 17 April 2017 at 16:51, Steve the Fiddle <[hidden email]> wrote:
>> A user "kensmbour" posted a bug report to feedback@ three days ago in
>> a post titled "small noticeable occurence" (sic)
>> Have you logged that somewhere Gale? If you have, where? If not, how
>> do we prevent it from getting lost?
>>
>> Steve
>>
>> On 17 April 2017 at 16:31, Gale Andrews <[hidden email]> wrote:
>>> I am not proposing to duplicate my previous reply, beyond this.
>>>
>>> At a minimum, post at least one set of reproducible steps that
>>> a tester or developer could follow, and set the platform to
>>> whatever platform you tested on.
>>>
>>> You can include another platform that a user reported the issue
>>> on if you can partly reproduce what the user said, but mention
>>> the part-reproducibility in the description.
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>> On 17 April 2017 at 13:31, Steve the Fiddle <[hidden email]> wrote:
>>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>>> which may include:
>>>> * Which platforms are effected?
>>>> * Is it repeatable on other hardware?
>>>> * Is it a regression?
>>>> * Is it part of a broader problem?
>>>> * Does the symptom characterise the cause?
>>>> * Which of the steps that originally produced the problem are required
>>>> to reproduce the problem?
>>>> * Is it dependent on locale?
>>>> * ...
>>>>
>>>> Yes it is good to know the answers to all of these questions when
>>>> tackling a fix, but determining the answers is part of the process of
>>>> fixing the problem.
>>>>
>>>> At what point do we want to log and begin tracking the issue?
>>>>
>>>> Steve
>>>>
>>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>>> visibly see a bug progressing towards closure.
>>>>>>
>>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>
>>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>>> the bug.
>>>>>>
>>>>>> My second commit fixes that residual issue too:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>>
>>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>>> wrong too.
>>>>>>
>>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>>
>>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>>
>>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>>
>>>>>>
>>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>>> important as it was originally, and indeed the original bug may have been
>>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>>> bug fixer.
>>>>>>
>>>>>> Again this is not so much about practicalities as about how it feels to
>>>>>> fix the bugs.
>>>>>
>>>>>
>>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>>
>>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>>> passes those - Gale will
>>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>>> close the bug, and that
>>>>> can take a lot of time.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --James.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>>
>>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>
>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>> helping out by writing a bug report when they see a user report or
>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>
>>>>>> When I logged the bug, I had no more information than you.
>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>
>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>> they say I think it's better to write steps for what we can
>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>> description.
>>>>>>
>>>>>>
>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>> you.
>>>>>>
>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>> to everyone with Bugzilla access.
>>>>>>
>>>>>> I'm a "volunteer" not an employee.
>>>>>>
>>>>>>
>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>> description might be no better than one with wrong information,
>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>> report that generated it, or comes to it a long time after the
>>>>>> report, lack of steps can be a serious drawback.
>>>>>>
>>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>>
>>>>>> You have said many times that bugs cannot be closed until the full
>>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>>
>>>>>>
>>>>>> So I would say go ahead and log please, but not until you are
>>>>>> able to add steps.
>>>>>>
>>>>>> We may not immediately have time to fully analyse the problem and work
>>>>>> out steps to fully characterise the problem, and that delay before
>>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>>> all,  but I accept that it's your decision.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> The only exception might be a P2/P1 that
>>>>>> was found close to release. In that case the RM needs to
>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>> to fill in the blanks.
>>>>>>
>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>> tracker when you have completed testing.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> See, it's even caught you out now. :=)
>>>>>>
>>>>>>
>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>> The issue was not described there either. The email is saying that VI
>>>>>> users
>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>>> can.
>>>>>>
>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>> unintuitive for VI users?
>>>>>>
>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>
>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>> unique value for the position. That would be consistent.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> --James.
>>>>>>
>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>
>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>
>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>
>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>
>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>>> format,
>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>> values.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>
>>>>>> Steve wrote in:
>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>
>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>> an exceptional case for audio)".
>>>>>>
>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>> there is no way for VI users to create spectral selections above
>>>>>> 100 000 Hz.
>>>>>>
>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>> format because the leading values are truncated, which I agree is
>>>>>> reasonable.
>>>>>>
>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Gale
Administrator
In reply to this post by James Crook
On 17 April 2017 at 17:14, James Crook <[hidden email]> wrote:

> On 4/17/2017 4:22 PM, Gale Andrews wrote:
>> Do you agree then James that 1633 was posted too early for you
>> to make progress on it? Let's assume I had not e-mailed about
>> the separate issue Steve raised in the description, and all you
>> had to go on was the description.
>
> The description had just enough in it for me to DEVEL-FIX the bug.
>
> So in that sense it was ready to work on..
>
> However, correctly, my 'fix' did not close the bug, because there was a
> bug still.  That made me feel I hadn't made progress.
>
> So in that sense the bug was not 'ready to be worked on'.
>
>
> This bug is not really bugging me.  It's only 6 items in the comment
> trail so far.  The bugs that frustrate me have constantly mutating steps
> to reproduce.  I hadn't seen before that that is the key thing that
> makes them frustrating.  If we accept that we often re-use an original
> bug for 'residuals', possibly updating the steps to reproduce and the
> title when we do, then we need to do something more.

There is a good side to reusing a bug report for what you call residuals,
in that the history and comment trail is in one place, and we don't add
to the bug count.

I don't tend to regard a fix that breaks something else as a residual. I
call it the wrong fix and expect that the original bug would reopen.
Perhaps it lays too much "blame" to do that, but even if we open a
new bug for what got broken, we MUST still reopen the original bug
because I assume it would have to be retested.


> I propose that when a developer marks a bug as DEVEL-FIXED they should
> post steps to reproduce if there were none such already.  By saying
> DEVEL-FIXED the developer is claiming, as a minimum, that the steps to
> reproduce no longer reproduce the issue.  If they are wrong, a straight
> REOPEN is fine.  If they are right, but updated steps show there is
> still a bug, then ***Steps-Updated*** in the log would make a huge
> difference.  When reading the comment trail I only HAVE to read down to
> the first ***Steps Updated***.  Testers know there is a reason why their
> 'tested' flags are being cancelled, developer knows why there
> DEVEL-FIXED isn't closing it, and so on. ***Steps Updated*** becomes a
> clear mark of progress.  [Not needed when going from empty steps to some
> steps, of course].

I think it already usually happens, in that I add to my comment that
the Steps have been updated. There is no consistent text used for
that though, and the text may not be at the top of the comment.

I'm fine with your suggestion. You prefer that to a keyword?


> IF we do that, then this bug was ready to work on when Steve posted the
> description.

Yes. There is a risk of residual steps being added post-fix if the
developer does not find all of them when he posts DEVEL-FIXED.
I think it more gold standard where possible for the steps to be
given earlier by the person(s) who created and tested the symptoms.

If the bug comes from a report on a list, we can also refer to the URL
in case something is unclear.

In the case of 1633, the report was on feedback@, so private. But it
might have helped a developer who reads feedback@ for us to
say where the report came from. It does not post anything personally
identifiable to do that.


Gale


>> On 17 April 2017 at 13:36, James Crook <[hidden email]> wrote:
>>>> At what point do we want to log and begin tracking the issue?
>>> For me, it is when there is enough information that a developer can make
>>> progress on it and feel that they are doing so.  That's pretty early on.
>>>
>>> --James.
>>>
>>>
>>>
>>> On 4/17/2017 1:31 PM, Steve the Fiddle wrote:
>>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>>> which may include:
>>>> * Which platforms are effected?
>>>> * Is it repeatable on other hardware?
>>>> * Is it a regression?
>>>> * Is it part of a broader problem?
>>>> * Does the symptom characterise the cause?
>>>> * Which of the steps that originally produced the problem are required
>>>> to reproduce the problem?
>>>> * Is it dependent on locale?
>>>> * ...
>>>>
>>>> Yes it is good to know the answers to all of these questions when
>>>> tackling a fix, but determining the answers is part of the process of
>>>> fixing the problem.
>>>>
>>>> At what point do we want to log and begin tracking the issue?
>>>>
>>>> Steve
>>>>
>>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>>> visibly see a bug progressing towards closure.
>>>>>>
>>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>
>>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>>> the bug.
>>>>>>
>>>>>> My second commit fixes that residual issue too:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>>
>>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>>> wrong too.
>>>>>>
>>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>>
>>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>>
>>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>>
>>>>>>
>>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>>> important as it was originally, and indeed the original bug may have been
>>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>>> bug fixer.
>>>>>>
>>>>>> Again this is not so much about practicalities as about how it feels to
>>>>>> fix the bugs.
>>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>>
>>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>>> passes those - Gale will
>>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>>> close the bug, and that
>>>>> can take a lot of time.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> --James.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>>
>>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>
>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>> helping out by writing a bug report when they see a user report or
>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>
>>>>>> When I logged the bug, I had no more information than you.
>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>
>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>> they say I think it's better to write steps for what we can
>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>> description.
>>>>>>
>>>>>>
>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>> you.
>>>>>>
>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>> to everyone with Bugzilla access.
>>>>>>
>>>>>> I'm a "volunteer" not an employee.
>>>>>>
>>>>>>
>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>> description might be no better than one with wrong information,
>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>> report that generated it, or comes to it a long time after the
>>>>>> report, lack of steps can be a serious drawback.
>>>>>>
>>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>>
>>>>>> You have said many times that bugs cannot be closed until the full
>>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>>
>>>>>>
>>>>>> So I would say go ahead and log please, but not until you are
>>>>>> able to add steps.
>>>>>>
>>>>>> We may not immediately have time to fully analyse the problem and work
>>>>>> out steps to fully characterise the problem, and that delay before
>>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>>> all,  but I accept that it's your decision.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> The only exception might be a P2/P1 that
>>>>>> was found close to release. In that case the RM needs to
>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>> to fill in the blanks.
>>>>>>
>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>> tracker when you have completed testing.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> See, it's even caught you out now. :=)
>>>>>>
>>>>>>
>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>> The issue was not described there either. The email is saying that VI
>>>>>> users
>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>>> can.
>>>>>>
>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>> unintuitive for VI users?
>>>>>>
>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>
>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>> unique value for the position. That would be consistent.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> --James.
>>>>>>
>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>
>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>
>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>
>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>
>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>>> format,
>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>> values.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>
>>>>>> Steve wrote in:
>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>
>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>> an exceptional case for audio)".
>>>>>>
>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>> there is no way for VI users to create spectral selections above
>>>>>> 100 000 Hz.
>>>>>>
>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>> format because the leading values are truncated, which I agree is
>>>>>> reasonable.
>>>>>>
>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

James Crook
(Re '*** STEPS UPDATED ***')
Gale wrote:

> I'm fine with your suggestion. You prefer that to a keyword?
Yes.  Actually in the comments shows when it happened, and unlike a keyword also allows for steps to be updated more than once.


Gale wrote:
> I don't tend to regard a fix that breaks something else as a residual.
A really bad fix where the break is as bad or worse than the original symptom should just be reverted.  But I would say if the fix has made progress, then it is time to update steps (or start a new bug).



On 4/17/2017 8:35 PM, Gale Andrews wrote:

> On 17 April 2017 at 17:14, James Crook <[hidden email]> wrote:
>> On 4/17/2017 4:22 PM, Gale Andrews wrote:
>>> Do you agree then James that 1633 was posted too early for you
>>> to make progress on it? Let's assume I had not e-mailed about
>>> the separate issue Steve raised in the description, and all you
>>> had to go on was the description.
>> The description had just enough in it for me to DEVEL-FIX the bug.
>>
>> So in that sense it was ready to work on..
>>
>> However, correctly, my 'fix' did not close the bug, because there was a
>> bug still.  That made me feel I hadn't made progress.
>>
>> So in that sense the bug was not 'ready to be worked on'.
>>
>>
>> This bug is not really bugging me.  It's only 6 items in the comment
>> trail so far.  The bugs that frustrate me have constantly mutating steps
>> to reproduce.  I hadn't seen before that that is the key thing that
>> makes them frustrating.  If we accept that we often re-use an original
>> bug for 'residuals', possibly updating the steps to reproduce and the
>> title when we do, then we need to do something more.
> There is a good side to reusing a bug report for what you call residuals,
> in that the history and comment trail is in one place, and we don't add
> to the bug count.
>
> I don't tend to regard a fix that breaks something else as a residual. I
> call it the wrong fix and expect that the original bug would reopen.
> Perhaps it lays too much "blame" to do that, but even if we open a
> new bug for what got broken, we MUST still reopen the original bug
> because I assume it would have to be retested.
>
>
>> I propose that when a developer marks a bug as DEVEL-FIXED they should
>> post steps to reproduce if there were none such already.  By saying
>> DEVEL-FIXED the developer is claiming, as a minimum, that the steps to
>> reproduce no longer reproduce the issue.  If they are wrong, a straight
>> REOPEN is fine.  If they are right, but updated steps show there is
>> still a bug, then ***Steps-Updated*** in the log would make a huge
>> difference.  When reading the comment trail I only HAVE to read down to
>> the first ***Steps Updated***.  Testers know there is a reason why their
>> 'tested' flags are being cancelled, developer knows why there
>> DEVEL-FIXED isn't closing it, and so on. ***Steps Updated*** becomes a
>> clear mark of progress.  [Not needed when going from empty steps to some
>> steps, of course].
> I think it already usually happens, in that I add to my comment that
> the Steps have been updated. There is no consistent text used for
> that though, and the text may not be at the top of the comment.
>
> I'm fine with your suggestion. You prefer that to a keyword?
>
>
>> IF we do that, then this bug was ready to work on when Steve posted the
>> description.
> Yes. There is a risk of residual steps being added post-fix if the
> developer does not find all of them when he posts DEVEL-FIXED.
> I think it more gold standard where possible for the steps to be
> given earlier by the person(s) who created and tested the symptoms.
>
> If the bug comes from a report on a list, we can also refer to the URL
> in case something is unclear.
>
> In the case of 1633, the report was on feedback@, so private. But it
> might have helped a developer who reads feedback@ for us to
> say where the report came from. It does not post anything personally
> identifiable to do that.
>
>
> Gale
>
>
>>> On 17 April 2017 at 13:36, James Crook <[hidden email]> wrote:
>>>>> At what point do we want to log and begin tracking the issue?
>>>> For me, it is when there is enough information that a developer can make
>>>> progress on it and feel that they are doing so.  That's pretty early on.
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>> On 4/17/2017 1:31 PM, Steve the Fiddle wrote:
>>>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>>>> which may include:
>>>>> * Which platforms are effected?
>>>>> * Is it repeatable on other hardware?
>>>>> * Is it a regression?
>>>>> * Is it part of a broader problem?
>>>>> * Does the symptom characterise the cause?
>>>>> * Which of the steps that originally produced the problem are required
>>>>> to reproduce the problem?
>>>>> * Is it dependent on locale?
>>>>> * ...
>>>>>
>>>>> Yes it is good to know the answers to all of these questions when
>>>>> tackling a fix, but determining the answers is part of the process of
>>>>> fixing the problem.
>>>>>
>>>>> At what point do we want to log and begin tracking the issue?
>>>>>
>>>>> Steve
>>>>>
>>>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>>>> visibly see a bug progressing towards closure.
>>>>>>>
>>>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>
>>>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>>>> the bug.
>>>>>>>
>>>>>>> My second commit fixes that residual issue too:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>>>
>>>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>>>> wrong too.
>>>>>>>
>>>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>>>
>>>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>>>
>>>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>>>
>>>>>>>
>>>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>>>> important as it was originally, and indeed the original bug may have been
>>>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>>>> bug fixer.
>>>>>>>
>>>>>>> Again this is not so much about practicalities as about how it feels to
>>>>>>> fix the bugs.
>>>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>>>
>>>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>>>> passes those - Gale will
>>>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>>>> close the bug, and that
>>>>>> can take a lot of time.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>>>
>>>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>>
>>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>>> helping out by writing a bug report when they see a user report or
>>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>>
>>>>>>> When I logged the bug, I had no more information than you.
>>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>>
>>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>>> they say I think it's better to write steps for what we can
>>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>>> description.
>>>>>>>
>>>>>>>
>>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>>> you.
>>>>>>>
>>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>>> to everyone with Bugzilla access.
>>>>>>>
>>>>>>> I'm a "volunteer" not an employee.
>>>>>>>
>>>>>>>
>>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>>> description might be no better than one with wrong information,
>>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>>> report that generated it, or comes to it a long time after the
>>>>>>> report, lack of steps can be a serious drawback.
>>>>>>>
>>>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>>>
>>>>>>> You have said many times that bugs cannot be closed until the full
>>>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>>>
>>>>>>>
>>>>>>> So I would say go ahead and log please, but not until you are
>>>>>>> able to add steps.
>>>>>>>
>>>>>>> We may not immediately have time to fully analyse the problem and work
>>>>>>> out steps to fully characterise the problem, and that delay before
>>>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>>>> all,  but I accept that it's your decision.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> The only exception might be a P2/P1 that
>>>>>>> was found close to release. In that case the RM needs to
>>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>>> to fill in the blanks.
>>>>>>>
>>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>>> tracker when you have completed testing.
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> See, it's even caught you out now. :=)
>>>>>>>
>>>>>>>
>>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>>> The issue was not described there either. The email is saying that VI
>>>>>>> users
>>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>>>> can.
>>>>>>>
>>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>>> unintuitive for VI users?
>>>>>>>
>>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>>
>>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>>> unique value for the position. That would be consistent.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>
>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>
>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>
>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>>>> format,
>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>> values.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>
>>>>>>> Steve wrote in:
>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>
>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>> an exceptional case for audio)".
>>>>>>>
>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>> 100 000 Hz.
>>>>>>>
>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>> reasonable.
>>>>>>>
>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Vaughan Johnson-4
In reply to this post by Stevethefiddle
On Mon, Apr 17, 2017 at 5:31 AM, Steve the Fiddle
<[hidden email]> wrote:

> When a bug is first noticed, there are inevitably many 'unknowns',
> which may include:
> * Which platforms are effected?
> * Is it repeatable on other hardware?
> * Is it a regression?
> * Is it part of a broader problem?
> * Does the symptom characterise the cause?
> * Which of the steps that originally produced the problem are required
> to reproduce the problem?
> * Is it dependent on locale?
> * ...
>
> Yes it is good to know the answers to all of these questions when
> tackling a fix, but determining the answers is part of the process of
> fixing the problem.
>
> At what point do we want to log and begin tracking the issue?
>
> Steve
>
> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>
>>
>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>
>>> Where I am coming from on this is only indirectly about practicalities and
>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>> visibly see a bug progressing towards closure.

Amen.


>>>
>>> My first commit, I hoped, was enough to close the bug:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> However, I'd certainly agree the bug title is sufficiently general that it
>>> does cover more, and the bug, that I was not aware of, of max copying from
>>> min fits under that title too.  I think my real issue was that I didn't get
>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>> less important than the original (minor) issue arrived.  My peve about the
>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>> the bug.
>>>
>>> My second commit fixes that residual issue too:
>>>
>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>
>>> However, I am expecting not to get the satisfaction of seeing the bug
>>> close from that either.  I gave the reasons in a previous email.  There are
>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>> frequency display rather than showing '------' for invalid/out-of-range is
>>> wrong too.
>>>
>>> So basically the experience of working on bugs is unsatisfying.  I would
>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>
>>> I added a new bug about Spectral Selection Toolbar in German.
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>
>>> Maybe this new bug will be enough to allow us to close 1633.
>>>
>>>
>>> This isn't about practicalities.  It's about how it feels to fix bugs.

As someone who has fixed 100's of bugs in Audacity, I just want to put
in a big +1 to James's sentiment here!  Especially fixing bugs in
other peoples' code.




>>> Even though there appear to be two bugs in 1634, I think the experience of
>>> working on 1634 might be more satisfying than 1633, as there is a real
>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>> and define what the bug is, rather than the title doing so.  I think if the
>>> steps to reproduce are updated significantly to cover other similar issues,
>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>> Then someone reading the comment trail knows that essentially a new or
>>> residual issue is being worked on now, and earlier bug trail is not as
>>> important as it was originally, and indeed the original bug may have been
>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>> bug fixer.
>>>
>>> Again this is not so much about practicalities as about how it feels to
>>> fix the bugs.
>>
>>
>> It's also about how it feels to test fixed bugs and then not see them close.

No doubt.


>>
>> But as we know, even if there are clear Steps To Reproduce and testing
>> passes those - Gale will
>> usually insist on "testing around" and not just relying on steps-passing to
>> close the bug, and that
>> can take a lot of time.
>>
>> Peter
>>
>>
>>
>>>
>>>
>>>
>>> --James.
>>>
>>>
>>>
>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>
>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>
>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>
>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>
>>> Gale, that issue was not in the steps to reproduce
>>>
>>> Well, isn't that the very point I have been making? I appreciate others
>>> helping out by writing a bug report when they see a user report or
>>> when a bug is confirmed on a list, but *everyone* should write proper
>>> steps to reproduce (in the Steps to Reproduce) box.
>>>
>>> When I logged the bug, I had no more information than you.
>>> I didn't include all of the detail reported by the person that wrote
>>> in to feedback@ because it did not appear to be correct, and in my
>>> opinion, incorrect information is worse than incomplete information.
>>>
>>> User information often isn't correct. If we can't reproduce what
>>> they say I think it's better to write steps for what we can
>>> reproduce, then refer to the user's discrepant account in the
>>> description.
>>>
>>>
>>> If you prefer that I don't log bugs until I have time to work out the
>>> full scope of the issue, including detailed steps to reproduce, then
>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>> you.
>>>
>>> That isn't very efficient, and it is something that can be delegated
>>> to everyone with Bugzilla access.
>>>
>>> I'm a "volunteer" not an employee.

Right on. This seems to be about actual privileges, regardless of titles.


>>>
>>>
>>> However a bug report with no steps to reproduce and a partial
>>> description might be no better than one with wrong information,
>>> as we saw today. If the person reading it has not seen the user
>>> report that generated it, or comes to it a long time after the
>>> report, lack of steps can be a serious drawback.
>>>
>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>> That looks pretty clear to me that there's one or more problems in the
>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>
>>> You have said many times that bugs cannot be closed until the full
>>> scope of the bug has been investigated, in fact, that was a reason
>>> that you gave for not allowing Peter or myself to close bugs.
>>>
>>>
>>> So I would say go ahead and log please, but not until you are
>>> able to add steps.
>>>
>>> We may not immediately have time to fully analyse the problem and work
>>> out steps to fully characterise the problem, and that delay before
>>> logging the bug may increase the likelihood of it not being logged at
>>> all,  but I accept that it's your decision.
>>>
>>> Steve
>>>
>>> The only exception might be a P2/P1 that
>>> was found close to release. In that case the RM needs to
>>> know ASAP and there should be no shortage of willing hands
>>> to fill in the blanks.
>>>
>>> For bugs that are not time sensitive, perhaps you could say to
>>> feedback@ as I sometimes do, that you will add it to the bug
>>> tracker when you have completed testing.
>>>
>>>
>>> Thanks
>>>
>>>
>>> Gale
>>>
>>>
>>> See, it's even caught you out now. :=)
>>>
>>>
>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>> The issue was not described there either. The email is saying that VI
>>> users
>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>> can.
>>>
>>> I only tested with KHz (and MHz).  The bug you report here has a
>>> different cause.  One possible fix is to make the number of digits in
>>> the Hz display variable, rather than truncate, but that might prove
>>> unintuitive for VI users?
>>>
>>> Can you say then how we would display in Hz, a spectral selection of
>>> 120 000 Hz to 180 000 Hz?
>>>
>>> I can't discuss what technically could be done, but I think it "should"
>>> behave as Selection Toolbar does when the format can't show a
>>> unique value for the position. That would be consistent.
>>>
>>>
>>> Gale
>>>
>>>
>>> --James.
>>>
>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>
>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>
>>> So that our VI users who work with bat and/or porpoise sounds are not
>>> inconvenienced, I have addressed this issue with following commit:
>>>
>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>
>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>> I don't see that I could resolve the bug just with that.
>>>
>>> In Hz format, the display of High Frequency remains incorrect above
>>> 100 000 Hz. It's the same as Low Frequency.
>>>
>>> Surely it should show the correct High and Low frequencies with leading
>>> truncation, just as when you select in a 38 hour track using samples
>>> format,
>>> Selection Start and End in Selection Toolbar show different but truncated
>>> values.
>>>
>>>
>>> Gale
>>>
>>>
>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>
>>> Steve wrote in:
>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>
>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>> an exceptional case for audio)".
>>>
>>> For display I might agree, but this does mean that Spectral Selection
>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>> there is no way for VI users to create spectral selections above
>>> 100 000 Hz.
>>>
>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>> we compare the case of long audio (say 48 hours) VI users can use
>>> Selection Toolbar to create selections or move the cursor because
>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>> format because the leading values are truncated, which I agree is
>>> reasonable.
>>>
>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>> (still only P4) unless there is a technical reason why not.
>>>
>>>
>>> Gale
>>>
>>>
>

Thanks for discussing policies. I hope it will streamline process.

- Vaughan

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Vaughan Johnson-4
In reply to this post by James Crook
On Mon, Apr 17, 2017 at 5:36 AM, James Crook <[hidden email]> wrote:
>
>> At what point do we want to log and begin tracking the issue?
> For me, it is when there is enough information that a developer can make
> progress on it and feel that they are doing so.  That's pretty early on.
>
> --James.

Yes.  Understanding a bug and its ramifications takes time. Get it
started early. But also resolve it when resolved.

If it later turns out to not actually be resolved, we have mechanism
for reviving it or splitting it to a new (probably lower priority)
bug.

I think the main point is to try to make bug reporting, fixing, and
closing all more rewarding than seem to be now.

Thanks for discussing policies. I hope it will streamline process.

- Vaughan


>
>
>
> On 4/17/2017 1:31 PM, Steve the Fiddle wrote:
>> When a bug is first noticed, there are inevitably many 'unknowns',
>> which may include:
>> * Which platforms are effected?
>> * Is it repeatable on other hardware?
>> * Is it a regression?
>> * Is it part of a broader problem?
>> * Does the symptom characterise the cause?
>> * Which of the steps that originally produced the problem are required
>> to reproduce the problem?
>> * Is it dependent on locale?
>> * ...
>>
>> Yes it is good to know the answers to all of these questions when
>> tackling a fix, but determining the answers is part of the process of
>> fixing the problem.
>>
>> At what point do we want to log and begin tracking the issue?
>>
>> Steve
>>
>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>
>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>> Where I am coming from on this is only indirectly about practicalities and
>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>> visibly see a bug progressing towards closure.
>>>>
>>>> My first commit, I hoped, was enough to close the bug:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>> less important than the original (minor) issue arrived.  My peve about the
>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>> the bug.
>>>>
>>>> My second commit fixes that residual issue too:
>>>>
>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>
>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>> wrong too.
>>>>
>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>
>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>
>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>
>>>>
>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>> Then someone reading the comment trail knows that essentially a new or
>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>> important as it was originally, and indeed the original bug may have been
>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>> bug fixer.
>>>>
>>>> Again this is not so much about practicalities as about how it feels to
>>>> fix the bugs.
>>>
>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>
>>> But as we know, even if there are clear Steps To Reproduce and testing
>>> passes those - Gale will
>>> usually insist on "testing around" and not just relying on steps-passing to
>>> close the bug, and that
>>> can take a lot of time.
>>>
>>> Peter
>>>
>>>
>>>
>>>>
>>>>
>>>> --James.
>>>>
>>>>
>>>>
>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>
>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>> wrote:
>>>>
>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>
>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>
>>>> Gale, that issue was not in the steps to reproduce
>>>>
>>>> Well, isn't that the very point I have been making? I appreciate others
>>>> helping out by writing a bug report when they see a user report or
>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>
>>>> When I logged the bug, I had no more information than you.
>>>> I didn't include all of the detail reported by the person that wrote
>>>> in to feedback@ because it did not appear to be correct, and in my
>>>> opinion, incorrect information is worse than incomplete information.
>>>>
>>>> User information often isn't correct. If we can't reproduce what
>>>> they say I think it's better to write steps for what we can
>>>> reproduce, then refer to the user's discrepant account in the
>>>> description.
>>>>
>>>>
>>>> If you prefer that I don't log bugs until I have time to work out the
>>>> full scope of the issue, including detailed steps to reproduce, then
>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>> you.
>>>>
>>>> That isn't very efficient, and it is something that can be delegated
>>>> to everyone with Bugzilla access.
>>>>
>>>> I'm a "volunteer" not an employee.
>>>>
>>>>
>>>> However a bug report with no steps to reproduce and a partial
>>>> description might be no better than one with wrong information,
>>>> as we saw today. If the person reading it has not seen the user
>>>> report that generated it, or comes to it a long time after the
>>>> report, lack of steps can be a serious drawback.
>>>>
>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>> That looks pretty clear to me that there's one or more problems in the
>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>
>>>> You have said many times that bugs cannot be closed until the full
>>>> scope of the bug has been investigated, in fact, that was a reason
>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>
>>>>
>>>> So I would say go ahead and log please, but not until you are
>>>> able to add steps.
>>>>
>>>> We may not immediately have time to fully analyse the problem and work
>>>> out steps to fully characterise the problem, and that delay before
>>>> logging the bug may increase the likelihood of it not being logged at
>>>> all,  but I accept that it's your decision.
>>>>
>>>> Steve
>>>>
>>>> The only exception might be a P2/P1 that
>>>> was found close to release. In that case the RM needs to
>>>> know ASAP and there should be no shortage of willing hands
>>>> to fill in the blanks.
>>>>
>>>> For bugs that are not time sensitive, perhaps you could say to
>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>> tracker when you have completed testing.
>>>>
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> See, it's even caught you out now. :=)
>>>>
>>>>
>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>> The issue was not described there either. The email is saying that VI
>>>> users
>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>> can.
>>>>
>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>> different cause.  One possible fix is to make the number of digits in
>>>> the Hz display variable, rather than truncate, but that might prove
>>>> unintuitive for VI users?
>>>>
>>>> Can you say then how we would display in Hz, a spectral selection of
>>>> 120 000 Hz to 180 000 Hz?
>>>>
>>>> I can't discuss what technically could be done, but I think it "should"
>>>> behave as Selection Toolbar does when the format can't show a
>>>> unique value for the position. That would be consistent.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> --James.
>>>>
>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>
>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>
>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>> inconvenienced, I have addressed this issue with following commit:
>>>>
>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>
>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>> I don't see that I could resolve the bug just with that.
>>>>
>>>> In Hz format, the display of High Frequency remains incorrect above
>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>
>>>> Surely it should show the correct High and Low frequencies with leading
>>>> truncation, just as when you select in a 38 hour track using samples
>>>> format,
>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>> values.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>
>>>> Steve wrote in:
>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>
>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>> an exceptional case for audio)".
>>>>
>>>> For display I might agree, but this does mean that Spectral Selection
>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>> there is no way for VI users to create spectral selections above
>>>> 100 000 Hz.
>>>>
>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>> Selection Toolbar to create selections or move the cursor because
>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>> format because the leading values are truncated, which I agree is
>>>> reasonable.
>>>>
>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>> (still only P4) unless there is a technical reason why not.
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Vaughan Johnson-4
In reply to this post by Gale
On Mon, Apr 17, 2017 at 12:00 PM, Gale Andrews <[hidden email]> wrote:

> I believe you are misleading this list, Steve. I replied promptly and
> asked for more details because I was not able to reproduce the
> issue (because I was testing fitting into tight spaces, where I was
> often using CTRL).
>
> The user came back 10 hours ago with a video, then further after
> that, you said you could reproduce the issue on Linux. So the
> timescales are not as you describe.
>
> I can (about half the time) reproduce the issue now, but for me it
> is definitely moonphase. There are good workarounds.
>
> I store bugs that I can't add reasonably promptly to Bugzilla
> (for whatever reason) on my local file system. So they don't get
> lost, but that does not even apply in this case.
>
> Anything I do or don't do in Bugzilla is subject to health. If I can
> barely stand or keep my eyes open, as was the case for a week
> or so at the end of March, then local storage may be all that
> happens.

Gale, I'm very sorry to hear your health is so bad -- I knew only that
it was not good, no specifics.

Steve and Peter on QA and James-with-bug-fixer-hat-on are trying to
help the process, afaict, not attack your powers. I hope we can all
see this as, and make it, more amicable and feasible given our
resources.

- Vaughan


>
>
>
> Gale
>
>
> On 17 April 2017 at 16:51, Steve the Fiddle <[hidden email]> wrote:
>> A user "kensmbour" posted a bug report to feedback@ three days ago in
>> a post titled "small noticeable occurence" (sic)
>> Have you logged that somewhere Gale? If you have, where? If not, how
>> do we prevent it from getting lost?
>>
>> Steve
>>
>> On 17 April 2017 at 16:31, Gale Andrews <[hidden email]> wrote:
>>> I am not proposing to duplicate my previous reply, beyond this.
>>>
>>> At a minimum, post at least one set of reproducible steps that
>>> a tester or developer could follow, and set the platform to
>>> whatever platform you tested on.
>>>
>>> You can include another platform that a user reported the issue
>>> on if you can partly reproduce what the user said, but mention
>>> the part-reproducibility in the description.
>>>
>>>
>>>
>>> Gale
>>>
>>>
>>> On 17 April 2017 at 13:31, Steve the Fiddle <[hidden email]> wrote:
>>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>>> which may include:
>>>> * Which platforms are effected?
>>>> * Is it repeatable on other hardware?
>>>> * Is it a regression?
>>>> * Is it part of a broader problem?
>>>> * Does the symptom characterise the cause?
>>>> * Which of the steps that originally produced the problem are required
>>>> to reproduce the problem?
>>>> * Is it dependent on locale?
>>>> * ...
>>>>
>>>> Yes it is good to know the answers to all of these questions when
>>>> tackling a fix, but determining the answers is part of the process of
>>>> fixing the problem.
>>>>
>>>> At what point do we want to log and begin tracking the issue?
>>>>
>>>> Steve
>>>>
>>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>>
>>>>>
>>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>>> visibly see a bug progressing towards closure.
>>>>>>
>>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>
>>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>>> the bug.
>>>>>>
>>>>>> My second commit fixes that residual issue too:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>>
>>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>>> wrong too.
>>>>>>
>>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>>
>>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>>
>>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>>
>>>>>>
>>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>>> important as it was originally, and indeed the original bug may have been
>>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>>> bug fixer.
>>>>>>
>>>>>> Again this is not so much about practicalities as about how it feels to
>>>>>> fix the bugs.
>>>>>
>>>>>
>>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>>
>>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>>> passes those - Gale will
>>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>>> close the bug, and that
>>>>> can take a lot of time.
>>>>>
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --James.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>>
>>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>
>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>
>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>> helping out by writing a bug report when they see a user report or
>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>
>>>>>> When I logged the bug, I had no more information than you.
>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>
>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>> they say I think it's better to write steps for what we can
>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>> description.
>>>>>>
>>>>>>
>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>> you.
>>>>>>
>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>> to everyone with Bugzilla access.
>>>>>>
>>>>>> I'm a "volunteer" not an employee.
>>>>>>
>>>>>>
>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>> description might be no better than one with wrong information,
>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>> report that generated it, or comes to it a long time after the
>>>>>> report, lack of steps can be a serious drawback.
>>>>>>
>>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>>
>>>>>> You have said many times that bugs cannot be closed until the full
>>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>>
>>>>>>
>>>>>> So I would say go ahead and log please, but not until you are
>>>>>> able to add steps.
>>>>>>
>>>>>> We may not immediately have time to fully analyse the problem and work
>>>>>> out steps to fully characterise the problem, and that delay before
>>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>>> all,  but I accept that it's your decision.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> The only exception might be a P2/P1 that
>>>>>> was found close to release. In that case the RM needs to
>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>> to fill in the blanks.
>>>>>>
>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>> tracker when you have completed testing.
>>>>>>
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> See, it's even caught you out now. :=)
>>>>>>
>>>>>>
>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>> The issue was not described there either. The email is saying that VI
>>>>>> users
>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>>> can.
>>>>>>
>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>> unintuitive for VI users?
>>>>>>
>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>
>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>> unique value for the position. That would be consistent.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> --James.
>>>>>>
>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>
>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>
>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>
>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>
>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>
>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>
>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>>> format,
>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>> values.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>
>>>>>> Steve wrote in:
>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>
>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>> an exceptional case for audio)".
>>>>>>
>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>> there is no way for VI users to create spectral selections above
>>>>>> 100 000 Hz.
>>>>>>
>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>> format because the leading values are truncated, which I agree is
>>>>>> reasonable.
>>>>>>
>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>
>>>>>>
>>>>>> Gale
>>>>>>
>>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Gale
Administrator
In reply to this post by Stevethefiddle
On 17 April 2017 at 20:15, Steve the Fiddle <[hidden email]> wrote:

> On 17 April 2017 at 20:00, Gale Andrews <[hidden email]> wrote:
>> I believe you are misleading this list, Steve. I replied promptly and
>> asked for more details because I was not able to reproduce the
>> issue (because I was testing fitting into tight spaces, where I was
>> often using CTRL).
>
> I am not misleading, I am asking a question for the purpose of
> clarifying how we log and track bugs.
>
>>
>> The user came back 10 hours ago with a video, then further after
>> that, you said you could reproduce the issue on Linux. So the
>> timescales are not as you describe.
>>
>> I can (about half the time) reproduce the issue now, but for me it
>> is definitely moonphase. There are good workarounds.
>
> For the purpose of "software quality", workarounds are irrelevant. We
> need to log and track bugs so that they can be fixed.

How many years hence, for P3 and below?

Until someone advises some level of reproducibility for the Time
Shift Problem, and how to do so (you did not advise reproducibility
on Linux until two days after the user posted) no, they should not
go on Bugzilla. This is OK as long as someone is actively working
with the user, which was happening. .

I would think this bug is P3, though not fully reproducible for me, not
least to tell users in a release note that dragging in the upper half of
a stereo track may not be reliable. Workarounds are often given as
part of release notes, so they are not irrelevant.


>> I store bugs that I can't add reasonably promptly to Bugzilla
>> (for whatever reason) on my local file system. So they don't get
>> lost, but that does not even apply in this case.
>
> Thank you for the answer.
> Personally I think that it would be far more helpful if bugs are
> logged from the start on a tracker to which we all have access rather
> than on your local file system.

That only applies to bugs that stay on the local file system, and
those that do are mostly not ready to be posted, IMO. And most
of them would only rate P4 or P5.

All the other bugs are those that you can see for yourself on feedback,
mailing lists and Forum. By definition no-one else has tracked these
bugs, for some reason. Tracking them locally (which is as immediate
as I can make it, and is fast) is better than not tracking them at all.

An alternative (which I will do anyway when I quit bugs work) is to
post the material on Wiki for triage. Some of it might only make
sense to me, until edited.


Gale


>>
>> Anything I do or don't do in Bugzilla is subject to health. If I can
>> barely stand or keep my eyes open, as was the case for a week
>> or so at the end of March, then local storage may be all that
>> happens.
>>
>>
>>
>> Gale
>>
>>
>> On 17 April 2017 at 16:51, Steve the Fiddle <[hidden email]> wrote:
>>> A user "kensmbour" posted a bug report to feedback@ three days ago in
>>> a post titled "small noticeable occurence" (sic)
>>> Have you logged that somewhere Gale? If you have, where? If not, how
>>> do we prevent it from getting lost?
>>>
>>> Steve
>>>
>>> On 17 April 2017 at 16:31, Gale Andrews <[hidden email]> wrote:
>>>> I am not proposing to duplicate my previous reply, beyond this.
>>>>
>>>> At a minimum, post at least one set of reproducible steps that
>>>> a tester or developer could follow, and set the platform to
>>>> whatever platform you tested on.
>>>>
>>>> You can include another platform that a user reported the issue
>>>> on if you can partly reproduce what the user said, but mention
>>>> the part-reproducibility in the description.
>>>>
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 17 April 2017 at 13:31, Steve the Fiddle <[hidden email]> wrote:
>>>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>>>> which may include:
>>>>> * Which platforms are effected?
>>>>> * Is it repeatable on other hardware?
>>>>> * Is it a regression?
>>>>> * Is it part of a broader problem?
>>>>> * Does the symptom characterise the cause?
>>>>> * Which of the steps that originally produced the problem are required
>>>>> to reproduce the problem?
>>>>> * Is it dependent on locale?
>>>>> * ...
>>>>>
>>>>> Yes it is good to know the answers to all of these questions when
>>>>> tackling a fix, but determining the answers is part of the process of
>>>>> fixing the problem.
>>>>>
>>>>> At what point do we want to log and begin tracking the issue?
>>>>>
>>>>> Steve
>>>>>
>>>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>>>> visibly see a bug progressing towards closure.
>>>>>>>
>>>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>
>>>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>>>> the bug.
>>>>>>>
>>>>>>> My second commit fixes that residual issue too:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>>>
>>>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>>>> wrong too.
>>>>>>>
>>>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>>>
>>>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>>>
>>>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>>>
>>>>>>>
>>>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>>>> important as it was originally, and indeed the original bug may have been
>>>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>>>> bug fixer.
>>>>>>>
>>>>>>> Again this is not so much about practicalities as about how it feels to
>>>>>>> fix the bugs.
>>>>>>
>>>>>>
>>>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>>>
>>>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>>>> passes those - Gale will
>>>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>>>> close the bug, and that
>>>>>> can take a lot of time.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>>>
>>>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>>
>>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>>> helping out by writing a bug report when they see a user report or
>>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>>
>>>>>>> When I logged the bug, I had no more information than you.
>>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>>
>>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>>> they say I think it's better to write steps for what we can
>>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>>> description.
>>>>>>>
>>>>>>>
>>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>>> you.
>>>>>>>
>>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>>> to everyone with Bugzilla access.
>>>>>>>
>>>>>>> I'm a "volunteer" not an employee.
>>>>>>>
>>>>>>>
>>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>>> description might be no better than one with wrong information,
>>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>>> report that generated it, or comes to it a long time after the
>>>>>>> report, lack of steps can be a serious drawback.
>>>>>>>
>>>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>>>
>>>>>>> You have said many times that bugs cannot be closed until the full
>>>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>>>
>>>>>>>
>>>>>>> So I would say go ahead and log please, but not until you are
>>>>>>> able to add steps.
>>>>>>>
>>>>>>> We may not immediately have time to fully analyse the problem and work
>>>>>>> out steps to fully characterise the problem, and that delay before
>>>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>>>> all,  but I accept that it's your decision.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> The only exception might be a P2/P1 that
>>>>>>> was found close to release. In that case the RM needs to
>>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>>> to fill in the blanks.
>>>>>>>
>>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>>> tracker when you have completed testing.
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> See, it's even caught you out now. :=)
>>>>>>>
>>>>>>>
>>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>>> The issue was not described there either. The email is saying that VI
>>>>>>> users
>>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>>>> can.
>>>>>>>
>>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>>> unintuitive for VI users?
>>>>>>>
>>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>>
>>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>>> unique value for the position. That would be consistent.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>
>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>
>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>
>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>>>> format,
>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>> values.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>
>>>>>>> Steve wrote in:
>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>
>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>> an exceptional case for audio)".
>>>>>>>
>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>> 100 000 Hz.
>>>>>>>
>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>> reasonable.
>>>>>>>
>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Gale
Administrator
In reply to this post by James Crook
If most of us really WANT a residual observed in testing to be a new bug,
even if it matches the original bug title, I don't object. There are pros
and cons to each method, but I don't see that either way affects the
quality of the result.

New topic if we want to discuss it.



Gale


On 17 April 2017 at 21:27, James Crook <[hidden email]> wrote:

> (Re '*** STEPS UPDATED ***')
> Gale wrote:
>
>> I'm fine with your suggestion. You prefer that to a keyword?
> Yes.  Actually in the comments shows when it happened, and unlike a keyword also allows for steps to be updated more than once.
>
>
> Gale wrote:
>> I don't tend to regard a fix that breaks something else as a residual.
> A really bad fix where the break is as bad or worse than the original symptom should just be reverted.  But I would say if the fix has made progress, then it is time to update steps (or start a new bug).
>
>
>
> On 4/17/2017 8:35 PM, Gale Andrews wrote:
>> On 17 April 2017 at 17:14, James Crook <[hidden email]> wrote:
>>> On 4/17/2017 4:22 PM, Gale Andrews wrote:
>>>> Do you agree then James that 1633 was posted too early for you
>>>> to make progress on it? Let's assume I had not e-mailed about
>>>> the separate issue Steve raised in the description, and all you
>>>> had to go on was the description.
>>> The description had just enough in it for me to DEVEL-FIX the bug.
>>>
>>> So in that sense it was ready to work on..
>>>
>>> However, correctly, my 'fix' did not close the bug, because there was a
>>> bug still.  That made me feel I hadn't made progress.
>>>
>>> So in that sense the bug was not 'ready to be worked on'.
>>>
>>>
>>> This bug is not really bugging me.  It's only 6 items in the comment
>>> trail so far.  The bugs that frustrate me have constantly mutating steps
>>> to reproduce.  I hadn't seen before that that is the key thing that
>>> makes them frustrating.  If we accept that we often re-use an original
>>> bug for 'residuals', possibly updating the steps to reproduce and the
>>> title when we do, then we need to do something more.
>> There is a good side to reusing a bug report for what you call residuals,
>> in that the history and comment trail is in one place, and we don't add
>> to the bug count.
>>
>> I don't tend to regard a fix that breaks something else as a residual. I
>> call it the wrong fix and expect that the original bug would reopen.
>> Perhaps it lays too much "blame" to do that, but even if we open a
>> new bug for what got broken, we MUST still reopen the original bug
>> because I assume it would have to be retested.
>>
>>
>>> I propose that when a developer marks a bug as DEVEL-FIXED they should
>>> post steps to reproduce if there were none such already.  By saying
>>> DEVEL-FIXED the developer is claiming, as a minimum, that the steps to
>>> reproduce no longer reproduce the issue.  If they are wrong, a straight
>>> REOPEN is fine.  If they are right, but updated steps show there is
>>> still a bug, then ***Steps-Updated*** in the log would make a huge
>>> difference.  When reading the comment trail I only HAVE to read down to
>>> the first ***Steps Updated***.  Testers know there is a reason why their
>>> 'tested' flags are being cancelled, developer knows why there
>>> DEVEL-FIXED isn't closing it, and so on. ***Steps Updated*** becomes a
>>> clear mark of progress.  [Not needed when going from empty steps to some
>>> steps, of course].
>> I think it already usually happens, in that I add to my comment that
>> the Steps have been updated. There is no consistent text used for
>> that though, and the text may not be at the top of the comment.
>>
>> I'm fine with your suggestion. You prefer that to a keyword?
>>
>>
>>> IF we do that, then this bug was ready to work on when Steve posted the
>>> description.
>> Yes. There is a risk of residual steps being added post-fix if the
>> developer does not find all of them when he posts DEVEL-FIXED.
>> I think it more gold standard where possible for the steps to be
>> given earlier by the person(s) who created and tested the symptoms.
>>
>> If the bug comes from a report on a list, we can also refer to the URL
>> in case something is unclear.
>>
>> In the case of 1633, the report was on feedback@, so private. But it
>> might have helped a developer who reads feedback@ for us to
>> say where the report came from. It does not post anything personally
>> identifiable to do that.
>>
>>
>> Gale
>>
>>
>>>> On 17 April 2017 at 13:36, James Crook <[hidden email]> wrote:
>>>>>> At what point do we want to log and begin tracking the issue?
>>>>> For me, it is when there is enough information that a developer can make
>>>>> progress on it and feel that they are doing so.  That's pretty early on.
>>>>>
>>>>> --James.
>>>>>
>>>>>
>>>>>
>>>>> On 4/17/2017 1:31 PM, Steve the Fiddle wrote:
>>>>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>>>>> which may include:
>>>>>> * Which platforms are effected?
>>>>>> * Is it repeatable on other hardware?
>>>>>> * Is it a regression?
>>>>>> * Is it part of a broader problem?
>>>>>> * Does the symptom characterise the cause?
>>>>>> * Which of the steps that originally produced the problem are required
>>>>>> to reproduce the problem?
>>>>>> * Is it dependent on locale?
>>>>>> * ...
>>>>>>
>>>>>> Yes it is good to know the answers to all of these questions when
>>>>>> tackling a fix, but determining the answers is part of the process of
>>>>>> fixing the problem.
>>>>>>
>>>>>> At what point do we want to log and begin tracking the issue?
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>>>>> visibly see a bug progressing towards closure.
>>>>>>>>
>>>>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>>>>
>>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>>
>>>>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>>>>> the bug.
>>>>>>>>
>>>>>>>> My second commit fixes that residual issue too:
>>>>>>>>
>>>>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>>>>
>>>>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>>>>> wrong too.
>>>>>>>>
>>>>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>>>>
>>>>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>>>>
>>>>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>>>>
>>>>>>>>
>>>>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>>>>> important as it was originally, and indeed the original bug may have been
>>>>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>>>>> bug fixer.
>>>>>>>>
>>>>>>>> Again this is not so much about practicalities as about how it feels to
>>>>>>>> fix the bugs.
>>>>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>>>>
>>>>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>>>>> passes those - Gale will
>>>>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>>>>> close the bug, and that
>>>>>>> can take a lot of time.
>>>>>>>
>>>>>>> Peter
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> --James.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>>>>
>>>>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>>>
>>>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>>>> helping out by writing a bug report when they see a user report or
>>>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>>>
>>>>>>>> When I logged the bug, I had no more information than you.
>>>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>>>
>>>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>>>> they say I think it's better to write steps for what we can
>>>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>>>> description.
>>>>>>>>
>>>>>>>>
>>>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>>>> you.
>>>>>>>>
>>>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>>>> to everyone with Bugzilla access.
>>>>>>>>
>>>>>>>> I'm a "volunteer" not an employee.
>>>>>>>>
>>>>>>>>
>>>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>>>> description might be no better than one with wrong information,
>>>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>>>> report that generated it, or comes to it a long time after the
>>>>>>>> report, lack of steps can be a serious drawback.
>>>>>>>>
>>>>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>>>>
>>>>>>>> You have said many times that bugs cannot be closed until the full
>>>>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>>>>
>>>>>>>>
>>>>>>>> So I would say go ahead and log please, but not until you are
>>>>>>>> able to add steps.
>>>>>>>>
>>>>>>>> We may not immediately have time to fully analyse the problem and work
>>>>>>>> out steps to fully characterise the problem, and that delay before
>>>>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>>>>> all,  but I accept that it's your decision.
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>> The only exception might be a P2/P1 that
>>>>>>>> was found close to release. In that case the RM needs to
>>>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>>>> to fill in the blanks.
>>>>>>>>
>>>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>>>> tracker when you have completed testing.
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>>
>>>>>>>> Gale
>>>>>>>>
>>>>>>>>
>>>>>>>> See, it's even caught you out now. :=)
>>>>>>>>
>>>>>>>>
>>>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>>>> The issue was not described there either. The email is saying that VI
>>>>>>>> users
>>>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>>>>> can.
>>>>>>>>
>>>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>>>> unintuitive for VI users?
>>>>>>>>
>>>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>>>
>>>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>>>> unique value for the position. That would be consistent.
>>>>>>>>
>>>>>>>>
>>>>>>>> Gale
>>>>>>>>
>>>>>>>>
>>>>>>>> --James.
>>>>>>>>
>>>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>>>
>>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>>
>>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>>
>>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>>
>>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>>
>>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>>
>>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>>>>> format,
>>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>>> values.
>>>>>>>>
>>>>>>>>
>>>>>>>> Gale
>>>>>>>>
>>>>>>>>
>>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>>
>>>>>>>> Steve wrote in:
>>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>>
>>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>>> an exceptional case for audio)".
>>>>>>>>
>>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>>> 100 000 Hz.
>>>>>>>>
>>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>>> reasonable.
>>>>>>>>
>>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>>
>>>>>>>>
>>>>>>>> Gale
>>>>>>>>
>>>>>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Bug reporting, logging and tracking [Was: Accessibility of Spectral Selection Toolbar at high frequencies]

Gale
Administrator
In reply to this post by Vaughan Johnson-4
On 18 April 2017 at 03:25, Vaughan Johnson <[hidden email]> wrote:

> On Mon, Apr 17, 2017 at 12:00 PM, Gale Andrews <[hidden email]> wrote:
>> I believe you are misleading this list, Steve. I replied promptly and
>> asked for more details because I was not able to reproduce the
>> issue (because I was testing fitting into tight spaces, where I was
>> often using CTRL).
>>
>> The user came back 10 hours ago with a video, then further after
>> that, you said you could reproduce the issue on Linux. So the
>> timescales are not as you describe.
>>
>> I can (about half the time) reproduce the issue now, but for me it
>> is definitely moonphase. There are good workarounds.
>>
>> I store bugs that I can't add reasonably promptly to Bugzilla
>> (for whatever reason) on my local file system. So they don't get
>> lost, but that does not even apply in this case.
>>
>> Anything I do or don't do in Bugzilla is subject to health. If I can
>> barely stand or keep my eyes open, as was the case for a week
>> or so at the end of March, then local storage may be all that
>> happens.
>
> Gale, I'm very sorry to hear your health is so bad -- I knew only that
> it was not good, no specifics.
>
> Steve and Peter on QA and James-with-bug-fixer-hat-on are trying to
> help the process, afaict, not attack your powers. I hope we can all
> see this as, and make it, more amicable and feasible given our
> resources.

I can't avoid the impression that Steve and Peter are attacking my
powers. If I have Bugs Czar powers I should be able to make a
polite request that Steps to Reproduce is populated when
creating a bug (which most people do anyway) without being told
that I have no powers to tell people what to do.

It takes both sides to be amicable and flexible in order to make
progress when "powers" are involved.



Gale


> - Vaughan
>
>
>>
>>
>>
>> Gale
>>
>>
>> On 17 April 2017 at 16:51, Steve the Fiddle <[hidden email]> wrote:
>>> A user "kensmbour" posted a bug report to feedback@ three days ago in
>>> a post titled "small noticeable occurence" (sic)
>>> Have you logged that somewhere Gale? If you have, where? If not, how
>>> do we prevent it from getting lost?
>>>
>>> Steve
>>>
>>> On 17 April 2017 at 16:31, Gale Andrews <[hidden email]> wrote:
>>>> I am not proposing to duplicate my previous reply, beyond this.
>>>>
>>>> At a minimum, post at least one set of reproducible steps that
>>>> a tester or developer could follow, and set the platform to
>>>> whatever platform you tested on.
>>>>
>>>> You can include another platform that a user reported the issue
>>>> on if you can partly reproduce what the user said, but mention
>>>> the part-reproducibility in the description.
>>>>
>>>>
>>>>
>>>> Gale
>>>>
>>>>
>>>> On 17 April 2017 at 13:31, Steve the Fiddle <[hidden email]> wrote:
>>>>> When a bug is first noticed, there are inevitably many 'unknowns',
>>>>> which may include:
>>>>> * Which platforms are effected?
>>>>> * Is it repeatable on other hardware?
>>>>> * Is it a regression?
>>>>> * Is it part of a broader problem?
>>>>> * Does the symptom characterise the cause?
>>>>> * Which of the steps that originally produced the problem are required
>>>>> to reproduce the problem?
>>>>> * Is it dependent on locale?
>>>>> * ...
>>>>>
>>>>> Yes it is good to know the answers to all of these questions when
>>>>> tackling a fix, but determining the answers is part of the process of
>>>>> fixing the problem.
>>>>>
>>>>> At what point do we want to log and begin tracking the issue?
>>>>>
>>>>> Steve
>>>>>
>>>>> On 17 April 2017 at 13:19, Peter Sampson <[hidden email]> wrote:
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 17, 2017 at 1:11 PM, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> Where I am coming from on this is only indirectly about practicalities and
>>>>>>> efficiency.  As someone who fixes some bugs, I get satisfaction when I can
>>>>>>> visibly see a bug progressing towards closure.
>>>>>>>
>>>>>>> My first commit, I hoped, was enough to close the bug:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>
>>>>>>> However, I'd certainly agree the bug title is sufficiently general that it
>>>>>>> does cover more, and the bug, that I was not aware of, of max copying from
>>>>>>> min fits under that title too.  I think my real issue was that I didn't get
>>>>>>> the satisfaction of seeing the bug close.  Instead more work, that seemed
>>>>>>> less important than the original (minor) issue arrived.  My peve about the
>>>>>>> 'steps to reproduce' was that I could not use that to argue that I HAD fixed
>>>>>>> the bug.
>>>>>>>
>>>>>>> My second commit fixes that residual issue too:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/24c2c6e070ab94d676f1c70b615d92269a939889
>>>>>>>
>>>>>>> However, I am expecting not to get the satisfaction of seeing the bug
>>>>>>> close from that either.  I gave the reasons in a previous email.  There are
>>>>>>> residuals (the fix does not yet work in German).  Arguably truncating the
>>>>>>> frequency display rather than showing '------' for invalid/out-of-range is
>>>>>>> wrong too.
>>>>>>>
>>>>>>> So basically the experience of working on bugs is unsatisfying.  I would
>>>>>>> get a small degree of satisfaction from seeing bug 1633 transition from P4
>>>>>>> to P5.  I would feel I had made some progress in resolving an issue.
>>>>>>>
>>>>>>> I added a new bug about Spectral Selection Toolbar in German.
>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1634
>>>>>>>
>>>>>>> Maybe this new bug will be enough to allow us to close 1633.
>>>>>>>
>>>>>>>
>>>>>>> This isn't about practicalities.  It's about how it feels to fix bugs.
>>>>>>> Even though there appear to be two bugs in 1634, I think the experience of
>>>>>>> working on 1634 might be more satisfying than 1633, as there is a real
>>>>>>> possibility of feeling one is progressing.  The steps to reproduce are there
>>>>>>> and define what the bug is, rather than the title doing so.  I think if the
>>>>>>> steps to reproduce are updated significantly to cover other similar issues,
>>>>>>> then a comment ***Steps to Reproduce Updated*** in the log would help a lot.
>>>>>>> Then someone reading the comment trail knows that essentially a new or
>>>>>>> residual issue is being worked on now, and earlier bug trail is not as
>>>>>>> important as it was originally, and indeed the original bug may have been
>>>>>>> fixed.  So ***steps to reproduce updated*** will feel like progress, for a
>>>>>>> bug fixer.
>>>>>>>
>>>>>>> Again this is not so much about practicalities as about how it feels to
>>>>>>> fix the bugs.
>>>>>>
>>>>>>
>>>>>> It's also about how it feels to test fixed bugs and then not see them close.
>>>>>>
>>>>>> But as we know, even if there are clear Steps To Reproduce and testing
>>>>>> passes those - Gale will
>>>>>> usually insist on "testing around" and not just relying on steps-passing to
>>>>>> close the bug, and that
>>>>>> can take a lot of time.
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 4/17/2017 11:49 AM, Steve the Fiddle wrote:
>>>>>>>
>>>>>>> On 17 April 2017 at 03:47, Gale Andrews <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 21:31, Steve the Fiddle <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 21:13, Gale Andrews <[hidden email]> wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 20:29, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> Gale, that issue was not in the steps to reproduce
>>>>>>>
>>>>>>> Well, isn't that the very point I have been making? I appreciate others
>>>>>>> helping out by writing a bug report when they see a user report or
>>>>>>> when a bug is confirmed on a list, but *everyone* should write proper
>>>>>>> steps to reproduce (in the Steps to Reproduce) box.
>>>>>>>
>>>>>>> When I logged the bug, I had no more information than you.
>>>>>>> I didn't include all of the detail reported by the person that wrote
>>>>>>> in to feedback@ because it did not appear to be correct, and in my
>>>>>>> opinion, incorrect information is worse than incomplete information.
>>>>>>>
>>>>>>> User information often isn't correct. If we can't reproduce what
>>>>>>> they say I think it's better to write steps for what we can
>>>>>>> reproduce, then refer to the user's discrepant account in the
>>>>>>> description.
>>>>>>>
>>>>>>>
>>>>>>> If you prefer that I don't log bugs until I have time to work out the
>>>>>>> full scope of the issue, including detailed steps to reproduce, then
>>>>>>> that's you're call. I'm perfectly happy to leave bugzilla entirely to
>>>>>>> you.
>>>>>>>
>>>>>>> That isn't very efficient, and it is something that can be delegated
>>>>>>> to everyone with Bugzilla access.
>>>>>>>
>>>>>>> I'm a "volunteer" not an employee.
>>>>>>>
>>>>>>>
>>>>>>> However a bug report with no steps to reproduce and a partial
>>>>>>> description might be no better than one with wrong information,
>>>>>>> as we saw today. If the person reading it has not seen the user
>>>>>>> report that generated it, or comes to it a long time after the
>>>>>>> report, lack of steps can be a serious drawback.
>>>>>>>
>>>>>>> "Bug 1633 - Spectral Selection Toolbar incorrect above 100 kHz"
>>>>>>> That looks pretty clear to me that there's one or more problems in the
>>>>>>> Spectral Selection Toolbar for frequencies above 100 kHz.
>>>>>>>
>>>>>>> You have said many times that bugs cannot be closed until the full
>>>>>>> scope of the bug has been investigated, in fact, that was a reason
>>>>>>> that you gave for not allowing Peter or myself to close bugs.
>>>>>>>
>>>>>>>
>>>>>>> So I would say go ahead and log please, but not until you are
>>>>>>> able to add steps.
>>>>>>>
>>>>>>> We may not immediately have time to fully analyse the problem and work
>>>>>>> out steps to fully characterise the problem, and that delay before
>>>>>>> logging the bug may increase the likelihood of it not being logged at
>>>>>>> all,  but I accept that it's your decision.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> The only exception might be a P2/P1 that
>>>>>>> was found close to release. In that case the RM needs to
>>>>>>> know ASAP and there should be no shortage of willing hands
>>>>>>> to fill in the blanks.
>>>>>>>
>>>>>>> For bugs that are not time sensitive, perhaps you could say to
>>>>>>> feedback@ as I sometimes do, that you will add it to the bug
>>>>>>> tracker when you have completed testing.
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> See, it's even caught you out now. :=)
>>>>>>>
>>>>>>>
>>>>>>> and my fallback when there are no steps to reproduce is to read comment 0.
>>>>>>> The issue was not described there either. The email is saying that VI
>>>>>>> users
>>>>>>> can't use spectral selection with porpoise (or bat) sounds, and now they
>>>>>>> can.
>>>>>>>
>>>>>>> I only tested with KHz (and MHz).  The bug you report here has a
>>>>>>> different cause.  One possible fix is to make the number of digits in
>>>>>>> the Hz display variable, rather than truncate, but that might prove
>>>>>>> unintuitive for VI users?
>>>>>>>
>>>>>>> Can you say then how we would display in Hz, a spectral selection of
>>>>>>> 120 000 Hz to 180 000 Hz?
>>>>>>>
>>>>>>> I can't discuss what technically could be done, but I think it "should"
>>>>>>> behave as Selection Toolbar does when the format can't show a
>>>>>>> unique value for the position. That would be consistent.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> --James.
>>>>>>>
>>>>>>> On 4/16/2017 8:04 PM, Gale Andrews wrote:
>>>>>>>
>>>>>>> On 16 April 2017 at 18:56, James Crook <[hidden email]> wrote:
>>>>>>>
>>>>>>> So that our VI users who work with bat and/or porpoise sounds are not
>>>>>>> inconvenienced, I have addressed this issue with following commit:
>>>>>>>
>>>>>>> https://github.com/audacity/audacity/commit/80928bfe6198d30c329536d1fcc2b7d4396f83d9
>>>>>>>
>>>>>>> Thanks. That fixes keyboard-creating and -adjusting a spectral selection
>>>>>>> that goes above 100 000 Hz. I think that will be much appreciated, but
>>>>>>> I don't see that I could resolve the bug just with that.
>>>>>>>
>>>>>>> In Hz format, the display of High Frequency remains incorrect above
>>>>>>> 100 000 Hz. It's the same as Low Frequency.
>>>>>>>
>>>>>>> Surely it should show the correct High and Low frequencies with leading
>>>>>>> truncation, just as when you select in a 38 hour track using samples
>>>>>>> format,
>>>>>>> Selection Start and End in Selection Toolbar show different but truncated
>>>>>>> values.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>>> On 4/16/2017 5:59 PM, Gale Andrews wrote:
>>>>>>>
>>>>>>> Steve wrote in:
>>>>>>> http://bugzilla.audacityteam.org/show_bug.cgi?id=1633#c0
>>>>>>>
>>>>>>> "In my opinion, it is not unreasonable to limit the display to 99.999 kHz
>>>>>>> and truncate the leading "1" when 100 kHz or higher (because this is
>>>>>>> an exceptional case for audio)".
>>>>>>>
>>>>>>> For display I might agree, but this does mean that Spectral Selection
>>>>>>> Toolbar is inaccessible for audio of 200 000 Hz or higher, because
>>>>>>> there is no way for VI users to create spectral selections above
>>>>>>> 100 000 Hz.
>>>>>>>
>>>>>>> I don't know if any VI users work with bat or porpoise sounds, but if
>>>>>>> we compare the case of long audio (say 48 hours) VI users can use
>>>>>>> Selection Toolbar to create selections or move the cursor because
>>>>>>> there is a dd:hh:mm:ss format. They won't be able to use samples
>>>>>>> format because the leading values are truncated, which I agree is
>>>>>>> reasonable.
>>>>>>>
>>>>>>> So, might not at least the kHz format in Spectral Selection Toolbar
>>>>>>> support 100 000 Hz or more? I think this is worth an Enh on Bugzilla
>>>>>>> (still only P4) unless there is a technical reason why not.
>>>>>>>
>>>>>>>
>>>>>>> Gale
>>>>>>>
>>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...