Dear GNU Radio community, ----------------------------------------------------------------------- Tl;dr: Feature freeze coming up, please help categorizing issues and fixing unit tests using our project boards. General excitement. -----------------------------------------------------------------------
as we've now closed a lot of the severe issues that GNU Radio had right after we've tried to bring it to the present (meaning enabling Python 3, porting to Qt5), and adding a lot of cool new features (we're close to finally merging Håkon's awesome C++ generation code), we're now working on squashing the remaining bugs and really narrowing all the things down that need to be done before we release something that really deserves the Tag 3.8.0.0. So, in order to do that, I'm defining the feature freeze for 3.8.0.0 to happen on the tenth of January 2019. That means that all features and feature requests after that won't be part of that release, but of course, won't be forgotten; it's just that we'll then have reached a state where we must avoid scope creep for this specific release. Nothing says your feature can't be in 3.8.1! Also, just because a feature is on the list by the 2018-01-10 doesn't mean it's already implemented. It means we – as a project – commit to putting it into the release. In the meantime we do our best to categorize the many outstanding issues we have. What we're doing there is pretty classical (implemented with the tools that Github gives us): If you go to https://github.com/gnuradio/gnuradio/projects/1 you'll find four categories, from "To Do" over "In Progress" to "Done". "Contested" is for issues that we initially added to the "must haves" for 3.8, but warrant that we reconsider whether actually necessary for 3.8.0.0 (or just additional complication). All the things in "To Do" deserve attention; if you happen to have spare time, don't hesitate to pick any one of these. These are definitely up for grabs! So, if you feel like you can contribute anything, especially commentary on demand and use cases, and of course we'd love code, for any of the feature-issues, go ahead! If you don't have the permissions to move the issue from the "To Do" to the "In Progress" category, give us (me) a nudge. We'll get this thing rolling! Another thing I want to draw attention to in this context: There's a special, analogously operating board, "Meaningful QA", on https://github.com/gnuradio/gnuradio/projects/3 There's a serious problem: whilst we've become a lot better than we used to be at covering more and more of our code with test cases, there's still quite a few tests that simply fail, for no reason that we could easily see. These partially touch on very specific topics, but partially really frighten me. So, if you have spare cycles, run one or two of these test cases a couple of times (many include infos on how to trigger), and report success or failure together with your architecture. So, as you can see, we're getting excitingly close to actually putting out a cool new version of GNU Radio! Best regards, Marcus _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
