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 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
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 B.
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