<div dir="ltr"><div><div><div><div><div><div><div>Hello,<br><br></div>Attached is patch "vx8-4883.patch" which resolves bug issue #4883. This <br>patch simply creates distinct MODELs for each of the supported VX-8 <br></div>variants and removes the VARIANT constant for each of the radio classes.<br></div>The result is new Yaesu radio drop down selections for VX-8R, VX-8DR, and <br></div>VX-8GE. Also attached are test image files for each of the three radios. Running <br></div>"run-tests" for each of the radios yields all PASSED except for the VX-8R which<br></div>yields SKIPPED for the Settings test. Running a full "run-tests" shows 735 TOTAL<br></div><div>with 624 PASSED and 111 SKIPPED. <br><br></div><div>The tests/images file Yaesu_VX-8_R.img is replaced by identical file Yaesu_VX-8R.img<br></div><div>reflecting the assumed naming convention of MANUFACTURER_MODEL[_VARIANT].img<br></div><div>since the "R" variant was subsumed into the model. <br></div><div><br></div><div>Cheers,<br><br></div><div>Keith<br></div><div>KF7DRV<br></div><div><br><br></div><div><div><div><div><div><div><br></div></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 5, 2017 at 1:49 PM, Dan Smith via chirp_devel <span dir="ltr"><<a href="mailto:chirp_devel@intrepid.danplanet.com" target="_blank">chirp_devel@intrepid.danplanet.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> OK cool. In that case, I'll leave the bug fix as is and make that<br>
> the first patch. The goal of the first patch is simply to ensure that<br>
> if you download from a VX-8R, you don't generate trace back errors<br>
> and you don't get a Settings menu at all. In other words, ensure that<br>
> the correct code gets called for a given variant.<br>
<br>
</span>Yeah, good plan.<br>
<span class=""><br>
> On an administrative note, should we just reject Issue 4881 and have<br>
> me create a new issue with the scope of work limited to the bug fix?<br>
<br>
</span>It's up to you, but I don't think you need to close it. You could call<br>
all of your patches "groundwork" for getting to 4881, or open a new bug<br>
for the correctness (i.e. fixing the tracebacks) and then any refactors<br>
are mostly groundwork for the end goal of settings support for the base<br>
driver.<br>
<br>
But, your call as you're doing the work. I just granted you permissions<br>
to monkey with the issues, so you can close/create/link as you see fit.<br>
<br>
Thanks!<br>
<div class="HOEnZb"><div class="h5"><br>
--Dan<br>
<br>
______________________________<wbr>_________________<br>
chirp_devel mailing list<br>
<a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.<wbr>danplanet.com</a><br>
<a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" rel="noreferrer" target="_blank">http://intrepid.danplanet.com/<wbr>mailman/listinfo/chirp_devel</a><br>
Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" rel="noreferrer" target="_blank">http://chirp.danplanet.com/<wbr>projects/chirp/wiki/Developers</a><br>
</div></div></blockquote></div><br></div>