Forum: GNU Radio 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:
http://gnuradio.org/redmine/projects/gnuradio/issues

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 gnuradio.org to use the issue
  tracker. Unfortunately, we still have to manually activate your 
account
  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
  issue).

To get all of this working, Ben Reynwar 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
code).
When that happens, one of us checks the issue. It might get rejected
(perhaps it violates coding conventions, or the bug fix itself is 
buggy),
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
smoother.

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

Cheers,
MB

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

Dipl.-Ing. Martin Braun
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

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 Braun (CEL) 
<martin.braun@kit.edu>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:
> http://gnuradio.org/redmine/projects/gnuradio/issues


<snip>

First of all, thanks to Martin for coordinating this, and I'll second 
our
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 
thing
that will help us more than anything is a small, simple test program 
that
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!

Tom