Development: Difference between revisions

From GNU Radio
Jump to navigation Jump to search
(Update development workflow to current practice, remove references to the redmine issue tracker)
 
(10 intermediate revisions by 8 users not shown)
Line 7: Line 7:
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 pull requests and that you have forked the GNU Radio git repo.


* Identify which branch of the GNU Radio base code to work from.
* Identify which branch of the GNU Radio base code to work from. Most of the time, that's main.
* 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 with log messages.
* Provide (an) appropriate Git commit(s) with well-formatted 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 starting branch (i.e., master).
* Issue a pull request against the base branch (i.e., main).
* 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://github.com/gnuradio/gnuradio/issues gnuradio/issues] 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].
* 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].
Line 20: Line 21:


The GNU Radio project maintainers will mark issues as Closed at the appropriate time.
The GNU Radio project maintainers will mark issues as Closed at the appropriate time.
== How can I help? ==
== How can I help? ==


Line 28: Line 30:
* Documentation
* Documentation
* Missing test cases
* Missing test cases
* Report and reproduce bugs
* Bug fixes
* Bug fixes
* GUIs
* Review pull requests
* 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.
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"].


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).
Line 39: Line 43:
== Development Style ==
== Development Style ==


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.
Our coding and development style is codified on [https://github.com/gnuradio/greps/blob/main/grep-0001-coding-guidelines.md GREP1].
 
* 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 master branch and marked for backporting to a maint-X 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 76: Line 55:
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 issue tracker] by following these steps:
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:


1. You'll need to login to GitHub, first, and then click New Issue.<br />
1. If you don't already have one, create an account on GitHub.<br />
2. Provide an appropriate subject to explain the Issue.<br />
2. You'll need to login to GitHub, first, and then click New Issue.<br />
3. 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 />
3. Provide an appropriate subject to explain the Issue (shorter than 72 characters).<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 />


=== I've fixed an Issue! What do I do now? ===
=== I've fixed an Issue! What do I do now? ===
Line 87: Line 67:


