News on Bugs & Issues

Hi everyone,

starting now, we would like to re-introduce the GNU Radio issue tracker.
If you don’t know what I’m talking about, it’s what you get when you
click ‘Issues’ on our website:

The issue tracker has been unmaintained for quite a while, but we’ve
cleaned it out and will go back to using that.

For you guys, this means:

  • The tracker is the one place to go for bug reports, patches, feature
    requests and any other issue. The patch-gnuradio mailing list will be
    made obsolete soon.
  • If you have a bug report, patch etc. please post it directly to the
    tracker. This way, we can keep track of open bugs much better; also,
    any discussion specific to this patch is kept out of the way of this
    mailing list.
  • We welcome everyone to sign up on to use the issue
    tracker. Unfortunately, we still have to manually activate your
    to post on the wiki and bug tracker because of spam accounts, but a
    quick email to me off-list will take care of that easily. If you don’t
    wish to sign up, you can still use the guest:gnuradio account.
  • The big advantage is that we will try to handle issues much quicker
    than before (no more than 1-2 weeks until something happens with your

To get all of this working, Ben R. has volunteered to be the chief
bug tracking officer of GNU Radio (thanks a lot, Ben!). He will make
sure bugs are assigned to developers, and that developers don’t ignore
bugs assigned to them. This way, we hope to keep the half-life of open
issues short, and tie in developers other then the few heads of GNU
Radio more closely.

So how does this work now?
Say you’ve discovered a bug, and know how to patch it. You write the
patch, and submit the patch file to the issue tracker, along with a
description of the problem (or you link to your github with the fixed
When that happens, one of us checks the issue. It might get rejected
(perhaps it violates coding conventions, or the bug fix itself is
but most likely, it gets assigned to one of the developers. What happens
then depends on the issue at hand, but the goal is to close issues ASAP.
Bug fixes will usually go into the next minor release, anything API
changing into the next major release.

By implementing these changes, we’re hoping to make the issue process
more tangible and get code submissions into our tree faster.
It might take a couple of weeks before everyone runs smoothly, but
eventually it should make collaboration on this awesome project much

If you have any questions, please ask on-list so we can make this as
transparent as possible.


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On Mon, Dec 10, 2012 at 5:21 PM, Martin B. (CEL)
[email protected]wrote:

Hi everyone,

starting now, we would like to re-introduce the GNU Radio issue tracker.
If you don’t know what I’m talking about, it’s what you get when you
click ‘Issues’ on our website:

First of all, thanks to Martin for coordinating this, and I’ll second
thanks to Ben for stepping up to help us manage the system!

changing into the next major release.

One thing that I wanted to add here. Sometimes we’ll come up with a bug
that we don’t know how to write a patch for. If that’s the case, the
that will help us more than anything is a small, simple test program
demonstrates the bug. The easier it is to reproduce the problem with as
minimal amount of code required, the easier it’ll be to track down,
write a
patch, and test it.

Otherwise, just do as Martin says and we can all start to benefit!