[chirp_devel] Plans to get the users involved
Thanks to everyone that has tried (and/or still plans) to help test the new UI and radios under py3. The testing matrix is looking pretty decent:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
I know there are still things on there that people here have plans to test/fix, so please keep those coming.
With the help of some stats, it looks like we're almost at the point at which 90% of the radios that get used regularly are in the "tested" or "probably works" category. Honestly, that's higher than I was really thinking we'd get, so that's cool.
I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page.
I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable.
If anyone feels this is premature or not the best plan, speak up here and we can discuss. Actually, please speak up regardless, even if it's "yes, seems reasonable" or "friggin finally". There will be some bumps for sure, but I think if people can continue using the legacy builds for radios that don't yet work on the new stuff, we should be okay.
I've started generating periodic builds here:
https://trac.chirp.danplanet.com/chirp_next
I've also started on a couple of docs on the website for "why are we doing this":
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuild
as well as explaining some differences between the old and new UI:
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuildChanges
If you have comments, edits, or suggestions on these, let me know.
--Dan
I think going py3 only asap is the best idea.
Looks great to me!
On Fri, Dec 16, 2022, 3:31 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Thanks to everyone that has tried (and/or still plans) to help test the new UI and radios under py3. The testing matrix is looking pretty decent:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
I know there are still things on there that people here have plans to test/fix, so please keep those coming.
With the help of some stats, it looks like we're almost at the point at which 90% of the radios that get used regularly are in the "tested" or "probably works" category. Honestly, that's higher than I was really thinking we'd get, so that's cool.
I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page.
I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable.
If anyone feels this is premature or not the best plan, speak up here and we can discuss. Actually, please speak up regardless, even if it's "yes, seems reasonable" or "friggin finally". There will be some bumps for sure, but I think if people can continue using the legacy builds for radios that don't yet work on the new stuff, we should be okay.
I've started generating periodic builds here:
https://trac.chirp.danplanet.com/chirp_next
I've also started on a couple of docs on the website for "why are we doing this":
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuild
as well as explaining some differences between the old and new UI:
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuildChanges
If you have comments, edits, or suggestions on these, let me know.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
Completely agree. Let's get to 3 as soon as we can. Over Christmas I will have a chance to check out the RepeaterBook data imports. Can we use GIT? (Sorry) Great news though! Nicolas RepeaterBook app developer
On Fri, 16 Dec 2022 at 23:22, David Boucha via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
I think going py3 only asap is the best idea.
Looks great to me!
On Fri, Dec 16, 2022, 3:31 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Thanks to everyone that has tried (and/or still plans) to help test the new UI and radios under py3. The testing matrix is looking pretty decent:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
I know there are still things on there that people here have plans to test/fix, so please keep those coming.
With the help of some stats, it looks like we're almost at the point at which 90% of the radios that get used regularly are in the "tested" or "probably works" category. Honestly, that's higher than I was really thinking we'd get, so that's cool.
I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page.
I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable.
If anyone feels this is premature or not the best plan, speak up here and we can discuss. Actually, please speak up regardless, even if it's "yes, seems reasonable" or "friggin finally". There will be some bumps for sure, but I think if people can continue using the legacy builds for radios that don't yet work on the new stuff, we should be okay.
I've started generating periodic builds here:
https://trac.chirp.danplanet.com/chirp_next
I've also started on a couple of docs on the website for "why are we doing this":
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuild
as well as explaining some differences between the old and new UI:
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuildChanges
If you have comments, edits, or suggestions on these, let me know.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page.
I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable.
If anyone feels this is premature or not the best plan, speak up here and we can discuss. Actually, please speak up regardless, even if it's "yes, seems reasonable" or "friggin finally". There will be some bumps for sure, but I think if people can continue using the legacy builds for radios that don't yet work on the new stuff, we should be okay.
This sounds like a reasonable plan to me. I will support it.
Jim KC9HI
On Fri, Dec 16, 2022 at 2:31 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page.
I really like the "New Year, New Chirp" idea. As you say below, there may be some bumps along the road, but I think this would be a very positive message to send to the community as we start a new year.
I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable.
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.
I've also started on a couple of docs on the website for "why are we doing this":
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuild
as well as explaining some differences between the old and new UI:
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuildChanges
If you have comments, edits, or suggestions on these, let me know.
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.
Onward! :-)
Martin. KD6YAM
--Dan
chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
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.
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.
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.
Yeah, I have these saved as personal queries but can make them public when the time comes.
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.
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.
--Dan
Great idea. Looking forward to seeing chirp back in Gentoo's portage.
On Sat, Dec 17, 2022, 11:08 Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
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.
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.
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.
Yeah, I have these saved as personal queries but can make them public when the time comes.
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.
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.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
I would like to say that CHIRP with wxWidgets is looking great. Other comments inlined below.
Tony
December 17, 2022 at 11:08 AM, "Dan Smith via chirp_devel" chirp_devel@intrepid.danplanet.com wrote:
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.
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.
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).
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.
Yeah, I have these saved as personal queries but can make them public when the time comes.
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.
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.
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. --Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
I would like to say that CHIRP with wxWidgets is looking great. Other comments inlined below.
Thanks for saying that. I haven't heard a lot of feedback (other than bugs) about the new UI, which has me a bit nervous. I know there will be a certain amount of unhappiness about any kind of change, but I surely think it's much better than it has ever been in terms of consistency and "feeling native."
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.
Yeah, you definitely are and it's much appreciated, thanks :) The redmine upgrade was a long time coming (for a variety of reasons) but I'm glad to be on a modern version. Moving from their markdown-ish language to real markdown has left a bunch of pages in need of re-formatting as well, but it's pretty easy. I've done a bunch of it already, but there are stragglers.
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).
Yeah, I've been trying to go through and quietly start snipping out py2 and mercurial notes from the developer stuff, but there's certainly going to be other docs that need general trimming. Being in limbo, I've been obviously trying to keep to just developer pages, but help fixing the rest when the time comes would be helpful.
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.
When you said this I just realized... I will need to rename the current daily->legacy in the "Chirp Version" when I do that to make sure we don't confuse bugs opened against what becomes legacy with what becomes daily. The Target Version field is done by relations, but I might have to do some monkeywork in the backend to bulk rename the other field.
--Dan
Let's do it.
Joe Pizzi
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Friday, December 16, 2022 4:31 PM To: chirp devel chirp_devel@intrepid.danplanet.com Subject: [chirp_devel] Plans to get the users involved
Thanks to everyone that has tried (and/or still plans) to help test the new UI and radios under py3. The testing matrix is looking pretty decent:
https://github.com/kk7ds/chirp/blob/py3/tests/Python3_Driver_Testing.md
I know there are still things on there that people here have plans to test/fix, so please keep those coming.
With the help of some stats, it looks like we're almost at the point at which 90% of the radios that get used regularly are in the "tested" or "probably works" category. Honestly, that's higher than I was really thinking we'd get, so that's cool.
I like straight edges, right angles, and easy-to-remember dates. So, I'm thinking that first thing in January would be a good time to send out announcements to the users, looking to expand the testing to a wider audience. I think an initial blast to the chirp_users list would be good, see how that goes, and then start offering both on the download page.
I also think the plan should be to effectively freeze the py2 branch for anything other than bug fixes at that point, and expect all new drivers to be against the py3 branch only. I feel like we've got some inertia now and we had better capitalize on it. At one point in the past I tried to say "new stuff has to work in py3" but I don't think we were close enough to really make that work (sorry Rick!). But now I think we've got builds, they're clearly usable, and saying that new radios will only be available in the new builds is actually reasonable.
If anyone feels this is premature or not the best plan, speak up here and we can discuss. Actually, please speak up regardless, even if it's "yes, seems reasonable" or "friggin finally". There will be some bumps for sure, but I think if people can continue using the legacy builds for radios that don't yet work on the new stuff, we should be okay.
I've started generating periodic builds here:
https://trac.chirp.danplanet.com/chirp_next
I've also started on a couple of docs on the website for "why are we doing this":
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuild
as well as explaining some differences between the old and new UI:
https://chirp.danplanet.com/projects/chirp/wiki/ChirpNextBuildChanges
If you have comments, edits, or suggestions on these, let me know.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com http://intrepid.danplanet.com/mailman/listinfo/chirp_devel Developer docs: http://chirp.danplanet.com/projects/chirp/wiki/Developers
participants (8)
-
Dan Smith -
David Boucha -
Jim Unroe -
Martin Cooper -
Matthew Poletiek -
Nicolas Pike -
pizzi.joe＠gmail.com -
Tony Fuller