AnyTone-D868UV VS github

My most starred repo has no code in it too!

A few years ago I bought an AnyTone AT-D868UV ham radio. As with any software-managed device, there were a few issues. I wanted a place to keep track of these problems for my own purposes. So I thought "GitHub Issues!"

https://github.com/geary/AnyTone-D868UV

I added a couple dozen of the problems I'd run into. And then it took a life of its own. Some people thought it was an official AnyTone support channel (despite my disclaimer). That's bound to happen.

The fun part was when people started an issue on how to upgrade a D868UV to a D878UV.

https://github.com/geary/AnyTone-D868UV/issues/59

Of course this was kind of an insane project unless you look at it from the point of a ham operator: radio hacking is fun!

Now about the gloves and chili.

Around 1974 I decided to stir fry a very hot dish of chiles and eggplant.

I didn't use any gloves, nor the fume hood that would have been wise.

Midway through the stir fry I noticed my forehead was burning.

But I ate the dish and it was delicious.

The next morning I woke up and my fingers were numb!

I went into survival mode and quickly realized that what I needed to do was eat a lot of yogurt, right then and there.

And it worked. I still have my fingers!

I am embarrassed to admit that my most popular GitHub repo is an issues-only tracker for something I didn't even create: a popular handheld ham radio, the AnyTone AT-D868UV/AT-D878UV.

After I bought my radio, I found a few firmware issues and looked for a way to communicate them to the manufacturer. No luck on that. There was an active Facebook group, but it is a weird place run by a radio dealer who would ban you for discussing anything he thought might interfere with his business.

So I made a repo and started adding issues for the things I'd noticed. People found it and it took on a life of its own. The most popular issue is a lengthy collaboration among several hams who worked out a way to update the firmware on the D868UV to convert it to a D878UV.

This was one of the topics that would get you banned on that Facebook group, as the group owner would rather sell you a new radio. The funny part about that is the upgrade involves buying a special programming board and considerable time and effort, plus the risk of ruining your radio. So it was really just a labor of love for a few hams who had a blast working out how to do the upgrade.

Hams may not build our own radios as much as we used to, but we can still hack the firmware!

https://github.com/geary/AnyTone-D868UV

thanks yea. it's been a while, but according to another recent comment on the github

While looking for solutions, I realized that many developers face similar challenges. This issue is widely discussed, particularly in a GitHub thread: Track traffic to GitHub repo longer than 14 days #399.

Probably the older email address is still the primary one for the GitHub account.

GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See <https://github.com/isaacs/github/issues/1368> for the tedious details.

Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they will set noreply@github as the committer so that they can sign the merged commit themselves, and set author name & email to what they have recorded for the GH account involved (and the signature is then a record that GH have verified that account's involvement).

Personally I think it is shocking that they ignore the name and email address that the actual author of the commit has selected. This is both a violation of the author's intentions -- for example, you may set work and personal email addresses in different repositories as discussed here, but GitHub will rewrite them all to the same thing when other people press "Squash and Merge" on your pull requests -- and potentially a doxxing security risk.

I have considered re-reporting this to GitHub via the newer community discussions or via support again, but given the extent to which they've ignored all such reports over the last five years it is hard to find the motivation to do so.

However, there is a massive issue. Github by default truncates insights to t-14 days (where t = today). This is super annoying as there is a discontinuity in data. There is also an archived issue on Github regarding this. The issue has a whopping 119 comments and has been around for over 8 years now. Basically, from the discussions there - Data you don't persist today will be gone 14 days from now. And looks like Github hasn't done anything about it.

> Hi, people have made money using my code and I also don’t care

looks like everyone's missing the point.

> I understand this is upsetting to you

Again, maybe I am on another level of comprehension, so I don't understanda why it is so hard for someone to get it, but I am not upset by that, at all.

I simply know that those who think "it will be fine" are delusional and don't know what they are talking about!

So I just will paste some link to relevant news here, maybe it will make things clearer.

It includes the opinion of Antirez, father of one of the most successful OSS ever: Redis. Maybe his words will open your eyes and tear the veil of Maya.

(spoiler ahead alert!)

Basically you work for free and people don't even thank you and the maintainer ends up being doxed or blamed or pushed aside and in the long term the only solution to keep sanity is to resign

https://www.jeffgeerling.com/blog/2022/burden-open-source-ma...

https://www.theregister.com/2022/01/13/opensource_apacheplc4...

https://nolanlawson.com/2017/03/05/what-it-feels-like-to-be-...

https://old.reddit.com/r/linux/comments/z14tt2/reason_why_op...

https://github.com/isaacs/github/issues/167

http://web.archive.org/web/20221217180915/http://antirez.com...

I don't know what the fuss is all about. It was publicly known that Github was breaking automatic git archives consistency for many years. Here is a bug on a project to stop relying on fake github archives (as opposed to stable git-archive(1)):

https://bugzilla.tianocore.org/show_bug.cgi?id=3099

At some point it was impossible to go a few weeks (or even days) without a github archive change (depending on which part of the "CDN" you hit), I guess they must have stabilized it at some point. Here is an old issue before GitHub had a community issue tracker:

https://github.com/isaacs/github/issues/1483

Hello, I see you stepped on my favourite personal soapbox! :)

https://github.com/isaacs/github/issues/1017

I really, really like semi-linear branching/merging. I.e. always rebase-merging, but with a merge commit.

Reasons, in comparison to Github's "rebase merge" which doesn't produce a merge commit:

1. It makes it clear which commits were part of one PR

2. It makes it clear who did the merge

3. It's okay to not have every commit build. but the one being merged will.

4. Still pretty bisectable. You'll narrow things down at least to the PR that caused an issue, and from there it's usually quite simple.

5. Looks very tidy in gitk & Co

Not to say that the feature isn't coming to FOSS git services.. Just that even proprietary organizations have had issues with taking a while to implement them.

Oh this is cool actually! Nice! One of the grievances I have with github commit signing is this issue https://github.com/isaacs/github/issues/1099

In addition, you probably want to read this discussion. https://github.com/isaacs/github/issues/1138