[chirp_devel] Python 3 status
Hi all,
New to the mailing lists, but I've been trying to read up on the status of Python 3 support. I'm on Linux (Ubuntu 20.04 LTS), where Python 2 is no longer well-supported. The Flatpak version works alright, but I'm hoping to make some contributions to the VX-6R driver, so that means running from source.
Anyway, a couple questions:
1. The main question is what is the status of this? Dan mentioned in 2019 that about half the drivers had been converted, and the bugtracker for #495 shows a bit more work since, but it (and the Py3 branch) hasn't been updated in quite a while. I saw some messages from certain individuals saying they've made some significant progress on their own (e.g. http://intrepid.danplanet.com/pipermail/chirp_devel/2021-June/006397.html), but I'm guessing that's in private repos? I'm just not really sure what's going on. If there's still more work to be done, I'd like to help, because the legacy Python 2 dependencies are a royal pain.
2. I know Dan was working on rewriting the GUI to use wxPython since gtk2 wasn't ported to Python 3. Is that still part of the Python 3 plan? Is there still more work to be done there?
Thanks, Nick KW4XV
Hello,
I've made a public repo for a py3 version I use.
https://github.com/mpoletiek/py3-CHIRP/pulls
Hope it helps.
- Sent From My Phone
On Fri, Aug 20, 2021, 14:45 Dominick C. Pastore via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi all,
New to the mailing lists, but I've been trying to read up on the status of Python 3 support. I'm on Linux (Ubuntu 20.04 LTS), where Python 2 is no longer well-supported. The Flatpak version works alright, but I'm hoping to make some contributions to the VX-6R driver, so that means running from source.
Anyway, a couple questions:
- The main question is what is the status of this? Dan mentioned in
2019 that about half the drivers had been converted, and the bugtracker for #495 shows a bit more work since, but it (and the Py3 branch) hasn't been updated in quite a while. I saw some messages from certain individuals saying they've made some significant progress on their own (e.g. http://intrepid.danplanet.com/pipermail/chirp_devel/2021-June/006397.html),
but I'm guessing that's in private repos? I'm just not really sure what's going on. If there's still more work to be done, I'd like to help, because the legacy Python 2 dependencies are a royal pain.
- I know Dan was working on rewriting the GUI to use wxPython since
gtk2 wasn't ported to Python 3. Is that still part of the Python 3 plan? Is there still more work to be done there?
Thanks, Nick KW4XV _______________________________________________ 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
Thank you for that, Matthew! I assume your repo is mainly for shared/personal use?
Nick - I'm also interested in helping get the official release over to Python3. So count me in as another resource.
-Nathan KI5QLY
On Fri, Aug 20, 2021 at 4:21 PM Matthew Poletiek via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hello,
I've made a public repo for a py3 version I use.
https://github.com/mpoletiek/py3-CHIRP/pulls
Hope it helps.
- Sent From My Phone
On Fri, Aug 20, 2021, 14:45 Dominick C. Pastore via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi all,
New to the mailing lists, but I've been trying to read up on the status of Python 3 support. I'm on Linux (Ubuntu 20.04 LTS), where Python 2 is no longer well-supported. The Flatpak version works alright, but I'm hoping to make some contributions to the VX-6R driver, so that means running from source.
Anyway, a couple questions:
- The main question is what is the status of this? Dan mentioned in
2019 that about half the drivers had been converted, and the bugtracker for #495 shows a bit more work since, but it (and the Py3 branch) hasn't been updated in quite a while. I saw some messages from certain individuals saying they've made some significant progress on their own (e.g. http://intrepid.danplanet.com/pipermail/chirp_devel/2021-June/006397.html),
but I'm guessing that's in private repos? I'm just not really sure what's going on. If there's still more work to be done, I'd like to help, because the legacy Python 2 dependencies are a royal pain.
- I know Dan was working on rewriting the GUI to use wxPython since
gtk2 wasn't ported to Python 3. Is that still part of the Python 3 plan? Is there still more work to be done there?
Thanks, Nick KW4XV _______________________________________________ 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
Here's my take on the current situation with the various efforts at moving Chirp to Python 3.
* Matthew Poletiek has created a GitHub repo for Py3, but it was not created properly. Instead of migrating the Mercurial repo to Git, what Matt did was make a copy / take a snapshot of the 'py3' branch in Mercurial. Then he made some local changes, and *then* he checked it into a new GitHub repo. So there are a couple of issues here. One, all of the history of the codebase has been lost. Two, Matthew's initial changes have been lost, since it looks like he made local changes between copying from Mercurial and checking into GitHub. I suppose, in theory, if you knew the commit at which Matthew made his copy from Mercurial, you could somehow diff the entire tree between that and his initial commit to GitHub. But there's no commit history to explain what he did.
* Joe Pizzi started from Matthew Poletiek's codebase. He too has a repo on GitHub. The big issue here is that, for unknown (to me) reasons, he did not fork Matthew's codebase, preserving history, but actually copied it into a new GitHub repo. So in Joe's codebase, we not only have the same issues as with Matthew's codebase, described above, but we also have the issue of when Joe made his copy of Matthew's codebase, and whether or not Matthew made changes to his after Joe made that copy.
* A huge number of changes have been made to the (Python 2) trunk of Chirp since Matthew made his copy, and those have not been merged into either the 'py3' Mercurial branch or the GitHub tree(s).
This is a mess. It is unclear to me whether Matthew and Joe are intending for their changes to be merged back, but I think it would be extremely unlikely for that to happen. Since the history has been lost in the GitHub trees, any attempt to merge in one or both of these trees would have to come in the form of a gigantic patch with no history. Frankly, I would be very surprised if Dan would apply such a patch, even if he had the time and inclination to review it. Having no opportunity to review the changes commit by commit, it would be an all-or-nothing merge.
In my opinion, what would really need to happen is:
1. Do a proper migration of the Mercurial codebase to Git, preserving full history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.) 2. Get that *unmodified* copy pushed up to GitHub as the starting point. 3. Figure out the diff between what Matthew first checked in to his repo and what he copied from Mercurial. If Matthew doesn't have a local Git repo from which to obtain commit info, at least make those changes from the first commit to the new GitHub repo. 4. Figure out whether Matthew has made any changes to his GitHub repo since Joe made his copy. I am not entirely sure what path to take if he has made changes. If he hasn't, then move on. 5. Somehow apply all of the commits from Joe's repo on top of the new GitHub repo, preserving all of the commit history. I've no idea if this is possible given the path that has been taken through the creation of all these trees and commits. I'm also assuming that Joe has made meaningful commits with appropriate explanatory messages, but that may not be a safe assumption. 6. Merge in all of the changes to the trunk in Mercurial since the py3 branch was created (and that have not already been merged; I'm unclear as to whether or not any have). This is a huge task because of the degree of change in the py3 branch and its derivatives.
At that point, there would in theory be a Python 3 version of Chirp in GitHub with full project history. But that is a lot of work, and I've no idea if Matthew and / or Joe would be interested in pursuing it. For someone else to do it without them, the important point in the list above would be #3.
For completeness, the other alternative is to start again, from the Chirp trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
Martin. KD6YAM
On Fri, Aug 20, 2021 at 12:45 PM Dominick C. Pastore via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
Hi all,
New to the mailing lists, but I've been trying to read up on the status of Python 3 support. I'm on Linux (Ubuntu 20.04 LTS), where Python 2 is no longer well-supported. The Flatpak version works alright, but I'm hoping to make some contributions to the VX-6R driver, so that means running from source.
Anyway, a couple questions:
- The main question is what is the status of this? Dan mentioned in
2019 that about half the drivers had been converted, and the bugtracker for #495 shows a bit more work since, but it (and the Py3 branch) hasn't been updated in quite a while. I saw some messages from certain individuals saying they've made some significant progress on their own (e.g. http://intrepid.danplanet.com/pipermail/chirp_devel/2021-June/006397.html),
but I'm guessing that's in private repos? I'm just not really sure what's going on. If there's still more work to be done, I'd like to help, because the legacy Python 2 dependencies are a royal pain.
- I know Dan was working on rewriting the GUI to use wxPython since
gtk2 wasn't ported to Python 3. Is that still part of the Python 3 plan? Is there still more work to be done there?
Thanks, Nick KW4XV _______________________________________________ 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
Yes, my repo is mostly for personal use, but a few others have made contributions that I've merged.
In the readme I detail what revision I forked from and what changes I made.
""
Repo Source (Forked From)
Mercurial Repository: http://d-rats.com/hg/chirp.hg Revision: py3 Number: 3351:68534f20c141
Bugs and Patches Submitted to Official Project
https://chirp.danplanet.com/issues/8475 - Fixed old Python2 Syntax https://chirp.danplanet.com/issues/8545 - Syntax Errors in Driver Files https://chirp.danplanet.com/issues/8549 - Updated string.uppercase to string.ascii_uppercase
""
I agree with the steps Martin has laid out, however I don't think I'll have the time for a while to do the work.
Approving another pull request to my repo currently.
------------------------------------------- Matthew Poletiek 303.810.9082 matthew.poletiek@gmail.com www.matthewpoletiek.com
On Fri, Aug 20, 2021 at 5:47 PM Martin Cooper via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Here's my take on the current situation with the various efforts at moving Chirp to Python 3.
Matthew Poletiek has created a GitHub repo for Py3, but it was not created properly. Instead of migrating the Mercurial repo to Git, what Matt did was make a copy / take a snapshot of the 'py3' branch in Mercurial. Then he made some local changes, and *then* he checked it into a new GitHub repo. So there are a couple of issues here. One, all of the history of the codebase has been lost. Two, Matthew's initial changes have been lost, since it looks like he made local changes between copying from Mercurial and checking into GitHub. I suppose, in theory, if you knew the commit at which Matthew made his copy from Mercurial, you could somehow diff the entire tree between that and his initial commit to GitHub. But there's no commit history to explain what he did.
Joe Pizzi started from Matthew Poletiek's codebase. He too has a repo on GitHub. The big issue here is that, for unknown (to me) reasons, he did not fork Matthew's codebase, preserving history, but actually copied it into a new GitHub repo. So in Joe's codebase, we not only have the same issues as with Matthew's codebase, described above, but we also have the issue of when Joe made his copy of Matthew's codebase, and whether or not Matthew made changes to his after Joe made that copy.
A huge number of changes have been made to the (Python 2) trunk of Chirp since Matthew made his copy, and those have not been merged into either the 'py3' Mercurial branch or the GitHub tree(s).
This is a mess. It is unclear to me whether Matthew and Joe are intending for their changes to be merged back, but I think it would be extremely unlikely for that to happen. Since the history has been lost in the GitHub trees, any attempt to merge in one or both of these trees would have to come in the form of a gigantic patch with no history. Frankly, I would be very surprised if Dan would apply such a patch, even if he had the time and inclination to review it. Having no opportunity to review the changes commit by commit, it would be an all-or-nothing merge.
In my opinion, what would really need to happen is:
- Do a proper migration of the Mercurial codebase to Git, preserving full history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.)
- Get that *unmodified* copy pushed up to GitHub as the starting point.
- Figure out the diff between what Matthew first checked in to his repo and what he copied from Mercurial. If Matthew doesn't have a local Git repo from which to obtain commit info, at least make those changes from the first commit to the new GitHub repo.
- Figure out whether Matthew has made any changes to his GitHub repo since Joe made his copy. I am not entirely sure what path to take if he has made changes. If he hasn't, then move on.
- Somehow apply all of the commits from Joe's repo on top of the new GitHub repo, preserving all of the commit history. I've no idea if this is possible given the path that has been taken through the creation of all these trees and commits. I'm also assuming that Joe has made meaningful commits with appropriate explanatory messages, but that may not be a safe assumption.
- Merge in all of the changes to the trunk in Mercurial since the py3 branch was created (and that have not already been merged; I'm unclear as to whether or not any have). This is a huge task because of the degree of change in the py3 branch and its derivatives.
At that point, there would in theory be a Python 3 version of Chirp in GitHub with full project history. But that is a lot of work, and I've no idea if Matthew and / or Joe would be interested in pursuing it. For someone else to do it without them, the important point in the list above would be #3.
For completeness, the other alternative is to start again, from the Chirp trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
Martin. KD6YAM
On Fri, Aug 20, 2021 at 12:45 PM Dominick C. Pastore via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Hi all,
New to the mailing lists, but I've been trying to read up on the status of Python 3 support. I'm on Linux (Ubuntu 20.04 LTS), where Python 2 is no longer well-supported. The Flatpak version works alright, but I'm hoping to make some contributions to the VX-6R driver, so that means running from source.
Anyway, a couple questions:
- The main question is what is the status of this? Dan mentioned in
2019 that about half the drivers had been converted, and the bugtracker for #495 shows a bit more work since, but it (and the Py3 branch) hasn't been updated in quite a while. I saw some messages from certain individuals saying they've made some significant progress on their own (e.g. http://intrepid.danplanet.com/pipermail/chirp_devel/2021-June/006397.html), but I'm guessing that's in private repos? I'm just not really sure what's going on. If there's still more work to be done, I'd like to help, because the legacy Python 2 dependencies are a royal pain.
- I know Dan was working on rewriting the GUI to use wxPython since
gtk2 wasn't ported to Python 3. Is that still part of the Python 3 plan? Is there still more work to be done there?
Thanks, Nick KW4XV _______________________________________________ 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
In my opinion, what would really need to happen is:
- Do a proper migration of the Mercurial codebase to Git, preserving full history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.)
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.
For completeness, the other alternative is to start again, from the Chirp trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
This is easy to say, but it's just not that simple. We can't stop chirp development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people. Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.
I spent a ton of time working on the py3 stuff for a while, but pretty much burned myself out on it. When the flatpak stuff came it became harder and harder to justify the extra work because it's easy for most linux users to just use. The apple silicon thing is obviously a problem, but they're a smaller group than linux users. Since the python2 stuff is still installable by PPA, it's just really difficult for me to justify working on it. I know it's a looming problem.
If there was someone committed to bringing the new py3 GUI up to parity with the current one at least, that would help incentivize me to work on publishing builds from that other branch and keeping the other branch synced up. If we got to the point where the GUI was reasonably close, and most/all of the drivers worked, then obviously switching over and abandoning the python2 branch would be the thing to do. However, lots of people show up here with big plans, but it rarely pans out :/
I definitely agree that the various trees that have sprung up with no history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.
--Dan
I feel your pain, GUI development is not what I'm good at. I just didn't want to maintain yet another package manager on a distro that already had an amazing one and making the py3 branch work for me wasn't difficult at all to be honest. The GUI works for me currently too.
I like the idea of mirroring mercurial to github. In my opinion this project is more at risk of not attracting new talent than it is at losing the current contributors. Github is where they're at.
Obviously I'm not trying to manage a whole new project either.
It sounds like what this branch really needs is another GUI dev willing to work with wxPython.
------------------------------------------- Matthew Poletiek 303.810.9082 matthew.poletiek@gmail.com www.matthewpoletiek.com
On Fri, Aug 20, 2021 at 6:51 PM Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
In my opinion, what would really need to happen is:
- Do a proper migration of the Mercurial codebase to Git, preserving full history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.)
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.
For completeness, the other alternative is to start again, from the Chirp trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
This is easy to say, but it's just not that simple. We can't stop chirp development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people. Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.
I spent a ton of time working on the py3 stuff for a while, but pretty much burned myself out on it. When the flatpak stuff came it became harder and harder to justify the extra work because it's easy for most linux users to just use. The apple silicon thing is obviously a problem, but they're a smaller group than linux users. Since the python2 stuff is still installable by PPA, it's just really difficult for me to justify working on it. I know it's a looming problem.
If there was someone committed to bringing the new py3 GUI up to parity with the current one at least, that would help incentivize me to work on publishing builds from that other branch and keeping the other branch synced up. If we got to the point where the GUI was reasonably close, and most/all of the drivers worked, then obviously switching over and abandoning the python2 branch would be the thing to do. However, lots of people show up here with big plans, but it rarely pans out :/
I definitely agree that the various trees that have sprung up with no history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.
--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
Well, I'm glad this kicked off some discussion about the way forward. (And thank you for the summary on the current state of things, Martin.)
First off, I should probably clarify: I'm not really in a place to make any hard and fast commitments (not that I expect anyone would assume otherwise). But I do really want to see an official Python 3 release, and I'm willing to put in some effort when I have free time if it would help make it happen.
GUI programming is not something I've done a lot of, but if that's where the work is needed, I'm willing to try my hand at it.
Regarding Mercurial vs. GitHub: I know I'm new here, but personally, I couldn't care less whether the code is on GitHub, GitLab, Bitbucket, or some Git repo on Dan's server with emailed patches (like the Linux kernel). I've done all of the above. My only gripe with the current system is that I know Git well, and I don't know Mercurial. But I know Mercurial is supposed to have a lot in common, so it's probably not that hard to learn.
Regarding ongoing Python 2 compatibility: It makes sense to me that the main branch has to be actively maintained in Python-2-land (at least until the Py3 branch reaches parity), but we aren't talking about keeping the Py3 branch compatible with both 2 and 3, are we?
Nick
On 8/20/21 8:00 PM, Matthew Poletiek via chirp_devel wrote:
I feel your pain, GUI development is not what I'm good at. I just didn't want to maintain yet another package manager on a distro that already had an amazing one and making the py3 branch work for me wasn't difficult at all to be honest. The GUI works for me currently too.
I like the idea of mirroring mercurial to github. In my opinion this project is more at risk of not attracting new talent than it is at losing the current contributors. Github is where they're at.
Obviously I'm not trying to manage a whole new project either.
It sounds like what this branch really needs is another GUI dev willing to work with wxPython.
Matthew Poletiek 303.810.9082 matthew.poletiek@gmail.com www.matthewpoletiek.com
On Fri, Aug 20, 2021 at 6:51 PM Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
In my opinion, what would really need to happen is:
- Do a proper migration of the Mercurial codebase to Git, preserving full history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.)
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.
For completeness, the other alternative is to start again, from the Chirp trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
This is easy to say, but it's just not that simple. We can't stop chirp development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people. Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.
I spent a ton of time working on the py3 stuff for a while, but pretty much burned myself out on it. When the flatpak stuff came it became harder and harder to justify the extra work because it's easy for most linux users to just use. The apple silicon thing is obviously a problem, but they're a smaller group than linux users. Since the python2 stuff is still installable by PPA, it's just really difficult for me to justify working on it. I know it's a looming problem.
If there was someone committed to bringing the new py3 GUI up to parity with the current one at least, that would help incentivize me to work on publishing builds from that other branch and keeping the other branch synced up. If we got to the point where the GUI was reasonably close, and most/all of the drivers worked, then obviously switching over and abandoning the python2 branch would be the thing to do. However, lots of people show up here with big plans, but it rarely pans out :/
I definitely agree that the various trees that have sprung up with no history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.
--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
Thanks, Martin, for the synopsis.
Thanks, Dan, for the input and discussion.
I created my git repository because I couldn't figure out how to do anything in Matthew's repository. I'm more than willing to abandon my repo.
After updating my copy and creating my repo, I essentially abandoned it myself. I took the latest Chirp from Mercurial, and started checking what was and wasn't working when running Py3. I kinda gave up on that, too.
I started enhancing the GUI to try to bring it up on par with the GTK one, but ran into some really strange issues.
I lost motivation when I asked several questions here in the list, and never got any answers.
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, August 20, 2021 6:51 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Python 3 status
In my opinion, what would really need to happen is:
- Do a proper migration of the Mercurial codebase to Git, preserving full
history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.)
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.
For completeness, the other alternative is to start again, from the Chirp
trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
This is easy to say, but it's just not that simple. We can't stop chirp development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people. Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.
I spent a ton of time working on the py3 stuff for a while, but pretty much burned myself out on it. When the flatpak stuff came it became harder and harder to justify the extra work because it's easy for most linux users to just use. The apple silicon thing is obviously a problem, but they're a smaller group than linux users. Since the python2 stuff is still installable by PPA, it's just really difficult for me to justify working on it. I know it's a looming problem.
If there was someone committed to bringing the new py3 GUI up to parity with the current one at least, that would help incentivize me to work on publishing builds from that other branch and keeping the other branch synced up. If we got to the point where the GUI was reasonably close, and most/all of the drivers worked, then obviously switching over and abandoning the python2 branch would be the thing to do. However, lots of people show up here with big plans, but it rarely pans out :/
I definitely agree that the various trees that have sprung up with no history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.
--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
After refreshing my memory, my latest stuff (local only) has me updating drivers such that they run in both Python 2 and Python 3.
Seems like this should facilitate easier migration to the new GUI (or at least some new development on it).
I started with the current pristine repository and did each change on an independent commit.
This seems far easier to take piecemeal and at leisure.
Dan, did we get off on the wrong foot? I most certainly do not want to take over your excellent product, just add to it.
Joe Pizzi
-----Original Message----- From: Joe Pizzi pizzi.joe@gmail.com Sent: Friday, August 20, 2021 9:53 PM To: 'Dan Smith' dsmith@danplanet.com; chirp_devel@intrepid.danplanet.com Subject: RE: [chirp_devel] Python 3 status
Thanks, Martin, for the synopsis.
Thanks, Dan, for the input and discussion.
I created my git repository because I couldn't figure out how to do anything in Matthew's repository. I'm more than willing to abandon my repo.
After updating my copy and creating my repo, I essentially abandoned it myself. I took the latest Chirp from Mercurial, and started checking what was and wasn't working when running Py3. I kinda gave up on that, too.
I started enhancing the GUI to try to bring it up on par with the GTK one, but ran into some really strange issues.
I lost motivation when I asked several questions here in the list, and never got any answers.
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, August 20, 2021 6:51 PM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Python 3 status
In my opinion, what would really need to happen is:
- Do a proper migration of the Mercurial codebase to Git, preserving full
history. Make a clear note of the (Mercurial) commit at which this was done, for later reference. (The right thing would be for the Mercurial repo to be tagged at this point, but that seems unlikely to happen.)
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.
For completeness, the other alternative is to start again, from the Chirp
trunk instead of the py3 branch, and do a Python 3 migration *without* retaining Python 2 compatibility. Also a huge task, but I have to wonder if the result would be better in the end, and much cleaner as a codebase for the future. In my opinion, Chirp should be *moved* to Python 3, without all the complicated work involved in supporting both Python 2 and Python 3, and all the additional developer effort, and testing, that would be involved with that on an ongoing basis.
This is easy to say, but it's just not that simple. We can't stop chirp development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people. Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.
I spent a ton of time working on the py3 stuff for a while, but pretty much burned myself out on it. When the flatpak stuff came it became harder and harder to justify the extra work because it's easy for most linux users to just use. The apple silicon thing is obviously a problem, but they're a smaller group than linux users. Since the python2 stuff is still installable by PPA, it's just really difficult for me to justify working on it. I know it's a looming problem.
If there was someone committed to bringing the new py3 GUI up to parity with the current one at least, that would help incentivize me to work on publishing builds from that other branch and keeping the other branch synced up. If we got to the point where the GUI was reasonably close, and most/all of the drivers worked, then obviously switching over and abandoning the python2 branch would be the thing to do. However, lots of people show up here with big plans, but it rarely pans out :/
I definitely agree that the various trees that have sprung up with no history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.
--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
On Fri, Aug 20, 2021 at 4:51 PM Dan Smith via chirp_devel < chirp_devel@intrepid.danplanet.com> wrote:
This is assuming we're going to move to github, which is at least not a plan currently. I personally don't like github, and there are several developers here comfortable with the mercurial process and who have contributions to chirp that outweigh a lot of perceived benefit of moving to a "new" platform. Of course I'm 100% git in my day job outside of chirp, but I don't want to screw over the existing contributors. I also definitely do not want to have the github page be the thing that "regular" users find or try to file bugs against.
The world has moved to Git. Today there are *far* more developers who are familiar with Git than are familiar with Mercurial. Bitbucket started life as a Mercurial-only service, added Git 3 years later, and last year dropped support for Mercurial entirely. As for Chirp, I would hazard a guess that a significant proportion of the small number of contributors learned Mercurial just so they could contribute to Chirp. I know I did. I would hazard a further guess that many more people are likely to contribute to a Git-based project, and simply aren't willing to learn another source control system just to help out with Chirp. So if you want more help with Chirp, you're much more likely to get it if it's a Git project than if it continues with a dying SCM that people don't want to learn.
I'd be interested in hearing your objections to GitHub. In my experience with a significant number of projects, the pull request mechanism has no equal elsewhere, and makes it easy for a lot of people to contribute, even if they only contribute small changes, and for the project maintainers to apply those changes easily and with excellent tracking. The ability for project maintainers to comment on a pull request, and request additional changes, which can then be made to the same updated pull request, really helps track threads of change. Much better than "please make these changes to your patch and submit another one" via e-mail. GitHub also has great built-in support for Continuous Integration, and with minimal effort, users can see the status of the latest builds and tests at a glance on the repo home page. If there are features that you don't like - you mention the issue tracker - then you don't need to use them. Most of them are optional. The Python project itself is a great example of using GitHub to great effect without buying into the issue tracker, wiki, etc.
https://github.com/python/cpython
That said, Git doesn't have to mean GitHub. As someone else has already mentioned, there are alternatives such as Bitbucket, GitLab, or even self-hosted Git. (This last, though, can take significant work to harden, security-wise - just ask the PHP folks, who have now moved to GitHub after their self-hosted repo was hacked).
This is easy to say, but it's just not that simple. We can't stop chirp
development for two years while we completely rewrite the GUI (again?) and sort out the immense number of unicode/bytes violations in all the drivers. So, we have to be able to keep releasing on python2 from the main branch while we get something on python3 close to ready - at least close enough to be able to replace the current distribution for most people.
But this is not what's happening today. The py3 branch is languishing while development continues on trunk. Very little work is happening on the py3 branch, so it is falling further and further behind. You may not want to stop development for two years to rewrite things, but the py3 branch has already been sitting for two years, almost untouched over that period. Even if the py3 branch is progressed to a working state in its current form, the task of merging in all the changes from trunk is going to be massive. And only then will Chirp be at the point that you can have Py2 & Py3 building out of the same tree.
Especially since (almost) nobody other than myself ever works on the GUI, it's just a huge disincentive to go in that direction at all, IMHO. The py3 branch was being sync'd from the default branch regularly while I was working on it, which wasn't too terrible, but it's definitely work and it's hard to get casual contributors to make sure things work on both for submissions. Rick probably wants to strangle me (more than usual) right now.
I really do believe that you're going to get many more people willing to contribute to a Git project than a Mercurial project. You're certainly more likely to find more GUI developers that way. I also believe that a pure Py3 version is likely to gain more traction with contributors than one where people have to futz around with all the Py2/Py3 compatibility cruft in full knowledge that it's all in service of supporting an obsolete version of the language. There is so much good stuff in Py3, and so much that could benefit Chirp, that it really hobbles the project - and the experience of contributors - to require the use of a compatibility layer to support (develop, build, test) both. (On a personal note, I was quite interested in working on the py3 branch until I discovered all of the compatibility cruft, at which point I lost interest entirely.)
Martin. KD6YAM
I definitely agree that the various trees that have sprung up with no
history is causing confusion, and I really don't want to see that as I think it benefits nobody. I guess if it would help for me to create a master github clone that tracks the mercurial tree (at least for a while) I can do that, but I don't want to orphan the people that actually contribute via the current process for several people that have made a couple tweaks via github. No offense. Hopefully at least that would create a stake in the ground for the "official" chirp git tree, with history, and then we can see if the heavy contributors here are comfortable moving to that.
--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
The world has moved to Git.
OMG, really? I totally missed this memo. I guess we *have* to move. We should probably all run Windows too, right? Yay monoculture! :)
(On a personal note, I was quite interested in working on the py3 branch until I discovered all of the compatibility cruft, at which point I lost interest entirely.)
So why are you here? Just heckling and hoping that someone else will get the project to the point where you're willing to contribute? This is my general hesitancy to move stuff just because someone shows up and says "If only this project used tool X, then I'd contribute." The opinions of people who have actually contributed meaningfully weigh much more on me than those that haven't.
Moving to a new language and toolchain requires people that *have* contributed a lot to change, it requires me to change my build environment, and other knock-on impacts. Obviously I want it to just magically be current, but that involves a lot of work on my part, and even though might be great if it meant more contributors, it's still work.
As I said I would, just created this:
https://github.com/kk7ds/chirp
...and I will endeavor to sync back and forth between there and the mercurial repo so that people can, for the moment, submit to either. If/when the github side becomes the obvious default (clearly it will over time) and we can get the current major contributors happy with it, then I can work on making the build infrastructure pull from git and then stop the mercurial synchronization.
One of the primary reasons to tolerate github, IMHO, is travis, but unfortunately travis has seemingly abandoned the OSS people that used it before. In just working to get the tests running in travis I burned a substantial number of my own credits just getting it going, so at this point, I don't think it's really an option, unfortunately. I hope that changes.
For those that have set up unofficial git repos, it would probably benefit the world if you could either mark those as deprecated, remove them, or at least point at the above repo in a comment or something.
Joe, I assume you'd rather propose your patches (which I haven't looked at yet) against the github repo. If not, let me know.
--Dan
I Dan et all.
I have some practice dealing with Travis in the past even for automatic releasing on tagging for a project (actually I'm learning Github Actions for a project)
I can help with Travis and with the python3 porting, DevOps here (more Ops than dev...)
Cheers Pavel, CO7WT
El 22/8/21 a las 15:39, Dan Smith via chirp_devel escribió:
The world has moved to Git.
OMG, really? I totally missed this memo. I guess we *have* to move. We should probably all run Windows too, right? Yay monoculture! :)
(On a personal note, I was quite interested in working on the py3 branch until I discovered all of the compatibility cruft, at which point I lost interest entirely.)
So why are you here? Just heckling and hoping that someone else will get the project to the point where you're willing to contribute? This is my general hesitancy to move stuff just because someone shows up and says "If only this project used tool X, then I'd contribute." The opinions of people who have actually contributed meaningfully weigh much more on me than those that haven't.
Moving to a new language and toolchain requires people that *have* contributed a lot to change, it requires me to change my build environment, and other knock-on impacts. Obviously I want it to just magically be current, but that involves a lot of work on my part, and even though might be great if it meant more contributors, it's still work.
As I said I would, just created this:
https://github.com/kk7ds/chirp
...and I will endeavor to sync back and forth between there and the mercurial repo so that people can, for the moment, submit to either. If/when the github side becomes the obvious default (clearly it will over time) and we can get the current major contributors happy with it, then I can work on making the build infrastructure pull from git and then stop the mercurial synchronization.
One of the primary reasons to tolerate github, IMHO, is travis, but unfortunately travis has seemingly abandoned the OSS people that used it before. In just working to get the tests running in travis I burned a substantial number of my own credits just getting it going, so at this point, I don't think it's really an option, unfortunately. I hope that changes.
For those that have set up unofficial git repos, it would probably benefit the world if you could either mark those as deprecated, remove them, or at least point at the above repo in a comment or something.
Joe, I assume you'd rather propose your patches (which I haven't looked at yet) against the github repo. If not, 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
I have some practice dealing with Travis in the past even for automatic releasing on tagging for a project (actually I'm learning Github Actions for a project)
Thanks, I'm pretty familiar with travis myself and have used it in plenty of places. It's just the new pricing model that is the problem, not actually running the tests - those went fine after working through some of the weirdness of the chirp tests, which run with a split of site packages and venv because of lxml. But, the tests do a lot of work, about 300s per run, which will eat through the one-time gift of credits they gave people after the pricing change.
--Dan
OMG, really? I totally missed this memo. I guess we *have* to move. We should probably all run Windows too, right? Yay monoculture! :)
I stand by my original paragraph, which you chose to snip. Being snide and sarcastic about it doesn't lessen the truth of it.
So why are you here? Just heckling and hoping that someone else will get
the project to the point where you're willing to contribute? This is my general hesitancy to move stuff just because someone shows up and says "If only this project used tool X, then I'd contribute." The opinions of people who have actually contributed meaningfully weigh much more on me than those that haven't.
Message received. If contributing a driver for a new radio (IC-910H) and a fix for broken functionality (Icom auto-detect), and providing constructive commentary on other contributions via the mailing list is not considered meaningful, then your question is certainly a good one - what am I doing here?
I had thought that I could provide input that might prove beneficial to a discussion on the future of a project that I consider worthwhile, and of great benefit to many hams, but that I also consider to be in trouble with regard to moving to a more current version of Python. As for doing the work, open source is almost always about scratching an itch. Contributing to discussions is usually considered part of that.
Moving to a new language and toolchain requires people that *have*
contributed a lot to change, it requires me to change my build environment, and other knock-on impacts. Obviously I want it to just magically be current, but that involves a lot of work on my part, and even though might be great if it meant more contributors, it's still work.
Building a team around Chirp would, in my opinion, benefit the project greatly. To my knowledge - and certainly I could be wrong here, since much is not visible - you are the only committer, and everything has to either be done by you or go through you. That is obviously going to make it feel like the world is on your shoulders. By creating a team of trusted collaborators over time - likely from your list of meaningful contributors - you could spread the load. More could potentially get done, and you wouldn't need to be, or feel like, a bottleneck, since others could pick up the slack when you need some down-time.
Martin. KD6YAM
I removed my unofficial repository.
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: Sunday, August 22, 2021 2:39 PM To: chirp-devel chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Python 3 status
The world has moved to Git.
OMG, really? I totally missed this memo. I guess we *have* to move. We should probably all run Windows too, right? Yay monoculture! :)
(On a personal note, I was quite interested in working on the py3 branch
until I discovered all of the compatibility cruft, at which point I lost interest entirely.)
So why are you here? Just heckling and hoping that someone else will get the project to the point where you're willing to contribute? This is my general hesitancy to move stuff just because someone shows up and says "If only this project used tool X, then I'd contribute." The opinions of people who have actually contributed meaningfully weigh much more on me than those that haven't.
Moving to a new language and toolchain requires people that *have* contributed a lot to change, it requires me to change my build environment, and other knock-on impacts. Obviously I want it to just magically be current, but that involves a lot of work on my part, and even though might be great if it meant more contributors, it's still work.
As I said I would, just created this:
https://github.com/kk7ds/chirp
...and I will endeavor to sync back and forth between there and the mercurial repo so that people can, for the moment, submit to either. If/when the github side becomes the obvious default (clearly it will over time) and we can get the current major contributors happy with it, then I can work on making the build infrastructure pull from git and then stop the mercurial synchronization.
One of the primary reasons to tolerate github, IMHO, is travis, but unfortunately travis has seemingly abandoned the OSS people that used it before. In just working to get the tests running in travis I burned a substantial number of my own credits just getting it going, so at this point, I don't think it's really an option, unfortunately. I hope that changes.
For those that have set up unofficial git repos, it would probably benefit the world if you could either mark those as deprecated, remove them, or at least point at the above repo in a comment or something.
Joe, I assume you'd rather propose your patches (which I haven't looked at yet) against the github repo. If not, 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
Hello Joe,
Does this mean all of the changes you made in your personal repo are now in Dan's new Chirp Github repo?
--David KI6ZHD
On 08/24/2021 06:45 PM, Joe Pizzi via chirp_devel wrote:
I removed my unofficial repository.
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: Sunday, August 22, 2021 2:39 PM To: chirp-devel chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Python 3 status
The world has moved to Git.
OMG, really? I totally missed this memo. I guess we *have* to move. We should probably all run Windows too, right? Yay monoculture! :)
(On a personal note, I was quite interested in working on the py3 branch
until I discovered all of the compatibility cruft, at which point I lost interest entirely.)
So why are you here? Just heckling and hoping that someone else will get the project to the point where you're willing to contribute? This is my general hesitancy to move stuff just because someone shows up and says "If only this project used tool X, then I'd contribute." The opinions of people who have actually contributed meaningfully weigh much more on me than those that haven't.
Moving to a new language and toolchain requires people that *have* contributed a lot to change, it requires me to change my build environment, and other knock-on impacts. Obviously I want it to just magically be current, but that involves a lot of work on my part, and even though might be great if it meant more contributors, it's still work.
As I said I would, just created this:
https://github.com/kk7ds/chirp
...and I will endeavor to sync back and forth between there and the mercurial repo so that people can, for the moment, submit to either. If/when the github side becomes the obvious default (clearly it will over time) and we can get the current major contributors happy with it, then I can work on making the build infrastructure pull from git and then stop the mercurial synchronization.
One of the primary reasons to tolerate github, IMHO, is travis, but unfortunately travis has seemingly abandoned the OSS people that used it before. In just working to get the tests running in travis I burned a substantial number of my own credits just getting it going, so at this point, I don't think it's really an option, unfortunately. I hope that changes.
For those that have set up unofficial git repos, it would probably benefit the world if you could either mark those as deprecated, remove them, or at least point at the above repo in a comment or something.
Joe, I assume you'd rather propose your patches (which I haven't looked at yet) against the github repo. If not, 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
No, it doesn't.
I abandoned all those changes because they didn't have the requisite testing that would allow them into the baseline.
The only radio I have that is compatible is a Baofeng UV-5R. So far, I can't Chirp to talk to the serial port at all. I select download, choose the COM port, and hit OK, and nothing happens.
I'm more than willing to try my hand at getting the specific driver you need working for you. Just let me know which. Better yet, file a bug: make sure you mark it PY3, so everybody knows that it isn't a "general" issue, just one for Python3.
I have been able to upload and download to my radio in the past, but it might not have been on Windows. I know I did it on my Raspberry Pi. Maybe on Linux, too. Right now, I'm in Windows. Don't know if I have everything setup in the 3.9 version of Python or not. Might be that I only have it in the 2.7 version, or it might be that I only have it in the installed version of Chirp. Haven't gotten that far to look, yet.
Joe Pizzi
From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of David Ranch via chirp_devel Sent: Wednesday, August 25, 2021 9:51 AM To: chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Python 3 status
Hello Joe,
Does this mean all of the changes you made in your personal repo are now in Dan's new Chirp Github repo?
--David KI6ZHD
On 08/24/2021 06:45 PM, Joe Pizzi via chirp_devel wrote:
I removed my unofficial repository.
Joe Pizzi
-----Original Message----- From: chirp_devel-bounces@intrepid.danplanet.com mailto:chirp_devel-bounces@intrepid.danplanet.com mailto:chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com On Behalf Of Dan Smith via chirp_devel Sent: Sunday, August 22, 2021 2:39 PM To: chirp-devel mailto:chirp_devel@intrepid.danplanet.com chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Python 3 status
The world has moved to Git.
OMG, really? I totally missed this memo. I guess we *have* to move. We should probably all run Windows too, right? Yay monoculture! :)
(On a personal note, I was quite interested in working on the py3 branch
until I discovered all of the compatibility cruft, at which point I lost interest entirely.)
So why are you here? Just heckling and hoping that someone else will get the project to the point where you're willing to contribute? This is my general hesitancy to move stuff just because someone shows up and says "If only this project used tool X, then I'd contribute." The opinions of people who have actually contributed meaningfully weigh much more on me than those that haven't.
Moving to a new language and toolchain requires people that *have* contributed a lot to change, it requires me to change my build environment, and other knock-on impacts. Obviously I want it to just magically be current, but that involves a lot of work on my part, and even though might be great if it meant more contributors, it's still work.
As I said I would, just created this:
https://github.com/kk7ds/chirp
...and I will endeavor to sync back and forth between there and the mercurial repo so that people can, for the moment, submit to either. If/when the github side becomes the obvious default (clearly it will over time) and we can get the current major contributors happy with it, then I can work on making the build infrastructure pull from git and then stop the mercurial synchronization.
One of the primary reasons to tolerate github, IMHO, is travis, but unfortunately travis has seemingly abandoned the OSS people that used it before. In just working to get the tests running in travis I burned a substantial number of my own credits just getting it going, so at this point, I don't think it's really an option, unfortunately. I hope that changes.
For those that have set up unofficial git repos, it would probably benefit the world if you could either mark those as deprecated, remove them, or at least point at the above repo in a comment or something.
Joe, I assume you'd rather propose your patches (which I haven't looked at yet) against the github repo. If not, let me know.
--Dan _______________________________________________ chirp_devel mailing list chirp_devel@intrepid.danplanet.com mailto: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 mailto: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 Ranch -
Dominick C. Pastore -
Joe Pizzi -
Martin Cooper -
Matthew Poletiek -
Nathan Deckinga -
Pavel Milanes Costa (CO7WT)