On Wed, May 18, 2011 at 9:43 AM, Martin Braun
<address@hidden> wrote:
On Tue, May 17, 2011 at 07:51:00PM -0400, Marcus D. Leech wrote:
> 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.
>
> 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 :-)
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).
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 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).
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
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
--
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
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio