greps
greps copied to clipboard
gnuradio
0002: Upstreaming
@noc0lour Yes, discussion is definitely open.
@mbr0wn I'll have to fix this template, it does lose its number as per our process, right?
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 :wink:
I'm going to rework this tomorrow noon.
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 :+1:
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:
- in which way specifically is the document lacking a guideline when to upstream and when not to?
- how would you approach describing the process of "keeping things maintainable once upstreamed"? To me it's writing tests at the time of upstreaming, and keeping those tests running when evolving the project. Is there something higher-level to it that I'm missing (honest question from a newbie maintainer)?
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:
- how should your code/contribution look like (abstract/high-level)
- which tools to use
- timeline/steps to take (e.g. CLA signing)
- where to ask for help
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] ?).
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.