Consultation for dropping maintainance of maint-3.9 and maint-3.8 branches

[daniestevez]

I'm opening this discussion to ask the community whether they are still using the maint-3.9 or maint-3.8 branches of gr-satellites and what would be the impact of stopping to maintain these branches.

The motivation for this discussion is that having to support GNU Radio 3.9 and GNU Radio 3.8 introduces additional maintainer burden and limits us in the ways in which we can evolve gr-satellites. We cannot use more modern C++ features, since they are not available in old systems in which GNU Radio 3.8 usually runs (e.g., Ubuntu 20.04), and we need to be very careful when adding new functionality to gr-satellites. If this functionality uses blocks or features which are not present in GNU Radio 3.8, it will be more difficult to backport it. As more blocks get added to GNU Radio 3.10, the chances of this happening increase.

An recent example of this issues comes with the new Mobitex-NX Deframer implemented by @kerel-fs (#723). I have been able to port it to maint-3.9 in a straightforward way (#736), but for maint-3.8 I'm facing problems, since the Matrix Interleaver block is not available in the GNU Radio 3.8.1 version that ships with Ubuntu 20.04 (#737).

[kerel-fs]

Yes, with regards to SatNOGS, the existing integration via kng/satnogs-client-docker is still using the maint-3.8 branch.

Yesterday I've opened the discussion to solve the need of SatNOGS for the maint-3.8 branch in

• satnogs-org#265 - Support migration of kng/satnogs-client-docker (comment) and
• satnogs-org#264 - Officially support the (optional) gr-satellites integration.

To summarize the roadmap:

• gr-satellites is pre-installed in the base image used by satnogs-client (Debian package, built by OBS for the SatNOGS package repository).
• The latest master branch of satnogs-client is using GNU Radio 3.10 (merged 5 days ago)
• the existing integration, which is using a pre-/post-observation script grsats.py to start & stop gr-satellites, could easily be upstreamed (satnogs-client#493)

Otherwise I am not a user of the backported branches of gr-satellites. As contributor (and with the SatNOGS integration solved) I would welcome the eventual removal of the maint-3.8 and maint-3.9 branches, which makes it easier to develop for gr-satellites.

[daniestevez]

It seems that getting SatNOGS integration working with gr-satellites main / maint-3.10 is an important thing to do before dropping support for maint-3.8. Since this is already in progress, I think it is fair to define this milestone as the point where gr-satellites support for maint-3.8 and maint-3.9 will stop. I'll wait to hear more feedback from the community before making a final decision, but at this moment this approach seems reasonable to me.

[K4KDR]

First, thank you for maintaining the older branches for as long as you have!

My reasons for continuing to use v3.8 are:

#1, the computer where it is installed is running Ubuntu 18.04

#2, there are (or 'were'???) particular satellite downlinks that required compatibility with v3.8. I can't name any examples off-hand and have no idea if that continues to be the case.

However, I'm certainly aware that it's unfair & often not wise to continue using old versions of applications. So, when the day comes, I'll simply replace this computer with one running the latest version of Ubuntu.

-Scott, K4KDR

[daniestevez]

Probably it is a good idea to update your Ubuntu 18.04 to something like Ubuntu 24.04 at some point. Ubuntu 18.04 doesn't receive security updates since 2023 (unless you have the paid Ubuntu pro plan), and Ubuntu and free software in general has improved much in the 6 years difference between 18.04 and 24.04. This said, you could maybe even run GNU Radio 3.10 inside an Ubuntu 24.04 Docker in your Ubuntu 18.04.

It is true that for a long time, decoders that needed the BEESAT tnc_nx couldn't run on GNU Radio >= 3.9 because of #238. This has been fixed now, since @kerel-fs wrote a Mobitex-NX deframer from scratch for gr-satellites. This is available both in the main branch and maint-3.9.

[kng]

First, a big thank you for maintaining these for way too long.
Just do it, way overdue to be honest. Anyone can keep using the current releases, it's just frozen in time.

[N6RFM]

Hi Dani,

For such a long time you've most graciously maintained gr-satellites support for legacy GNU Radio 3.8 and 3.9, along side of the more contemporary 3.10. Given the inherent complexity of those tasks on your end, and the continued evolution of GNU radio, I would advise you lock the earlier versions and focus on 3.10 moving forward until something even better comes along. For example, this may buy you back some discretionary time to consider the ramifications to gr-satellites of when GNU Radio 4.0 comes on-line. Like it or not, one day we will have to adapt. IMO it's simply a matter of when not if.

As an aside, I have multiple independently bootable SSDs for 3.8, 3.9 and 3.10 installed in my desktop. Notably, it has been several years since i have used gr-satellites under any version of GNU Radio other than 3.10. One recent transient exception was when the Harbin ASRTU-1 project team provided a working legacy OS image. Even then, mostly with BG2BHC and K4KDR, work was undertaken to assure that gr-satellites/3.10 could be used instead.

Thanks a million for everything you have and continue to do to support our community and for teaching us so much along the way!

73,
Bob
N6RFM