# What does "Feedback" mean in the issue tracker? **URL:** \ **Category:** GNU Radio\ **Created:** [October 25, 2014, 3:03am UTC](https://www.ruby-forum.com/t/what-does-feedback-mean-in-the-issue-tracker/232740 "2014-10-25T03:03:40Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![addis\_a](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/c4cdca/32.png) [@addis\_a](https://www.ruby-forum.com/u/addis_a)\ **Post date:** [October 25, 2014, 3:03am UTC](https://www.ruby-forum.com/t/what-does-feedback-mean-in-the-issue-tracker/232740/1 "2014-10-25T03:03:40Z")
What does it mean in the GNU Radio issue tracker for an issue to have the status “Feedback”? Two of my bugs have been in this state and I don’t know what this means about them. I thought it might mean “asking for reporter’s response” but in the one case I gave it and got no response (#667), and in the other the update reads like just diagnosing the bug (#713). I’d like to get this clarified so I can be assured I’m doing the right thing in my bug reporting. – Kevin R. [http://switchb.org/kpreid/](http://switchb.org/kpreid/) ---
**Author:** ![dotty](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e56c9b/32.png) [@dotty](https://www.ruby-forum.com/u/dotty)\ **Post date:** [October 25, 2014, 2:28pm UTC](https://www.ruby-forum.com/t/what-does-feedback-mean-in-the-issue-tracker/232740/2 "2014-10-25T14:28:32Z")
On 10/24/2014 09:02 PM, Kevin R. wrote: > What does it mean in the GNU Radio issue tracker for an issue to have the status > “Feedback”? Usually “Feedback” does mean “waiting for user feedback”. But in this case, I think it means “hmm, have to think about that”. Both reports have the same underlying cause. The second one, to do with the resampler, was exposed when some timing code was fixed. In your phase\_bug.py, it’s interesting that removing the lock()/unlock() pair in \_do\_connect() makes the error go away. This probably means that the buffer calculations Tom mentions are not being done during a restart(), which happens at unlock(). The restart() function does not call flatten(), as start() does. I don’t know whether the flowgraph can be reflattened in restart(). If so, that might be a fix. Tom? In the mean time, setting up a couple of multiply\_const blocks and changing the constant at runtime will work as a switch, even though it’s not as efficient. Or, putting a stop()/wait()/start() around the call to \_do\_connect() in both phase-bug.py and try\_die.py makes things work correctly, but might not be what you want. - Jeff ---
**Author:** ![dotty](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e56c9b/32.png) [@dotty](https://www.ruby-forum.com/u/dotty)\ **Post date:** [October 25, 2014, 4:57pm UTC](https://www.ruby-forum.com/t/what-does-feedback-mean-in-the-issue-tracker/232740/3 "2014-10-25T16:57:16Z")
On Oct 25, 2014, at 5:27, Jeff L. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > On 10/24/2014 09:02 PM, Kevin R. wrote: > > > What does it mean in the GNU Radio issue tracker for an issue to have the > > status “Feedback”? > > Usually “Feedback” does mean “waiting for user feedback”. But in this case, I > think it means “hmm, have to think about that”. Both reports have the same > underlying cause. The second one, to do with the resampler, was exposed when some > timing code was fixed. I had understood the response to #667 (though it was unclear, hence my request for clarification) as that two internal connections to the input port of a hier block should be considered independent – capable of having passed different numbers of samples depending on how much work the downstream blocks have done – at the moment the graph is locked and modified. (Which makes sense, though is IMO poor usability, now that I’ve had it pointed out.) Thus, not the same bug at all. (As it happens, I believe there is an actual bug that I failed to correctly reproduce for reporting – the original program I reduced phase-bug.py from did not have two separate connections to the hier block port. I haven’t commented on this before because there’s been no particular use to it until I have a corrected test case.) > In the mean time, setting up a couple of multiply\_const blocks and changing the > constant at runtime will work as a switch, even though it’s not as efficient. In my application, the modification to the flow graph may be entirely unrelated to the subgraph affected by the bug, and may be due to the user requesting different processing (hence, creating new subgraphs), so it’s not really possible to stick to non-reconfiguring changes. Also, disabling unneeded processing is an important feature, because it makes the difference between reasonable CPU use and an uncomfortably toasty laptop. > Or, putting a stop()/wait()/start() around the call to \_do\_connect() in both > phase-bug.py and try\_die.py makes things work correctly, but might not be what you > want. That might be a useful workaround; I’ll keep it in mind. Thanks for the information and suggestions. – Kevin R. [http://switchb.org/kpreid/](http://switchb.org/kpreid/)