A few words on development

GNU Radio
#1

The other week, I made a post on my webpage about people not using GNU
Radio
enough, which sparked off quite an interesting debate on the mailing
list.
Just the other day, I went and pushed out some simple examples using the
UHD
interface in GNU Radio. This, too, caused some discussion. And the two
are
not unrelated.

As has been pointed out by a number of people, myself included (many
times),
is that GNU Radio is a very challenging project both in its scope and
its
usage. It’s it not an end product, but a development platform to build
some
very complex systems. Communications is not an easy subject, and mixing
RF,
comms theory, information theory, computer science, and raw programming
together is a very special skill set. But despite me thinking not enough
people are using it, a ton of people ARE using GNU Radio (my real point
was
that I see many situations where others could have benefited from using
our
project instead of rolling their own), so it definitely has a good base
of
users. What I’m now seeing, and this where the recent UHD apps comes in,
is
that there we really have a lack of developers.

One thing that I keep hearing is feature requests. Some of these are
small.
A consistent coding style is one of them. More apps and examples.
Better/more documentation. These are all on my todo list, and the other
hard
working GNU Radio developers are doing their best to help out and move
the
project forward (we’ve all see what Josh is capable of doing when he’s
pulling one of his 25 hour days). But there is so much more to do! It
was
great to get feedback immediately for my UHD examples in GNU Radio. That
just tells me there was a hole that needed filling. Some of them were
bug
reports, which is fine. Instead of bug reports, though, I want to see
bug
fixes. This could come in the form of a patch or even a Git branch
somewhere
else (I use Github for all of my branch development work; see
http://gnuradio.squarespace.com/blog/2010/10/29/using-git-with-github-for-developing.html
).

What it seems to come down to is a lack of initiative. We are all
willing to
wait until someone else does something for us, and then report on the
problems. But it’s hard to start something and push it out there. First,
you
expose yourself to criticism and bug reports. You might feel
uncomfortable
about your code. Don’t. Don’t worry about those things. We the community
as
a whole will be much more grateful for your efforts in making the
project
better than insulting you for mistakes or “ugly” code. We can work on
minor
issues like that. Especially if everyone is helping.

