0002: Upstreaming #2
Conversation
|
We're not yet accepting PRs on this repo. |
|
Is this PR actually up for discussion right now? |
|
As per GREP0, you and I pick a number when we merge. That said, we said we wanted to reserve a number space for (0-9) for "special" GREPs, and this might qualify. |
|
This one probably needs some rework since it predates the inauguration of the offical GREP process by a year. |
|
Yes, being ahead of time is what GNU Radio Maintainers do 😉 I'm going to rework this tomorrow noon. |
This not only includes replacing all occurences of GRIPE by GREP, but also adopting the GREP process as preferred way of bringing in substantial change to the environment.
marcusmueller
force-pushed
the
0002-upstreaming
branch
from
47e1818
to
09bd636
Compare
|
Reworked. |
|
|
||
| ## Copyright / License | ||
|
|
||
| [WTFPL](http://www.wtfpl.net/txt/copying/) Version 2 or later |
There was a problem hiding this comment.
Every open source lawyer will tell you this is not a license. Please choose something more approriate.
There was a problem hiding this comment.
https://www.gnu.org/licenses/license-list.html#WTFPL it's not recommended by the FSF, but recognized. I frankly think that the spirit of the WTFPL fully applies to this document, and thus I'd very much like to keep that license.
|
The second half of this document are generic contribution instructions. @noc0lour has also brought up such a document, plus, there's an outdated wiki page on contributing (https://wiki.gnuradio.org/index.php/Development). How about this: We make the sure the contribution info is up to date (maybe turn it into a GREP, too). That should include all the mechanics (forking, CLAs...). Then we can focus on a document that says "when do I upstream my block vs keeping it in my OOT". For the latter case, this document lacks some details on how it stays maintainable once upstreamed. Unit tests are nice, but we should also work on ways to have higher-level tests. That remains TBD. |
|
not quite sure what document of @noc0lour you're referring to here, but I'd very much like to read it in that case 👍 I think the part about "when to upstream and when to keep in OOT" is indeed expandable, but I do see a clear checklist – I intended this GREP to be exactly the document that defines that, so I'm happy to see that you agree we need something like that. I'm not quite sure what to make of your criticism here:
|
|
I was just referring in some chats that I'd very much like to write a technical "Contributors"-Guide once we are done with formatting and dev-model changing. I'm in for writing a the technical part explaining:
This should help kickstart new contributors and reduce the load of questions we already have an clear, but hard to find, answer. Re tests: We should try separating unit tests, integration tests (how well to certain modules play nice together?) and system tests (Is a full transceiver still working [with HW] ?). |
|
|
||
| GNU Radio calls itself the "Free and Open Software Radio Ecosystem". We're not | ||
| doing that bad with ecosystem size, but the code quality in Out-Of-Tree Modules | ||
| (OOTs) is very varying, and with every release, we risk serious bitrot, since |
| ### Upstreaming Process | ||
|
|
||
| 1. The party interested in upstreaming MUST integrate their changes into a fork | ||
| of GNU Radio on a publicly available git repository (classically: Github), |
|
I'd rather not specify the technical side of "How to contribute" in a GREP but in a Contributor's Guide (e.g. in the wiki) and reference it from README.md. |
No description provided.