Hello,

Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This
patch simply creates distinct MODELs for each of the supported VX-8
variants and removes the VARIANT constant for each of the radio classes.
The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and
VX-8GE. Also attached are test image files for each of the three radios. Running
"run-tests" for each of the radios yields all PASSED except for the VX-8R which
yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL
with 624 PASSED and 111 SKIPPED.

The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img
reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT].img
since the "R" variant was subsumed into the model.

Cheers,

Keith
KF7DRV




On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel <chirp_devel@intrepid.danplanet.com> wrote:
> OK cool. In that case, I'll leave the bug fix as is and make that
> the first patch. The goal of the first patch is simply to ensure that
> if you download from a VX-8R, you don't generate trace back errors
> and you don't get a Settings menu at all. In other words, ensure that
> the correct code gets called for a given variant.

Yeah, good plan.

> On an administrative note, should we just reject Issue 4881 and have
> me create a new issue with the scope of work limited to the bug fix?

It's up to you, but I don't think you need to close it. You could call
all of your patches "groundwork" for getting to 4881, or open a new bug
for the correctness (i.e. fixing the tracebacks) and then any refactors
are mostly groundwork for the end goal of settings support for the base
driver.

But, your call as you're doing the work. I just granted you permissions
to monkey with the issues, so you can close/create/link as you see fit.

Thanks!