There are two things that I want everyone to consider helping with.
First,
look at my post on using Github (and use whatever Git-supported service
you
prefer) to help develop, add features, and fix bugs in branches. I can
then
pull them into the master branch easily. Second, I have started to build
a
Coding Guide on our GNU Radio Wiki (
http://gnuradio.org/redmine/wiki/gnuradio/Coding_guide). It’s very basic
right now, but we can pull in the text that is in README.hacking, too. I
find, and I think others do as well, that getting information in the
form of
a webpage is preferable to a text file. We can use this space to iterate
and
evolve our style, and then hopefully (over time) backtrack and improve
the
existing code that we find lacking.

If we can get your help for stuff big and small, I really think we can
start
to see us making the project even better than it is now.

Thanks for your time,
Tom

#2

hopefully (over time) backtrack and improve the existing code that we
find lacking.

If we can get your help for stuff big and small, I really think we can
start to see us making the project even better than it is now.

Thanks for your time,
Tom
Having been a contributor of both new-content and bug-fixes and
“sidecars” (like build-gnuradio), I can attest that the experience is
very
rewarding. I only regret that I can’t spend more time on making Gnu
Radio better. Between my full-time job, and spending my
“spare” (ha!) time using Gnu Radio for actual applications work, I
find I have less time for bug-fixing/contributing than I used to.

The Josh object is amazing, to be sure. But even an energetic young
whipper-snapper like Josh can’t keep from burnout forever.
So, those of you who feel competent to contribute, and have been
holding back, JUST DO IT :slight_smile:

#3

On Tue, May 17, 2011 at 07:51:00PM -0400, Marcus D. Leech wrote:

whipper-snapper like Josh can’t keep from burnout forever.
So, those of you who feel competent to contribute, and have been holding
back, JUST DO IT :slight_smile:

I can agree on one thing in particular: I wish I had more time to work
on GNU Radio, it’s a great project. Also, contributing stuff is better
than requesting things.

Still, I also believe the community thing can be improved for GNU Radio.
From my experiences, I can say that the process of contributing stuff is
quite opaque.

For the one-line bug-fixes, this seems not to be a problem. For bigger
contributions, things could be smoother.

First of all, how exactly does one contribute stuff? There’s Tom’s blog
entry on how to use github, there’s the gnuradio-patch mailing list, and
theres the trac bugtracker. So what do I use? Do all major patches go
through Tom? But isn’t he busy? By the way, the official GR website
seems to have a very outdated document on this topic
(http://gnuradio.org/redmine/wiki/gnuradio/Development).

And what kind of stuff is accepted, anyway? How do I know that whatever
code I feel should be part of the GNU Radio core will be actually
merged?

The Coding Guide is a good step in the right direction. But let me
suggest some other things to smoothen the ‘community integration’:

  • There could be another document with the definitive guide on how to
    contribute. Perhaps updating the previous link would be enough.
    Questions answered should include:
    • What kind of stuff is accepted into the core, what kind of stuff is
      better maintained as a separate CGRAN project? (Examples, refer to
      the mailing lists as a place to discuss this…)
    • The mechanics/protocol of actually submitting
    • What happens after submitting?
  • Revive the bug tracker.
  • Explain who’s who in GNU Radio (seriously, who’s actually actively
    developing GR besides Tom? Are there areas of responsibility? Who may
    submit to the master?)
  • Create a list of suggestions of contributions (“You want to
    contribute? How about you write a foo-agulator for standard bar? How
    about writing the docs for block grep -R 'FIX MY DOCS' src/lib/?”)

This would be great.

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

#4

On Wed, May 18, 2011 at 9:43 AM, Martin B. [email protected]
wrote:

the community as a whole will be much more grateful for your efforts

Having been a contributor of both new-content and bug-fixes and
whipper-snapper like Josh can’t keep from burnout forever.
quite opaque.

Agreed. We really need to update the website and make things more clear.
But
here’s the general rules to follow:

  • use a patch for a small fix; just a couple of lines in one or two
    files
  • use the “Issues” on the Redmine page to add feature requests or to
    report
    bugs that you don’t know how to fix (
    http://gnuradio.org/redmine/projects/gnuradio/issues)
  • use a git branch (on github or other service) for developing big
    things

Yes, I’m very busy, but right now everything is coming through me. There
is
a thought of a “gatekeeper” for the code that gets merged into master to
make sure it fits with our standards. This mostly means that any new
code is
checked to see if it breaks anything or changes any interfaces. New code
and
new features tend to be much easier to work with. API changes have to be
saved for the next branch.

Also, I admit that we tend to be bad about looking at the issues on the
Redmine page. Every now and then, I’ll find some time to try and work a
few
of them out. Partly, these issues tend not to be critical; people seem
to
report the critical issues on the list. I would like it if we all tried
to
start using the issues concept a bit more; it will provide a better
history/record of the project’s evolution.

And what kind of stuff is accepted, anyway? How do I know that whatever

code I feel should be part of the GNU Radio core will be actually
merged?

That’s a very interesting question. A couple of us have some sort of
plan in
mind for the project, but largely, it develops as needs arise or someone
gets interested in something. There are two things here.

First, we as a community are starting to develop a better roadmap of the
project. This is due largely to our monthly conference calls (details on
that in the next email). We are really starting to lay down a plan for
what’s going to be in 3.5.

Second, if you have something that you are working on that you think
should
be a part of GNU Radio, the best thing would be to email the list and
start
a discussion on it. Ask if it’s a CGRAN project (like an application),
and
add-on to GNU Radio, or some deeper change to the code that might need
some
discussion between a bunch of us.

Again, we (that is, I) need to be better about using our webpage. We
have
this concept of a roadmap on the wiki that hasn’t really been used for a
while. We should try and lay down a plan for this (and then stick to it
as
much as possible).

  • Revive the bug tracker.
  • Explain who’s who in GNU Radio (seriously, who’s actually actively
    developing GR besides Tom? Are there areas of responsibility? Who may
    submit to the master?)
  • Create a list of suggestions of contributions (“You want to
    contribute? How about you write a foo-agulator for standard bar? How
    about writing the docs for block grep -R 'FIX MY DOCS' src/lib/?”)

This would be great.

MB

Agreed, Martin, those are all really good suggestions and points to
think
over. I hope we can keep iterating on these concepts over the next few
weeks
and months. I will try my best to add more content to the website, and
others should feel free to help out as you feel you can.

Martin, maybe add these questions to the coding guide page or make
another
page for juts for explaining contributions. It’ll give us a template
work
from and update.

One thing is that we haven’t done a good enough job helping you help us,
so
the process is ill defined currently. So as we are working on this,
hopefully it will be more streamlined and we’ll get a better
understanding
of how to operate.

Thanks for your great comments and suggestions, Martin!

Tom

#5

On Tue, May 17, 2011 at 4:39 PM, Tom R. [email protected]
wrote:

together is a very special skill set. But despite me thinking not enough
pulling one of his 25 hour days). But there is so much more to do! It was
about your code. Don’t. Don’t worry about those things. We the community as
find, and I think others do as well, that getting information in the form of
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

I have a minor comment for anyone planning on using github. It has
what could be a potentially cool feature called a “Network view” where
you can look at what every one is doing on their various branches.
However, it only works if everyone creates their repositories by
forking from one another. I would suggest then that anyone who wants
to create a new github repo do it by forking Tom’s repository.

#6

On May 17, 2011, at 5:39 PM, Tom R. wrote:

What I’m now seeing, and this where the recent UHD apps comes in, is that there
we really have a lack of developers.

What it seems to come down to is a lack of initiative. We are all willing to
wait until someone else does something for us, and then report on the problems.
But it’s hard to start something and push it out there.

Hi Tom - Related to this thread, this blog post about Qt’s developer
hierarchy might be interesting. GNU Radio isn’t nearly as huge as Qt,
but maybe it could benefit from a similar hierarchy – which is already
in place to some degree, but maybe having such a post or wiki page would
help solidify it. - MLD

<
http://labs.qt.nokia.com/2011/05/20/open-governance-roles-and-responsibilities/

Last week, in my blog on the Maturity Level List and in the previous
weeks Maturity Levels, I left some indications of what would be expected
of a maintainer of a portion of the Qt codebase. In this blog Id like to
explain a bit more whats expected of people working via the Qt Open
Governance, what roles will exist and what responsibilities will each
have.

In short, there will be three levels only:

Contributor
Approver
Maintainer

The presence of a Chief Maintainer is not exactly a fourth level. More
on that below.

#7

On Thu, May 19, 2011 at 12:32 AM, Ben R. [email protected] wrote:

I have a minor comment for anyone planning on using github. It has
what could be a potentially cool feature called a “Network view” where
you can look at what every one is doing on their various branches.
However, it only works if everyone creates their repositories by
forking from one another. I would suggest then that anyone who wants
to create a new github repo do it by forking Tom’s repository.

Hi Ben,

I too have found the network view on github to be very useful.
However, it seems that Tom’s master branch on github is behind the
master branch on gnuradio.org so maybe we are supposed to clone from
here.

Alex

#8

On Fri, May 20, 2011 at 3:49 AM, Alexandru C. [email protected]
wrote:

I too have found the network view on github to be very useful.
However, it seems that Tom’s master branch on github is behind the
master branch on gnuradio.org so maybe we are supposed to clone from
here.

Alex

Yep. The full process would be:

  • make a github fork of Tom’s repository.
  • make a local clone of the gnuradio.org master branch.
  • delete all the existing branches in the github fork.
  • push the master branch to the github fork.

It’s silly that the process is so convoluted, but, as far as I know,
there is no process to tell github that two repositories are in the
same network other than if they have a common fork-ancestor.

Ben

#9

On Fri, May 20, 2011 at 12:32 PM, Michael D. [email protected]
wrote:

hierarchy might be interesting. GNU Radio isn’t nearly as huge as Qt, but
a bit more whats expected of people working via the Qt Open Governance,
what roles will exist and what responsibilities will each have.

In short, there will be three levels only:

    Contributor
    Approver
    Maintainer

The presence of a Chief Maintainer is not exactly a fourth level. More on
that below.

Thanks, Michael, that’s really useful; it’ll definitely give me
something to
think over, but initially, I like the idea of different people having
approval say over some component (like Josh and anything GRC or
Achilleas
and gr-trellis [if he’d want to]), which would ease the burden on me to
make
sure everything is good.

BTW: I just updated my master branch on my github account. I’ll try to
remember to keep it up.

Tom