Thank you so much for hanging in there. The new shop took about two weeks to bring up. I’ve been keeping an eye on the forum and assembled a todo list for this week.
I’m going to ease back into firmware by messing with image loading, and then move on to the PulseView issue on SDK2.0 which may be a very nasty bug that requires hacking the SDK (hope not!).
May I suggest at least the firmware issues be tracked as GitHub issues? This will let people see features that are being considered, provides searchable history of issue, etc.
more thoughts ...
There’s a possibility that some of the firmware issues are resolved by recent PRs by @phdussud or myself, and we can link the issues to the PRs that should have fixed a given problem more easily that way.
Also, by using GitHub, folks have visibility into what issues may exist in the current main branch / head. If you later want to target milestones / releases, we can also allocate issues (esp. enhancements) to those milestones, again with instant visibility to the community.
More importantly, issues can be assigned to volunteers: helping to lighten your load and increasing participation, while avoiding overlapping workstreams. Example: Adding RTT – people are REALLY passionate about this feature … and for good reason. If someone can generate a PR for this before you could get to it, then everyone wins!
You’re right, that is the right way to go. The project has progressed beyond a single developer and those tools keep everyone sane. I’m going to be asocial for just a bit longer though, I want to get through a couple emergency items.
This is my focus today, as well as getting @phdussud’s new pulseview teaser hosted somewhere.
Also not on the list: @dreg’s pull request for binmode documentation, and my own binmode documentation. Tomorrow is reserved for editing and illustrating the binmode docs.