On "Profiteering" and Free Software

[K4ED]

Even the current Beta has a few bugs which I found 2 days ago, one of which precludes it from ever being marked as stable.
I know the last "stable" version also had a load of bugs, but I was not keeping track so well back then.

Understood. Any recommendations on how I would know if any particular pre-release is more, or less stable than the previous ones?

I have the last "release" on the gd77, from October ... Now looking for the nest better version since then ... and going forward .. looking to keep a fairly "stable" version with "Stable" being defined as no killer bugs and a positive ratio of features to bugs

[VK3KYY]

All the releases with large numbers of downloads must be relatively stable, otherwise I'd have a lot of people complaining.

Any release with very low numbers of downloads, or when there has been a second update on the same day, is likely to have problems.

I try to keep the Betas as stable as possible,but there have been multiple occasions where there have been problems.


Because there are only 2 levels of version available to me on the GitHub storage, (either "Pre-Release" which I label as a Beta, and "Release" which I label as release"), its difficult for me.

Normally projects have at least 3 levels of releases.

Stable , Latest / Beta , and "Nightly"

But I don't have the option to mark something as a Nightly

People have suggested I do automated builds and make these available, but this would be problematic, because just the other day, I did something which worked fine on my radio, and also on 2 other Beta testers radios, but another Beta tester had serious problems and his radio hung and would not turn off, and he had to remove the battery and then plug the battery back in whilst holding down the buttons to allow him to reload the older firmware

I can't risk putting those versions out by accident, because of automated "Nightly" builds.

In fact with the change that caused this problem, I'm going to need to post an experimental release for anyone willing to take the risk, as a completely separate download from a file on my Google drive

Edit..

e.g.

viewtopic.php?f=7&t=1487&p=13069#p13069

[K4ED]

I think I found my answer, at least for now, in another forum where it was mentioned that the 01/19/2021 firmware release was “one of the more stable and bug free versions."

That gives me a solid target to move forward from the Oct. 15th version with today and your advise to watch for download numbers gives me go forward advice.

I don't know git that well ... but is there an option to number the releases beyond their date? I was thinking of the numbering system we use at work, where odd numbered minor releases are "new features" and even numbered minor releases are "no new features, just bug fixes."

Could you do something similar to indicate if a particular release's focus is new features, or stability and bug fixes?

Or, I guess, I could just you know, read the text for each release and figure that out for myself.

[VK3KYY]

I think I found my answer, at least for now, in another forum where it was mentioned that the 01/19/2021 firmware release was “one of the more stable and bug free versions."

That gives me a solid target to move forward from the Oct. 15th version with today and your advise to watch for download numbers gives me go forward advice.

I don't know git that well ... but is there an option to number the releases beyond their date? I was thinking of the numbering system we use at work, where odd numbered minor releases are "new features" and even numbered minor releases are "no new features, just bug fixes."

Could you do something similar to indicate if a particular release's focus is new features, or stability and bug fixes?

Or, I guess, I could just you know, read the text for each release and figure that out for myself.

Things are done ad-hock when we get bug reports, or when the developer, Daniel F1RMB, sends an update.

There is no project program or focus on either features or bug fixes

[OK1TE]

People have suggested I do automated builds and make these available, but this would be problematic, because just the other day, I did something which worked fine on my radio, and also on 2 other Beta testers radios, but another Beta tester had serious problems and his radio hung and would not turn off, and he had to remove the battery and then plug the battery back in whilst holding down the buttons to allow him to reload the older firmware

That's interesting. Please, what usually causes this different behavior on relatively same HW? And how do you debug that? Seems to be a hard nut...

[VK3KYY]

People have suggested I do automated builds and make these available, but this would be problematic, because just the other day, I did something which worked fine on my radio, and also on 2 other Beta testers radios, but another Beta tester had serious problems and his radio hung and would not turn off, and he had to remove the battery and then plug the battery back in whilst holding down the buttons to allow him to reload the older firmware

That's interesting. Please, what usually causes this different behavior on relatively same HW? And how do you debug that? Seems to be a hard nut...

Older radios had older or different memory chips in them.

Both the EEPROM and Flash chips were different.

I think the CPU and the DMR chip have always been the same.

Possibly the RF chip may be an older version in some very old radios , RDA1846 rather than AT1846S

[DU2XXR]

I was supposed this reply to this thread, but somehow it went somewhere else:

Last week, I helped a fellow ham program channels on his openDM1801 radio (plus updating the firmware) and TYT MD390. We spent around 4 hours, since programming talkgroups on the TYT was a big headache--and that's using text-based .conf editing on dmrconfig (but first using the very slow TYT CPS GUI and then doing copy-paste afterward).

He bought me and my kids a bucket of fried chicken for dinner. We're both happy.

I'm not sure what you are trying to say here.

What has helping someone with their codeplug and there MD390 to do with the companies who were charging far more than a price of a bucket of chicken, for the radio if people chose to have the brand new radio with the OpenGD77 firmware.
Or the people who seemed to be selling the firmware as a digital download, to people who didn't know it was free?

I guess I was just making a comment about the thin line between "commercialization" of something that is otherwise supposedly free, and a friendly service done for a fellow ham.

If done in the spirit of service and a helping hand, then if the other person reciprocates with something of value (maybe a coffee, beer, or a bucket of chicken, etc.) I think it's generally OK. But if it's "selling" it as an add-on service, well, it might be something different altogether.

I mean, I would've done it for my friend for free, but since he offered dinner, then OK.

Do you think it would also be ok if a friend or fellow ham, say, offered to compensate with something of value or even monetary compensation for the time spent?

Thoughts?

[VK3KYY]

Yep

Its a fine line between a company charging $50 to pre-install the firmware, versus you spending a long time personally with someone, only to receive a smaller amount as a non-financial transaction.

[dl9sec]

Hi,

This post (bottom) should answer your question:

viewtopic.php?f=3&t=1388#p12302

73, Thorsten

[OK1TE]

This post (bottom) should answer your question:

viewtopic.php?f=3&t=1388#p12302

Hi,
the sentence you declare to answer the questions ends with "if that happens", so I think it doesn't answer it fully...
I in different posts Roger writes about different reasons for not publishing the code temporarily.

We all are so much looking forward to this temporary period ends.