Hi all, In case you didn't know: Like many other free software projects, we have a process for communicating major changes to GNU Radio early, using what we call GNU Radio Enhancement Proposals (GREPs). We manage GREPs in a git repository:
https://github.com/gnuradio/greps The purpose of GREPs is manifold, but the main reasons for having them are: - They give us the ability to communicate early what we plan to do, so everyone can be involved soon, and is less surprised by what's coming - They 3rd-party developers the option to communicate their intent upstream before submitting the code. Every maintainer dreads the many-thousands-of-lines pull requests they hadn't heard before. - They give us a platform to discuss changes with our users before we start making decisions in private. For us maintainers, the year 2018 was all about getting 3.8 done, with all that it entailed: Removing Cheetah to enable Python 3, fighting SWIG to enable Python 3, replacing Qt4 with Qt5, improving the CI system... lots of stuff that was frankly a pain the rear and not the most entertaining. Now while 3.8 is not quite finished (see our other emails on the release planning), we feel like we're on the home stretch now. Which means, it's time to think about other changes to modernize GNU Radio and keep it relevant, modern, and powerful. In the last 6 months, I've had many conversations with developers within and around the GNU Radio community, and there's a lot of things that people want to happen. Heterogeneous computing, better streaming performance, ... there's so much we could do. To create a solid base for all of this, I've submitted four GREPs that have fallen out of various conversations. They are all in "Draft" stage, which means they're totally open for debate. We could decide to not implement any of those, but then at least we'll have come to that conclusion in a constructive fashion, and it will be documented in the GREPs system. Here they are: GREP 13: Remove log4cpp GREP 14: Create blocktool, a header parsing library for GR blocks GREP 15: Remove SWIG and replace it with ??? GREP 16: Separate the scheduler and the base GNU Radio components into separate in-tree modules to make the scheduler pluggable This thread is not a great place to discuss them, I'll start another thread for each one here. Cheers, Martin
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
