<!DOCTYPE html><html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body><div>I would like to say that CHIRP with wxWidgets is looking great. Other comments inlined below.<br></div><div><br></div><div>Tony<br></div><div><br></div><div>December 17, 2022 at 11:08 AM, "Dan Smith via chirp_devel" <<a href="mailto:chirp_devel@intrepid.danplanet.com?to=%22Dan%20Smith%20via%20chirp_devel%22%20%3Cchirp_devel%40intrepid.danplanet.com%3E" target="_blank" tabindex="-1">chirp_devel@intrepid.danplanet.com</a>> wrote:</div><blockquote><blockquote>I couldn't agree more. Now that we're gaining real momentum on py3 and reaching critical mass, it's time to focus all our energy on moving forward, and let go of the past as rapidly as we can. Being clear about py2 being in strict maintenance mode will be essential. It will also be crucial to jump on any issues that come up with installation of py3 builds, on any platform, so that we can make the transition process as painless as possible for as many users as possible.</blockquote><div><br></div><div>Yeah, I'm definitely going to need help with this. I tend to ignore issues for radios I don't have, but in a lot of cases, a debug log is enough to spot an issue. Especially if it's a leftover ord(str) or similar py3-related thing, most people should be able to spot and fix that. With the load-module thing, it's also easy to let someone test a fix (assuming it's in a driver) before we put it in.</div></blockquote><div><br></div><div>I enjoy helping out with these types of issues (especially where the settings page doesn't load). I'm in to keep an eye on the redmine issue tracker (which looks great since the upgrade btw) and chip in where I can. We'll probably need to update/review many of the wiki pages too or move the existing ones into a legacy section (if that's possible).<br></div><div><br></div><blockquote><blockquote>I think, perhaps just prior to the announcement to chirp-users, or perhaps sooner, it might be helpful to add the bug lists from "list of requested features" and "list of bugs" in the first document to the list of "Custom queries" in the issue tracker (i.e. the right-hand column), to make it as easy as possible to find these. It might help reduce duplication as people start to use the new builds.</blockquote><div><br></div><div>Yeah, I have these saved as personal queries but can make them public when the time comes.</div><div><br></div><div>In thinking about this, I'm wondering if anyone has a better idea for the stream naming. My thought was that in a year, we want to continue having daily builds, but be based on the new stuff, and we need to refer to the old frozen thing by a name. I don't want to just yank the carpet and start calling the new thing daily right away. So, the "daily becomes legacy, next becomes daily" dance is what I was thinking. But if anyone has a better idea, we should consider it.</div></blockquote><div><br></div><div>This sounds sensible to me. Currently there is one release track, soon there will be two tracks. The old one becoming "legacy" makes sense, espeically if it's not receiving updates.<br></div><div><br></div><blockquote><div>Also, I didn't mention it before, but I think that in January, I will branch current 'master' as 'legacy' and merge 'py3' into 'master' going forward so the default github branch is the new stuff. I'll be sure to make noise about that here when it happens.<br></div><div>--Dan</div><div>_______________________________________________</div><div>chirp_devel mailing list</div><div><a href="mailto:chirp_devel@intrepid.danplanet.com">chirp_devel@intrepid.danplanet.com</a></div><div><a href="http://intrepid.danplanet.com/mailman/listinfo/chirp_devel" target="_blank">http://intrepid.danplanet.com/mailman/listinfo/chirp_devel</a></div><div>Developer docs: <a href="http://chirp.danplanet.com/projects/chirp/wiki/Developers" target="_blank">http://chirp.danplanet.com/projects/chirp/wiki/Developers</a></div></blockquote><div><br></div></body></html>