Re: Gnuradio 3.8 on a Raspberry pi 4 B?

[Lamar Owen]

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.
> ....


Marcus,


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.