Editing Development

Jump to: navigation, search

Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 5: Line 5:
 
== Cheat Sheet ==
 
== Cheat Sheet ==
  
See the information throughout this page for details about these steps. But when looking to contribute, we encourage you to either make a new issue in the Issue Tracker or identify a current Issue already up and waiting for attention. We also assume you have a public GitHub repo you can use for pull requests and that you have forked the GNU Radio git repo.
+
See the information throughout this page for details about these steps. But when looking to contribute, we encourage you to either make a new issue in the Issue Tracker or identify a current Issue already up and waiting for attention. We also assume you have a public Github repo you can use for the pull requests and that you have cloned the GNU Radio git repo.
  
* Identify which branch of the GNU Radio base code to work from. Most of the time, that's master.
+
* Identify which branch of the GNU Radio base code to work from.
 
* Create a new branch from here to work from.
 
* Create a new branch from here to work from.
 
* Work on the bug fix or feature under the new branch.
 
* Work on the bug fix or feature under the new branch.
 
* Determine the QA code necessary to test and check the fix or feature.
 
* Determine the QA code necessary to test and check the fix or feature.
* Provide (an) appropriate Git commit(s) with well-formatted log messages.
+
* Provide an appropriate Git commit with log messages.
 
* Push the branch to a public repo on Github.
 
