[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnuradio 3.8 on a Raspberry pi 4 B?

From: Lamar Owen
Subject: Re: Gnuradio 3.8 on a Raspberry pi 4 B?
Date: Mon, 29 Nov 2021 17:44:14 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

On 11/25/21 5:52 PM, Marcus Müller wrote:
Hi Lamar!

I don't want to get into this again, honestly, we have like six or seven threads on this mailing list.


Sorry if I come across as a bit abrasive; that's not the intent. Nor am I wanting to overstate the point, or just continue an unproductive conversation ad nauseum.

It's really that simple: Stillstand and technical and community Death, or Progress and Breakage. It's a balance to strike, which is why with every release, the poor Maintainer goes and looks into their crystal ball, to see what they can improve without breaking the usability on reasonably old systems for the next release. We're really doing our best to *not* let GNU Radio die, so please understand that as much as I personally like what Glen does, it cannot define GNU Radio's speed. ...

Of course it can't define it; not my point.  My point is that a part of release balance is migration planning that allows smooth transitions and upgrades.  I advocated for that for years for another large project that tended to break things every major version; I maintained the RPM packages for that software for five years, and was perpetually caught in the middle between those who developed the software, expecting users to do various 'things' to upgrade from one version to the next and those users who expected 'rpm -U' to Just Work, which it didn't.  So I DO understand and sympathize with the issues on the developer side.  But I also believe that breakage should not happen between incremental versions.  Since GNUradio is built on Python, using the Python model, I expect breakage between Python 2.x and 3.x; I expect rather less breakage between 3.x and 3.(x+1).

That's when as a maintainer, you, responsibly, publicly say that, no, sorry, we're no longer in a position to guarantee the quality of further software releases. ....

I have been in that position; it's not an easy one.  And no you can't guarantee that quality as a volunteer.

So, please, understand that I might get a bit frustrated by people portraying things like we're letting Glen stand out in the rain. Or that we do things "willy-nilly". We don't. We made sure he has migration options, multiple people are and have been offering help, people are actively trying to help him get his airplay running, even though it's a commercial product that's incompatible by its own choice with our software license.

I am familiar with the frustration on both the developers' parts and the users' parts, since I HAVE been caught between.  And no I don't believe you're 'letting Glen stand out in the rain' or doing things 'willy-nilly;' that's reading more into what I wrote than is there.  I am just stating a fact; even the churn that is necessary muddies the waters.  No argument from me that upgrades and progress is necessary; it IS necessary, but what has been lacking (at least the last time I checked; my apologies if this type of document now exists) is a document that outlines the changes required for OOT modules and users programs to migrate from one version to another; better in ways would be a script that can make the edits, although the way of automation is fraught with peril (been there, done that, during the same stint as RPM maintainer).

And YES the SDRplay API is way more closed than I would like.

And I'm not trying to frustrate anyone; but there IS significant volatility in the GNUradio system that can be very frustrating to users.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]