1. Fork the [https://github.com/gnuradio/gnuradio GNU Radio project repository] to your personal GitHub development space.<br/>
1. Fork the [https://github.com/gnuradio/gnuradio GNU Radio project repository] to your personal GitHub development space.<br/>
2. Create a new git branch based on master or next and add commits which fix the issue you found.<br/>
2. Create a new git branch based on main or dev-4.0 and add commits which fix the issue you found.<br/>
3. Push the new feature branch to your personal fork of the GNU Radio project repository.<br/>
3. Push the new feature branch to your personal fork of the GNU Radio project repository.<br/>
4. Create a new pull request on GitHub by visiting [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/>
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 (main or dev-4.0) 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 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.
 
== 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 GitHub and then visit the [https://github.com/gnuradio/gnuradio/issues GNU Radio project issue tracker].
 
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 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.
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.


=== Assignment ===
=== Assignment ===
Line 109: Line 80:


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.
#FIXME link to appropriate description how to submit pull requests


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.
Line 130: Line 99:
* 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 158: Line 109:
== Which coding conventions apply? ==
== Which coding conventions apply? ==


All contributions should conform to the [http://www.gnu.org/prep/standards_toc.html GNU Coding Standards] as modified for C++ in README.hacking
See [https://github.com/gnuradio/greps/blob/master/grep-0001-coding-guidelines.md Coding guidelines].
 
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 196: Line 145:


};</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 218: Line 166:
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 Copyright Assignment? ==
== What's this Developer Certificate of Origin (DCO)? ==
 
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.
 
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/main/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.


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.
Additional DCO information is included in the GNU Radio [https://github.com/gnuradio/gnuradio/blob/main/CONTRIBUTING.md#dco-signed Contributing Guide].


This boils down to the following instructions:
You can sign a DCO using the <code>git commit -s</code> command line argument.


* 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.
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:
* 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.


In order to get the process rolling, please email "tom AT trondeau" for a form to start the copyright process.
<code>git rebase --exec 'git commit --amend --no-edit -n -s' -i COMMIT_HASH</code>


== Who maintains GNU Radio? ==
== Who maintains GNU Radio? ==


==== See [https://www.gnuradio.org/about/organization/ www.gnuradio.org/about/organization]====
See [https://www.gnuradio.org/org/organization/ gnuradio organization].

Latest revision as of 00:42, 25 November 2023

Contributing to GNU Radio -- FAQ

GNU Radio is an Open Source project, and as such contributions from the community are welcome. If you have some code or other things such as documentation you would like to share with the rest, please have a look at this FAQ before submitting.

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.

  • Identify which branch of the GNU Radio base code to work from. Most of the time, that's main.
  • Create a new branch from here to work from.
  • Work on the bug fix or feature under the new branch.
  • Determine the QA code necessary to test and check the fix or feature.
  • Provide (an) appropriate Git commit(s) with well-formatted log messages.
  • Push the branch to a public repo on Github.
  • Issue a pull request against the base branch (i.e., main).
  • 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 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 GitHub's automatic issue closing.
  • 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.

The GNU Radio project maintainers will mark issues as Closed at the appropriate time.

How can I help?

The easiest way to help is to simply use GNU Radio. The more you use it, the more likely you will perhaps find a bug, or miss a particular feature. Tell us about it on the mailing list, or, even better, fix it yourself and submit the code. The most rewarding way to go is probably to actually write a radio system, e.g. a receiver for a digital standard.

If you want to get involved in the development process, here's some suggestions where to start:

  • Documentation
  • Missing test cases
  • Report and reproduce bugs
  • Bug fixes
  • Review pull requests
  • 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 "good first issue".

We also use Coverity for static code analysis. You can find our project at [1]. 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 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.

Development Style

Our coding and development style is codified on GREP1.

Quality Assurance (QA) Code

Every block should have a QA file to test the validity of the code. Most current blocks have QA code that tests that the code runs and produces repeatable, testable results on all platforms. If this code fails, it is an indication of a problem, error, or unexpected change in the code. It is an easy way to verify the validity of the code. This can be a difficult concept in some signal processing codes (such as a phase lock loop that has to settle), but the current QA tests that are there can offer guidance and hints as to how to test a new block.

Any block that is currently without a QA testing program should be fixed to have one.

I've found a bug, but I don't have the skill/time/whatever to fix it... now what?

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 GNU Radio issue tracker by following these steps:

1. If you don't already have one, create an account on GitHub.
2. You'll need to login to GitHub, first, and then click New Issue.
3. Provide an appropriate subject to explain the Issue (shorter than 72 characters).
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.

I've fixed an Issue! What do I do now?

That's fantastic! Thanks! To help us provide a consistent experience resolving and fixing issues, please follow these steps.

1. Fork the GNU Radio project repository to your personal GitHub development space.
2. Create a new git branch based on main or dev-4.0 and add commits which fix the issue you found.
3. Push the new feature branch to your personal fork of the GNU Radio project repository.
4. Create a new pull request on GitHub by visiting the GNU Radio pull request page and clicking New pull request, then select the appropriate base branch in the GNU Radio project (main or dev-4.0) and select your feature branch to compare with from your personal fork .

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.

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.

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.

If you're having any trouble with this, don't hesitate to ask on the mailing list.

Which kind of patches are accepted into GNU Radio?

There is no definitive answer to this. Bug fixes and missing QA codes are of course always welcome.

Ultimately, the decision lies with the maintainers. If in doubt, consult the mailing list.

How long does it take for my patch to become part of GNU Radio?

Again, there is no definitive answer to this. It depends on many things: the complexity and size of the patch, the current situation of development and the relevance of the patch.

However, the following things are guaranteed to delay acceptance:

What's this CGRAN?

The Comprehensive GNU Radio Archive Network (CGRAN) is a free open source repository for 3rd party GNU Radio applications that are not officially supported by the GNU Radio project. In other words, it is a place for anybody to upload and publish extensions and modifications of and for GNU Radio.

If you are developing a GNU Radio project which works separately from the GNU Radio core, you might want to submit it to CGRAN rather than to the GNU Radio core. This way, you keep the write access to your published code and can maintain it independently from the core.

Which coding conventions apply?

See Coding guidelines.

How is the code documented?

GNU Radio uses Doxygen to document the source code. Any new block should use Doxygen markup structure to add to the Doxygen manual. Also, we use a list of groups to categorize all of the blocks, so when a new block is created, add this block to one or more of the available groups, a list of which can be found in docs/doxygen/other/group_defs.dox. Below is an example of a marked-up header file.

/*!
 * \brief A new block that does something.
 * \ingroup some_group
 * \ingroup another_group
 *
 * Detailed description of what this block does.
 * Quoting papers or textbooks is a good idea, too.
 */
class MODNAME_API new_block : public gr::block
{
 private:
  new_block(int param1, double param2);

 public:
  typedef boost::shared_ptr sptr;

  /*!
   * \brief Description of public_function()
   * \param foo Describe foo
   * \param bar Describe bar
   */
  virtual int public_function(int foo, float bar) = 0;

  /*!
   * \param param1 Describe param1
   * \param param2 Describe param2
   */
  static sptr make(int param1, double param2);

};

The top level blocks are all described inside that blocks doc directory in a .dox files named or the component. For example, in the component gr-digital, the manual page describing this component is in gr-digital/doc/digital.dox. 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 component's doc directory will also contain a README.package that gives a brief description of the package. This file should contain the most basic necessary information and point to the Doxygen files for more detail.

Doxygen Markup for Formulas

When inserting formulas into the header to be part of the documentation, we want to have the best representation possible, which means making Latex style formulas. This is done in Doxygen using the "\f{" to begin and "\f}" to end the formula section. However, these do not properly show up in the XML documents used in the Python help files. So we have to make the formula twice, once formatted for the HTML manual and another for the XML. It will look like this:

This is some text in the header...
\f{html}{
enter Latex formula here -> will only show up in the HTML document.
}

\xmlonly
Same Latex formula, but this will not be processed; will only be the raw Latex formula.
\endxmlonly

And here's some following text to the formulas.

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)?

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.

At the end of 2020, GNU Radio announced a switch from a Copyright Assignment, which included a CLA, to a 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.

Additional DCO information is included in the GNU Radio Contributing Guide.

You can sign a DCO using the git commit -s command line argument.

If you forget to sign a single commit, it can be quickly fixed with git commit --amend --signoff. 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:

git rebase --exec 'git commit --amend --no-edit -n -s' -i COMMIT_HASH

Who maintains GNU Radio?

See gnuradio organization.