Issues & Pull Requests
Issues & Pull Requests
Attendee count (max): 22
UTC0054 - Plane update
UTC0055 - Copter update
UTC0056 - tradheli update
UTC0057 - Rover update
UTC0057 - release strategy
UTC011 - no Copter 4.2 beta release yet
UTC0027 - Conference
UTC0028 - links to diydrones?
UTC0032 - partners call tomorrow
UTC0032 - close
An observation from my somewhat brief time as a bleeding edge user of ArduPilot (probably skewed by some misperceptions):
Development seems to have ramped up significantly over the past year. Between September 2021 and present, there have been 7 major and minor releases, where in the 6 months preceding, there were zero, and prior to that (when I was testing and using moving baseline for Rover), development almost seemed stalled at times.
When releases were spaced farther apart, there was more time for beta testers to respond, and the changes were more significant, likely increasing motivation to test and try something new.
A few of the recent 4.1.x releases and release candidates have included bug fixes that were targeted to very specific audiences (many hardware specific), so it could be expected that feedback should be minimal.
In my own case, once 4.1.0-stable was released, I began to focus on 4.2-dev, specifically testing the Rover S-Curve branch. I continue to use 4.1.x on vehicles that are not my primary focus, and nearly all of the release candidates have included fixes for things I cannot specifically test.
EDIT: Reply count alone probably is not the best metric for determining beta tester engagement. A single reply can often be proof positive that a fix was successful or not, while many of the release topics include unrelated, drawn out discussion from new users needing help.
The pace of development has been refreshingly rapid lately, and as such, beta testers are probably less motivated to test minor bug fix releases while awaiting the “next big thing.” Perhaps victims of your own success!
The fixes? I’m not sure, but two suggestions above stand out to me:
I have always been quite happy with Randy’s direct feedback regarding testing, but other devs are less engaged here, which may be off-putting to some testers who may feel undervalued. More tester/dev engagement would likely be very welcome, including specifically asking individuals at times for their help in field testing features/fixes specific to their known hardware configs (perhaps that doesn’t scale well, but it does solve a near term need).
I think there could be a few things that could be done to streamline beta testing, first thing would be to get a list of beta testes and their hardware available for testing, that way if something new needs tested it’s not just left to chance, there will be a good odds someone that we know has the hardware that can asked to test it. It would also help with issues found on the forum where bugs are regularly discovered but end up difficult to diagnose without having another one to verify the results. Receivers, ESC and servo incompatibilities are seen regularly and it becomes difficult to determine if it’s an incompatibility or a bug.
If known beta testers don’t have the hardware put up on a front page notice somewhere with a list what the new hardware or features are that currently needs beta tested, very few people look at release notes.
If something has been confirmed working, it should be documented how it was tested and on what setup with what version of ardupilot so its much easier to replicate a known working specific hardware and software combination down the road to help with troubleshooting without spending hours searching through forum posts.