* Push the branch to a public repo on Github.
* Issue a pull request against the base branch (i.e., master).
+
* Issue a pull request against the starting branch (i.e., maint or master).
* If you're in the gr-dev group, please update the labels. If you are planning on doing more GNU Radio development, please request access to that group.
+
* Update the Issue on [https://gnuradio.org gnuradio.org] with information about the fix, including a link to the pull request on Github.
* Update the Issue on [https://github.com/gnuradio/gnuradio/issues gnuradio/issues] with information about the fix, including a link to the pull request on Github.
 
* Adding '''fixes #issue_number''' or '''closes #issue_number''' to the bottom of the appropriate commit message leverages [https://help.github.com/articles/closing-issues-using-keywords/ GitHub's automatic issue closing].
 
 
* Wait for the pull request to be merged -- often after some back and forth and testing by other developers.
 
* Wait for the pull request to be merged -- often after some back and forth and testing by other developers.
 
* Mark the Issue resolved and note the commit where it was resolved.
 
* Mark the Issue resolved and note the commit where it was resolved.
Line 30: Line 28:
 
* Documentation
 
* Documentation
 
* Missing test cases
 
* Missing test cases
* Report and reproduce bugs
 
 
* Bug fixes
 
* Bug fixes
* Review pull requests
+
* GUIs
* Implement new features
 
  
The main place to look is the issue tracker: https://github.com/gnuradio/gnuradio/issues. It tracks warnings, TODO's, FIXME's, and unit tests. Any warnings or FIXME fixes are useful as well as any more unit tests to exercise the validity of the signal processing or runtime code. Issues suitable for beginners are tagged [https://github.com/gnuradio/gnuradio/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22 "good first issue"].
+
The main place to look is the issue tracker. Also, look at the results posted by our Jenkins continuous integration service: http://jenkins.gnuradio.org/jenkins/job/GNURadio-master. It tracks warnings, TODO's, FIXME's, and unit tests. Any warnings or FIXME fixes are useful as well as any more unit tests to exercise the validity of the signal processing or runtime code.
  
We also use Coverity for static code analysis. You can find our project at [https://scan.coverity.com/projects]. Here, you can find small things to change and fix (a lot of these are so small you don't even need an FSF copyright assignment).
+
We also use Coverity for static code analysis. You can find our project at https://scan.coverity.com/projects. Here, you can find small things to change and fix (a lot of these are so small you don't even need an FSF copyright assignment).
  
 
There's also the possibility to [https://crm.fsf.org/civicrm/contribute/transact?reset=1&id=16 donate] to our project. The Free Software Foundation provides the infrastructure to do so, and can provide a receipt for US tax payers, who can deduct a donation.
 
There's also the possibility to [https://crm.fsf.org/civicrm/contribute/transact?reset=1&id=16 donate] to our project. The Free Software Foundation provides the infrastructure to do so, and can provide a receipt for US tax payers, who can deduct a donation.
Line 43: Line 39:
 
== Development Style ==
 
== Development Style ==
  
Our coding and development style is codified on [https://github.com/gnuradio/greps/blob/master/grep-0001-coding-guidelines.md GREP1].
+
When writing new code, we have a few general rules for where and how things go in. We follow that standard [http://schacon.github.com/git/gitworkflows.html Git workflows] concept in our Git branch structure. We have two main branches used in development, the 'master' and the 'next.' Here are a few rules to go by when working on new code or fixing old code in GNU Radio.
 +
 
 +
* Make sure any changes in 'master' do not break the API (even if there is an error)
 +
** Additions to the API are fine
 +
** Deprecating code by outputting a message is done here
 +
* Removing code or changing API names or calling conventions MUST be done in 'next'
 +
* Work in 'master' for as much as possible unless you are going to change the API
 +
 
 +
Following these simple rules will help get your code merged in faster and with less hassle.
 +
 
 +
When working in code, there may be additions or things you might not know how to do just yet. It is appropriate in these instances to make a comment about it. The convention for this is to use the following keywords to indicate where you have left something for later:
 +
 
 +
* Use TODO comments for low-priority fixes
 +
* Use FIXME comments for high-priority fixes
 +
 
 +
For all kinds of modifications and changes, try and make sure the following points are observed:
 +
 
 +
* For patches, the diff contains the minimal but related incremental changes, for all the files needing modification to implement the change. In other words, the diff should take a working GNU Radio source tree and modify it to become a working GNU Radio source tree with the feature implemented.
 +
* Diffs are made from the GNU Radio tree root, and are based on an recent master branch.
 +
** use [http://schacon.github.com/git/git-format-patch.html git format-patch] to create your patches.
 +
** Minor bug fixes should be applied to the maint branch
 +
** Addon's and features should be applied to the master branch
 +
** Changes to the structure, API, or other surgery to the code should be applied to the next branch
 +
* After applying your changes or building your branch, the command 'make test' must pass.
 +
* There should be no additional compiler warnings to what already occurs.
 +
* No gratuitous whitespace changes.
  
 
=== Quality Assurance (QA) Code ===
 
=== Quality Assurance (QA) Code ===
Line 55: Line 76:
 
No problem. If it's really an unfixed bug, you're perhaps the first to stumble upon it. Write an email to the discuss-gnuradio@gnu.org mailing list explaining what's wrong and, ideally, providing a test case so the developers can reproduce the error.
 
No problem. If it's really an unfixed bug, you're perhaps the first to stumble upon it. Write an email to the discuss-gnuradio@gnu.org mailing list explaining what's wrong and, ideally, providing a test case so the developers can reproduce the error.
  
If it's a confirmed bug, you should add a ticket to the [https://github.com/gnuradio/gnuradio/issues GNU Radio issue tracker] by following these steps:
+
If it's a confirmed bug, you should add a ticket to the bug tracker (http://gnuradio.org/redmine/projects/gnuradio/issues) by following these steps:
  
1. If you don't already have one, create an account on GitHub.<br />
+
1. You'll need to login to the website, first, and then click New Issue.<br />
2. You'll need to login to GitHub, first, and then click New Issue.<br />
+
2. Set if this Issue is a bug or perhaps a new feature.<br />
3. Provide an appropriate subject to explain the Issue (shorter than 72 characters).<br />
+
3. Provide an appropriate subject to explain the Issue.<br />
 
4. Provide a comprehensive description of the Issue. Provide links, code, and any examples here. It's much easier for us to understand a bug if we have a simple test case that demonstrates the issue such as a GRC file or Python program. Feel free to upload attachments using the Files button.<br />
 
4. Provide a comprehensive description of the Issue. Provide links, code, and any examples here. It's much easier for us to understand a bug if we have a simple test case that demonstrates the issue such as a GRC file or Python program. Feel free to upload attachments using the Files button.<br />
 +
5. The rest of the attributes of the Issue should be left alone. The GNU Radio development team will handle assignment of the bug and any other relevant attributes.
  
 
=== I've fixed an Issue! What do I do now? ===
 
=== I've fixed an Issue! What do I do now? ===
Line 66: Line 88:
 
That's fantastic! Thanks! To help us provide a consistent experience resolving and fixing issues, please follow these steps.
 
That's fantastic! Thanks! To help us provide a consistent experience resolving and fixing issues, please follow these steps.
  
1. Fork the [https://github.com/gnuradio/gnuradio GNU Radio project repository] to your personal GitHub development space.<br/>
+
1. Create a patch. See the next set of instructions on "How do I submit patches?". If you have a patch file, you can attach it to the Issue directly or use a pull request through github.com.<br />
2. Create a new git branch based on master or next and add commits which fix the issue you found.<br/>
+
2. Update the Issue that you're addressing by setting the Issue status to Feedback and a description of the update, such as the github branch or pull request number.<br />
3. Push the new feature branch to your personal fork of the GNU Radio project repository.<br/>
+
3. Set the Resolution field to Fixed.
4. Create a new pull request on GitHub by visiting the [https://github.com/gnuradio/gnuradio/pulls GNU Radio pull request page] and clicking New pull request, then select the appropriate base branch in the GNU Radio project (master or next) and select your feature branch to compare with from your personal fork .<br/>
+
 
 +
The GNU Radio development team will take the issue from here. We will handle applying or merging the fix and updating the issue from there. We will set the Status to Resolved and set the target version it belongs to. After a week or so without incident, we will close the Issue.
 +
 
 +
See the next section for how to work with our Issue Tracker.
 +
 
 +
== Dealing with the GNU Radio Issue Tracker ==
 +
 
 +
If you are filing a new bug or feature request, here's what you need to know. First, you'll need an account on gnuradio.org. Sign up for that and make sure you can log in; if you have trouble logging in, contact Tom Rondeau for help with your account.
  
The GNU Radio development team will take the issue from here. We will handle merging the fix and updating the issue from there. We will need your help to resolve conflicts and issues regarding your code. Communication will happen solely in the GitHub pull request comments to keep conversation and code close together.
+
Once logged in, you will see the New Issue option right next to Issues. Clicking that will take you to the page to enter the issue you wish to file. First select if this is a bug or a feature and provide a subject line describing it. Fill out the description as clearly as possible to describe the bug or feature. If it's a bug, it is most helpful to us if you would also attached an example application that exercises the bug so that we can easily test it. Add a file by looking below to the Files item and select the button "Choose Files".
 +
 
 +
The rest of the fields are mostly left alone by the initial filer. The GNU Radio team will take a look at the issue and fill in the appropriate fields from there. If the Category of the bug is obvious, please fill that in as appropriate.
 +
 
 +
You may select a priority, though we ask you to be reasonable in your assessment of the priority with respect to the project and not your personal requirements. If this is a feature that you are willing to work on or a bug that you feel you can handle yourself, you may also assign yourself to the task. We, of course, will then expect you to actually complete any issues assigned to you in that case.
 +
 
 +
=== What do the different Status levels mean? ===
 +
 
 +
* New: the default assignment when an issue is added and nothing has been done.
 +
* Feedback: the bug is unclear, we don't know what to do, or it needs more discussion.
 +
* Assigned: we know what to do and have given it to some someone to do it.
 +
* Resolved: patch submitted and merged into maint/master/next. We then wait a few weeks to see if it causes any problems or any other feedback.
 +
* Closed: after a few weeks of either positive or no farther issue with the resolution, we officially close it.
 +
 
 +
It is the task of the developer assigned to a task to update the issue for ever level except closed. The GNU Radio management team will decide when to officially close an issue.
  
 
=== Assignment ===
 
=== Assignment ===
  
 
Assignment to an Issue means that an individual has taken on the task of handling that particular issue of either fixing a bug or adding a feature. When assigned, that issue is claimed by the assignee, and so we expect that person to handle the task. Assigned issues that are not kept up on will be either removed or the assignee will be taken off. Removing the issue will generally occur with a feature request where that feature is not being managed properly. If it is a bug, inaction on it means that others may be discouraged from working on this because it is already assigned.
 
Assignment to an Issue means that an individual has taken on the task of handling that particular issue of either fixing a bug or adding a feature. When assigned, that issue is claimed by the assignee, and so we expect that person to handle the task. Assigned issues that are not kept up on will be either removed or the assignee will be taken off. Removing the issue will generally occur with a feature request where that feature is not being managed properly. If it is a bug, inaction on it means that others may be discouraged from working on this because it is already assigned.
 +
 +
There are a few categories that have default assignments to someone on the GNU Radio development team. The default assignment should be looked at as a triage operation. When assigned, the default assignee should look at the issue and decide how to handle it. It might be that someone else should be assigned to that task, or if it falls outside of the abilities, availability of time, or other such reasons, the default assignee can remove themselves from the issue thus freeing it up for others to take.
 +
 +
=== Target Version ===
 +
 +
Please leave the Target Version field blank until the issue is resolved. We handle this differently in our project than most as we do not build up a list of issues to tackle on a per-release basis.
 +
 +
== How do I submit patches? ==
 +
 +
This depends on the size of the patch. If it is a small patch, e.g. a bug fix which only consists of a few lines, you can just create a diff and attach that to the entry to the issue tracker. Please include a description of the bug and how your patch fixes this bug (see above on obtaining permissions to create bug tracker entries.)
 +
 +
Another easy, very useful (for both you and us) way is to go through github and send us a pull request (See: How can I use github? below).
 +
 +
In most cases, these are the commands you will enter:
 +
 +
<pre># You've just finished editing the patch
 +
$ git add FILE1 FILE2... # Put all the patch-relevant files here
 +
$ git commit -m 'filter: re-snazzled the frombobulator (was zingamawonking)'
 +
$ git format-patch HEAD~ # This will turn the latest commit into a patch file</pre>
 +
Note that the commit message should be prefixed with the component you changed (core, filter, audio, ...). Read the previous commit logs for examples (you can get them with 'git log').
 +
 +
The last command creates a file, usually starting with '0001', which contains the patch. Simply upload this to the issue tracker.
 +
 +
For larger patches (e.g. several commits), it is probably better to upload a modified version of the git repository, e.g. to github (see below).<br />
 +
If you want to extend GNU Radio and add new features, please read 'How can I add new features to GNU Radio?'.
 +
 +
For bug fixes, the least friction is caused if you branch of the 'maint' branch. Anything that goes into 'maint' is automatically rolled up-stream into 'master' and 'next'.
  
 
== How can I add new features to GNU Radio? ==
 
== How can I add new features to GNU Radio? ==
  
 
First of all, you should ask yourself if your code really belongs into the GNU Radio core. If you are developing a GNU Radio module which can exist completely separate of the GNU Radio code, it might be worth uploading it to CGRAN, where you can maintain the code yourself and don't have to go through the process of re-submitting patches.
 
First of all, you should ask yourself if your code really belongs into the GNU Radio core. If you are developing a GNU Radio module which can exist completely separate of the GNU Radio code, it might be worth uploading it to CGRAN, where you can maintain the code yourself and don't have to go through the process of re-submitting patches.
 +
 +
Of course some features (say, new modulators or filters) belong into the core GNU Radio repository. In this case, sending a patch to the mailing list is a bit too bulky. Instead, upload your code to a world-readable git repository, and then post a 'Feature' on our issue tracker. This is explained greater detail [http://gnuradio.squarespace.com/blog/2010/10/29/using-git-with-github-for-developing.html here] .
 +
 +
Before submitting, go through the following check list:
 +
 +
* Does the code include documentation? GNU Radio uses Doxygen for automatic doc generation, so be aware of this when documenting classes.
 +
* Are there unit tests? Are they ''sensible'' unit tests, i.e. do they cover the most common errors?
 +
* Does the patch maintain compatibility with the existing code base?
 +
* Does the code follow the [[coding_guide_impl|GNU Radio coding conventions]]?
 +
* Is the code based on the latest GNU Radio revision?
 +
* Is the code nicely portable?
 +
* Do you have a copyright assignment on file with the FSF?
  
 
If you're having any trouble with this, don't hesitate to ask on the mailing list.
 
If you're having any trouble with this, don't hesitate to ask on the mailing list.
 +
 +
== How can I use github to submit patches/features/changes? ==
 +
 +
'''Note:''' This is the recommended way to provide changes to the GNU Radio code.
 +
 +
Here's the easiest way:
 +
 +
* [https://help.github.com/articles/fork-a-repo/ Fork] a repository from https://github.com/gnuradio/gnuradio
 +
* Clone your repository or add it as a remote to a previously cloned gnuradio repo:
 +
** $ git remote add <name for your repo> <SSH link to your forked repo>
 +
** $ git remote update <name of your repo>
 +
* Make a new feature branch -- please make this distinct from maint/master/next
 +
** $ git branch <feature branch name>
 +
** $ git checkout <feature branch name>
 +
* Commit your changes on your new branch
 +
** $ git commit <files or -a for all changes>
 +
* Make sure it compiles, works, and passes QA
 +
** $ make
 +
** $ make test (or ctest)
 +
* [https://help.github.com/articles/using-pull-requests/ Submit a Pull Request] to merge your branch back into the gnuradio/gnuradio repository
 +
* Wait for us to process that
 +
 +
You need to figure out what the base branch is for you to work off of. Most likely, this will be either maint or master, but it could be next:
 +
 +
* '''maint:''' our bug patch branch; this will become a bug release against the current version. These are for bugs only; no new features. Any patches made to this branch will also be applied to the master and next branch. This branch becomes the patch version of a release, the p of an X.Y.Z.p (omitted if p=0).
 +
* '''master:''' this will become our next minor version release, the Z of an X.Y.Z version. This is where new code codes that’s more than just a bug patch.
 +
* '''next:''' in the X.Y.Z model, this is the staging area for the Y version increments, also called the API version. All code within a release version has the same compatible API. If you use code in the X.Y API release starting with minor release Z0, then all releases after Z0 in that API version are guaranteed to have the same backwards-compatible API. We put stuff on the next branch when we have to break the API. We try to avoid this whenever possible since API releases are rare and so any code submitted here will not be released for a while.
 +
 +
Keep in mind that a pull request is not a guaranteed merge on our part. We will vet the code for both correctness, usefulness, and style, and we might push back requesting some changes. There will likely be a bit of back and forth on this, so don't be discouraged; we're just trying to make sure that the code always gets better.
  
 
== Which kind of patches are accepted into GNU Radio? ==
 
== Which kind of patches are accepted into GNU Radio? ==
Line 99: Line 210:
 
* Non-portable code
 
* Non-portable code
 
* QA failures
 
* QA failures
 +
* Breaking of next (if it was in master)
 
* Lack of [[Development#Whats-this-Copyright-Assignment|copyright assignment]]
 
* Lack of [[Development#Whats-this-Copyright-Assignment|copyright assignment]]
 +
 +
== What if my patch works for master, but not for next? ==
 +
 +
Ideally, you do this:
 +
 +
# Create a branch off master, say foo-master
 +
# Implement feature or fix on foo-master
 +
# Create a branch off next called foo-next
 +
# Merge foo-master into foo-next, fix up breakage
 +
# Implement feature or fix on foo-next (this might have been done or partially done as a result of getting through #4)
 +
# Tell us about foo-master and foo-next
 +
 +
Then we:
 +
 +
# Merge foo-master into master. No problems since foo-master is branched from master.
 +
# Merge foo-next into next. No problems since #4 above already dealt with merge breakage
 +
# Merge master into next. This should end up being a null merge, but it maintains the master->next linkage
  
 
== What's this CGRAN? ==
 
== What's this CGRAN? ==
Line 109: Line 238:
 
== Which coding conventions apply? ==
 
== Which coding conventions apply? ==
  
See [https://github.com/gnuradio/greps/blob/master/grep-0001-coding-guidelines.md Coding guidelines].
+
All contributions should conform to the [http://www.gnu.org/prep/standards_toc.html GNU Coding Standards] as modified for C++ in README.hacking
 +
 
 +
Also, you should check out [[Coding_guide_impl|The GNU Radio Coding Style Guide]].
  
 
== How is the code documented? ==
 
== How is the code documented? ==
Line 145: Line 276:
  
 
};</pre>
 
};</pre>
 +
Starting in GNU Radio 3.5, we have been moving to new top level blocks, like gr-vocoder, gr-audio, gr-digital, etc. Each of these is getting its own group along with any specific group the block should be included in. These groups each have their own page to describe the group as a main description of the blocks and how to use the package. These pages are all linked from the Doxygen manual's front page, which is found in <code>docs/doxygen/other/main_page.dox</code>.
  
 
The top level blocks are all described inside that blocks <code>doc</code> directory in a <code>.dox</code> files named or the component. For example, in the component <code>gr-digital</code>, the manual page describing this component is in <code>gr-digital/doc/digital.dox</code>. This page should provide any detail that can help users add and use these packages and their blocks. As these components are developed, used, and added to, any more details that can go into this Doxygen page should be added for the benefit of anyone else.
 
The top level blocks are all described inside that blocks <code>doc</code> directory in a <code>.dox</code> files named or the component. For example, in the component <code>gr-digital</code>, the manual page describing this component is in <code>gr-digital/doc/digital.dox</code>. This page should provide any detail that can help users add and use these packages and their blocks. As these components are developed, used, and added to, any more details that can go into this Doxygen page should be added for the benefit of anyone else.
Line 166: Line 298:
 
Note that the spacing between sections is important to get the best output format. Furthermore, there are certain Doxygen markups that will cause a problem in the XML representation, like use the of \frac in Latex to create a fraction will not parse properly. There is likely a better way to handle this (PLEASE UPDATE IF YOU KNOW IT), but for now, we just add a space between them as "\ f".
 
Note that the spacing between sections is important to get the best output format. Furthermore, there are certain Doxygen markups that will cause a problem in the XML representation, like use the of \frac in Latex to create a fraction will not parse properly. There is likely a better way to handle this (PLEASE UPDATE IF YOU KNOW IT), but for now, we just add a space between them as "\ f".
  
== What's this Developer Certificate of Origin (DCO)? ==
+
== What's this Copyright Assignment? ==
  
Any code contributions going into GNU Radio will become part of a GPL-licensed, open source repository. It is therefore imperative that code submissions belong to the authors, and that submitters have the authority to merge that code into the public GNU Radio codebase.
+
Before we can accept non-trivial code contributions from you, we need a copyright assignment on file with the [http://www.fsf.org/ FSF]. A description of the process is available [http://www.gnu.org/prep/maintain/html_node/Legally-Significant.html here]. Basically, this guarantees the FSF (who is copyright holder of GNU Radio) does not run into any legal trouble somewhere down the road.
  
At the end of 2020, GNU Radio [https://lists.gnu.org/archive/html/discuss-gnuradio/2020-12/msg00107.html announced] a switch from a Copyright Assignment, which included a CLA, to a [https://github.com/gnuradio/gnuradio/blob/master/DCO.txt Developer Certificate of Origin (DCO)] requirement to contribute.  Since there is no copyright assignment in the DCO, this means that new components of GNU Radio can be upstreamed without copyright assignment. The copyright remains with the author or their company.
+
This boils down to the following instructions:
  
Additional DCO information is included in the GNU Radio [https://github.com/gnuradio/gnuradio/blob/master/CONTRIBUTING.md#dco-signed Contributing Guide].
+
* If you've developed some addition or patch to GNU Radio that you would like to contribute, you should send an email to the mailing list, or to one of the GNU Radio maintainers asking for an appropriate form. We might ask you for some more information at this point.
 +
* You will be sent a short form by email which you should fill in and email back to the FSF.
 +
* Once the FSF have received this email, they will send you a paper copy of the full copyright assignment papers for you to sign and post back to them.
 +
* As soon as the signed paperwork is filed at the FSF we can accept your changes into the source tree.
 +
* Individual small changes (fewer than 10 lines of code) can, however, be accepted without a copyright assignment form on file.
  
You can sign a DCO using the <code>git commit -s</code> command line argument.
+
In order to get the process rolling, please email "tom AT trondeau" for a form to start the copyright process.
  
If you forget to sign a single commit, it can be quickly fixed with <code>git commit --amend --signoff</code>. If you forget to sign a series of commits, the following can be used to go back and sign all commits up until the provided COMMIT_HASH:
+
== Who maintains GNU Radio? ==
  
<code>git rebase --exec 'git commit --amend --no-edit -n -s' -i COMMIT_HASH</code>
+
GNU Radio is currently maintained by:
  
== Who maintains GNU Radio? ==
+
* [https://github.com/bhilburn Ben Hilburn] (Project Lead) and
 +
* [http://corganlabs.com Johnathan Corgan] (Chief Architect) and
 +
* Nathan West (Release Manager) and
 +
* Martin Braun (Community Manager)
 +
 
 +
See also the [[Organization|full list of GNU Radio staff]].
 +
 
 +
GNU Radio was founded and initially maintained by:
  
See [https://www.gnuradio.org/about/organization/ gnuradio organization].
+
* [http://www.comsec.com Eric Blossom]

Please note that all contributions to GNU Radio are considered to be released under the Creative Commons Attribution-ShareAlike (see GNU Radio:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To edit this page, please answer the question that appears below (more info):

Cancel | Editing help (opens in new window)