I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub? Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language. As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.
There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made.
1. No XP support past Python 3.5. I think this is actually a good thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade. 2. With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows). Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...) 3. Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests. Of course, there is also a mercurial plugin that allows mercurial users to work against GitHub repos: https://bitbucket.org/durin42/hg-git/overview [https://d301sr5gafysq2.cloudfront.net/a6f25d658c68/img/repo-avatars/default....]https://bitbucket.org/durin42/hg-git/overview
durin42 / hg-git — Bitbuckethttps://bitbucket.org/durin42/hg-git/overview This is the Hg-Git plugin for Mercurial, adding the ability to push and pull to/from a Git server repository from Hg. This means you can collaborate on Git based projects from Hg, or use a Git server as a collaboration point for a team with developers using both Git and Hg. The Hg-Git plugin can ... bitbucket.org
4. Git is destructive - This is not really true. In fact, the opposite is true. When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow. 5. Github comes with its own documentation/hosting system with native support for markdown. 6. Python itself is hosted on GitHub. 7. GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python). 8. Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.
Anyhow, I'd love to hear what other people's thoughts are on this. I don't want to go down a path that will be outright rejected 😊
Thanks, Derek
I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub?
Before I answer further, I'd like to say that I write python3 for my day job, I use git exclusively these days, I contribute to many projects on github (large and small), and maintain several projects there and take PRs from people. I say this to make it clear that I'm definitely not afraid of the unknown :)
Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language.
Honestly I really don't understand this argument. There is so little (that affects chirp) that differs between 2.7 and 3.x. Unless it's just a psychological thing or something, but.. meh :)
As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.
I get that. I use git exclusively now myself. I understand the desire to appeal to new contributors, but those contributors haven't actually brought anything to the table yet. There are a bunch of contributors that have written and maintain large chunks of chirp code that didn't know another system and learned mercurial to be able to do that. Switching may not be a problem for them, but it's not a zero effort change, and I really (really) want to continue to make things easy for them. I certainly don't want to prioritize the contributors that may exist over those that do. Mercurial is so similar to git that I also really don't understand people that say they don't want to contribute because it requires learning a new (but similar) tool. Learning what you need to write a coherent patch against chirp is like an order of magnitude more work than learning how to hg clone, hg commit, hg email.
Moving to git is also a separate concern from moving to github to me. The two need not be tied together, IMHO.
There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made. • No XP support past Python 3.5. I think this is actually a good thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade.
Well, you can think it's silly but it's a reality. Not long ago I refreshed the build image for Windows and used Windows 7, thinking it was time. The next two days of emails I got from people made it pretty clear that a ton of users still run on XP and so I re-re-built it on XP. I am not a windows user, but the only physical windows machine I have is XP, which is purpose-built for specific tasks, so I get it. It's also the only one I have with a real serial port, which is, quite relevant.
• With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows).
No, we don't "get" GTK3, we are "forced" to move to PyGObject. Now, this is not a problem in and of itself, except that it's a big chunk of work that nobody has done yet. If you want to queue up all the changes required to change the UI to use PyGObject, I will happily review it and do the work to make the build image use it. Several people have expressed interest, but none have actually done it.
If this happens, then we can move to Python 3 by default for sure, and allow things up to 3.5 or whatever still runs on XP. I don't think I'm ready to drop support for XP yet, and since I'm the recipient of all the complaints that will come, hopefully that's understandable.
Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...)
What does this have to do with writing new UIs? There is a very clean seam between the UI and the non-UI stuff. There are routines in the UI that would be re-usable by others, and could easily be brought across that seam for re-use, but that would be very minor compared to the work of actually writing a new UI to meet the level of functionality we currently have. If you're interested in this, please feel free.
• Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests.
I definitely don't understand this. Mercurial and git are extremely similar. Branches in mercurial are a thing, if you want to use them, and you can use the commit workflow instead of mq and patchbomb those the same way. The mq workflow makes a lot of sense for small changes against upstream which are easy to add, remove, update and delete. Patchbomb just emails the commits that mq creates, and you can patchbomb any other commit that you want, if you don't want to use mq.
I've used github extensively, as well as many other similar git-based things. I'm not a huge fan of the PR workflow, the way code gets reviewed (or not) on github, and definitely not a fan of the really nasty commit history patterns that github tends to encourage of people. That said, I use it a lot and can certainly deal with it.
• Git is destructive - This is not really true. In fact, the opposite is true. When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow.
I'm not sure what your point here is. I've never heard this argument, so it definitely doesn't factor into my feelings on the matter :)
• Github comes with its own documentation/hosting system with native support for markdown.
It does, and it works reasonably well for developers. Good luck with the average ham wading through a github repo page to find the docs.
• Python itself is hosted on GitHub.
This isn't really an argument, right? :)
• GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python).
For some definition of easy I guess. Since I'm not a fan of that workflow, I'm biased. However, if you're going to undertake the PyGObject conversion, you can certainly import the repo into github for the collaboration process. But, just like if everything was on github, once you're done I'd expect a sanitized commit history with well-formed commits to come out of that and not just "please merge this branch of 500 messy commits". Unfortunately, that's the way people tend to do stuff in github and I do not think that's a good thing.
• Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.
Moving the code and relevant history there is trivial. Even setting up travis to run the tests wouldn't be hard (and arguably would be the major benefit from moving to github in my mind).
Here are other things you didn't cover, which I think are very important:
1. A github repo page is not going to be something the average ham can digest. That means we still need a website for them to land on. It wouldn't make sense to keep using redmine for that, so I/we have to build something else.
2. Related to the above, the docs on the redmine page have to make it to the new page and not just to the github repo.
3. Right now we have code and bugs in the same place. If we move to a github repo, people _will_ file bugs there, but the average ham is not going to be able to create a github account and file bugs there, IMHO. We can't have two places and maintain sanity. I don't know if we can bulk import bug history to github or not, but if we can't then we lose all that history. I can't tell you how many times a week I'm answering direct emails from people working through the very simple process of creating an account on our redmine site so that they can file or comment on a bug. Github makes that not my problem (which might be good), but it also means I don't control it (for helping them) and I think will be more confusing for that level of user, since github is a lot of stuff, not just about chirp. They're very developer-focused, and people are going to be confused about signing up for an account and being presented with their own profile page instead of just going right back to the chirp repo to file their bug.
I would definitely like to have more contributions to chirp, but there will always be more users than developers. Doing what is right by the users is always going to pay off with more adoption, even if it's less desirable for us.
In summary, I'm happy to take contributions for the PyGObject thing if you want to work on it. If you have solutions to the github concerns I have, then I'd be glad to hear them.
--Dan
Since I have asked about github in the past as well, thought I should chime in. Regarding workflow, PR, and commenting.I actually like this compared to hg, patchbomb. I think the discussion, review, and signoff can be handled much better (and with better history tracking). You can tie some change on a line of code back to the commit, and back to the pr, and the captured discussion behind it. With the current flow, the discussion happens passively in email, and you would have to dig through mailing list archive to follow the discussion and see the approvers behind it.With git hub code reviews, you can designate certain folks as reviewers to give a thumbs up for the change. https://help.github.com/articles/requesting-a-pull-request-review/You can also see all of the integrated testing run against a proposed change in a PR build, and require that to pass before it can even be committed. (While you might be doing this now, it's up front, obvious, and for all to see who are part of the PR.)https://help.github.com/articles/defining-the-mergeability-of-pull-requests/ Regarding the documentation thing. Markdown and readmes are great for commenting the repo itself for developers, but for general user documentation there are two great resources. Github wiki. Much like the existing danplanet one, it's pretty easy to edit and maintain E.g. https://github.com/Netflix/Hystrix/wiki Github pages. Many projects will take their project page up one notch, and can be hosted on github.io. Some examples:https://github.com/collections/github-pages-examples This could be the "landing page" which average users land on, e.g. "chirp.github.com" Regarding the messy commits thing.It doesn't have to be a thing. If you don't want to keep a messy commit history two things:1. use contributing guidelines to explain to prospective contributors what you expect (PEP8 & style stuff, required pre-commit testing, review process, commits structure, etc)2. squash merge - or just explain that in #2 to contributors to squash their working branch into a new clean, merge-worthy branch before opening pr, such that it's already donehttps://help.github.com/articles/about-pull-request-merges/#squash-and-merge...
I think in general moving to github is about making contributing more accessible, and about making all of the peripheral activities more visible and traceable. While contribute to the codebase infrequently, I would be willing to help as much as I can with any effort to migrate the repo/testing/etc over to github.(I'm a repo admin for a number of orgs and repos at my work, and CI/CD stuff is part of my duties as well.) -Jens AF5MI
On Saturday, June 9, 2018, 10:25:48 AM CDT, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub?
Before I answer further, I'd like to say that I write python3 for my day job, I use git exclusively these days, I contribute to many projects on github (large and small), and maintain several projects there and take PRs from people. I say this to make it clear that I'm definitely not afraid of the unknown :)
Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language.
Honestly I really don't understand this argument. There is so little (that affects chirp) that differs between 2.7 and 3.x. Unless it's just a psychological thing or something, but.. meh :)
As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.
I get that. I use git exclusively now myself. I understand the desire to appeal to new contributors, but those contributors haven't actually brought anything to the table yet. There are a bunch of contributors that have written and maintain large chunks of chirp code that didn't know another system and learned mercurial to be able to do that. Switching may not be a problem for them, but it's not a zero effort change, and I really (really) want to continue to make things easy for them. I certainly don't want to prioritize the contributors that may exist over those that do. Mercurial is so similar to git that I also really don't understand people that say they don't want to contribute because it requires learning a new (but similar) tool. Learning what you need to write a coherent patch against chirp is like an order of magnitude more work than learning how to hg clone, hg commit, hg email.
Moving to git is also a separate concern from moving to github to me. The two need not be tied together, IMHO.
There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made. • No XP support past Python 3.5. I think this is actually a good thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade.
Well, you can think it's silly but it's a reality. Not long ago I refreshed the build image for Windows and used Windows 7, thinking it was time. The next two days of emails I got from people made it pretty clear that a ton of users still run on XP and so I re-re-built it on XP. I am not a windows user, but the only physical windows machine I have is XP, which is purpose-built for specific tasks, so I get it. It's also the only one I have with a real serial port, which is, quite relevant.
• With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows).
No, we don't "get" GTK3, we are "forced" to move to PyGObject. Now, this is not a problem in and of itself, except that it's a big chunk of work that nobody has done yet. If you want to queue up all the changes required to change the UI to use PyGObject, I will happily review it and do the work to make the build image use it. Several people have expressed interest, but none have actually done it.
If this happens, then we can move to Python 3 by default for sure, and allow things up to 3.5 or whatever still runs on XP. I don't think I'm ready to drop support for XP yet, and since I'm the recipient of all the complaints that will come, hopefully that's understandable.
Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...)
What does this have to do with writing new UIs? There is a very clean seam between the UI and the non-UI stuff. There are routines in the UI that would be re-usable by others, and could easily be brought across that seam for re-use, but that would be very minor compared to the work of actually writing a new UI to meet the level of functionality we currently have. If you're interested in this, please feel free.
• Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests.
I definitely don't understand this. Mercurial and git are extremely similar. Branches in mercurial are a thing, if you want to use them, and you can use the commit workflow instead of mq and patchbomb those the same way. The mq workflow makes a lot of sense for small changes against upstream which are easy to add, remove, update and delete. Patchbomb just emails the commits that mq creates, and you can patchbomb any other commit that you want, if you don't want to use mq.
I've used github extensively, as well as many other similar git-based things. I'm not a huge fan of the PR workflow, the way code gets reviewed (or not) on github, and definitely not a fan of the really nasty commit history patterns that github tends to encourage of people. That said, I use it a lot and can certainly deal with it.
• Git is destructive - This is not really true. In fact, the opposite is true. When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow.
I'm not sure what your point here is. I've never heard this argument, so it definitely doesn't factor into my feelings on the matter :)
• Github comes with its own documentation/hosting system with native support for markdown.
It does, and it works reasonably well for developers. Good luck with the average ham wading through a github repo page to find the docs.
• Python itself is hosted on GitHub.
This isn't really an argument, right? :)
• GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python).
For some definition of easy I guess. Since I'm not a fan of that workflow, I'm biased. However, if you're going to undertake the PyGObject conversion, you can certainly import the repo into github for the collaboration process. But, just like if everything was on github, once you're done I'd expect a sanitized commit history with well-formed commits to come out of that and not just "please merge this branch of 500 messy commits". Unfortunately, that's the way people tend to do stuff in github and I do not think that's a good thing.
• Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.
Moving the code and relevant history there is trivial. Even setting up travis to run the tests wouldn't be hard (and arguably would be the major benefit from moving to github in my mind).
Here are other things you didn't cover, which I think are very important:
1. A github repo page is not going to be something the average ham can digest. That means we still need a website for them to land on. It wouldn't make sense to keep using redmine for that, so I/we have to build something else.
2. Related to the above, the docs on the redmine page have to make it to the new page and not just to the github repo.
3. Right now we have code and bugs in the same place. If we move to a github repo, people _will_ file bugs there, but the average ham is not going to be able to create a github account and file bugs there, IMHO. We can't have two places and maintain sanity. I don't know if we can bulk import bug history to github or not, but if we can't then we lose all that history. I can't tell you how many times a week I'm answering direct emails from people working through the very simple process of creating an account on our redmine site so that they can file or comment on a bug. Github makes that not my problem (which might be good), but it also means I don't control it (for helping them) and I think will be more confusing for that level of user, since github is a lot of stuff, not just about chirp. They're very developer-focused, and people are going to be confused about signing up for an account and being presented with their own profile page instead of just going right back to the chirp repo to file their bug.
I would definitely like to have more contributions to chirp, but there will always be more users than developers. Doing what is right by the users is always going to pay off with more adoption, even if it's less desirable for us.
In summary, I'm happy to take contributions for the PyGObject thing if you want to work on it. If you have solutions to the github concerns I have, then I'd be glad to hear them.
--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
Forgot the link for the contributing guidelines stuff:https://help.github.com/articles/setting-guidelines-for-repository-contribut...
On Saturday, June 9, 2018, 3:11:50 PM CDT, af5mi--- via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
Since I have asked about github in the past as well, thought I should chime in. Regarding workflow, PR, and commenting.I actually like this compared to hg, patchbomb. I think the discussion, review, and signoff can be handled much better (and with better history tracking). You can tie some change on a line of code back to the commit, and back to the pr, and the captured discussion behind it. With the current flow, the discussion happens passively in email, and you would have to dig through mailing list archive to follow the discussion and see the approvers behind it.With git hub code reviews, you can designate certain folks as reviewers to give a thumbs up for the change. https://help.github.com/articles/requesting-a-pull-request-review/You can also see all of the integrated testing run against a proposed change in a PR build, and require that to pass before it can even be committed. (While you might be doing this now, it's up front, obvious, and for all to see who are part of the PR.)https://help.github.com/articles/defining-the-mergeability-of-pull-requests/ Regarding the documentation thing. Markdown and readmes are great for commenting the repo itself for developers, but for general user documentation there are two great resources. Github wiki. Much like the existing danplanet one, it's pretty easy to edit and maintain E.g. https://github.com/Netflix/Hystrix/wiki Github pages. Many projects will take their project page up one notch, and can be hosted on github.io. Some examples:https://github.com/collections/github-pages-examples This could be the "landing page" which average users land on, e.g. "chirp.github.com" Regarding the messy commits thing.It doesn't have to be a thing. If you don't want to keep a messy commit history two things:1. use contributing guidelines to explain to prospective contributors what you expect (PEP8 & style stuff, required pre-commit testing, review process, commits structure, etc)2. squash merge - or just explain that in #2 to contributors to squash their working branch into a new clean, merge-worthy branch before opening pr, such that it's already donehttps://help.github.com/articles/about-pull-request-merges/#squash-and-merge...
I think in general moving to github is about making contributing more accessible, and about making all of the peripheral activities more visible and traceable. While contribute to the codebase infrequently, I would be willing to help as much as I can with any effort to migrate the repo/testing/etc over to github.(I'm a repo admin for a number of orgs and repos at my work, and CI/CD stuff is part of my duties as well.) -Jens AF5MI
On Saturday, June 9, 2018, 10:25:48 AM CDT, Dan Smith via chirp_devel chirp_devel@intrepid.danplanet.com wrote:
I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub?
Before I answer further, I'd like to say that I write python3 for my day job, I use git exclusively these days, I contribute to many projects on github (large and small), and maintain several projects there and take PRs from people. I say this to make it clear that I'm definitely not afraid of the unknown :)
Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language.
Honestly I really don't understand this argument. There is so little (that affects chirp) that differs between 2.7 and 3.x. Unless it's just a psychological thing or something, but.. meh :)
As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.
I get that. I use git exclusively now myself. I understand the desire to appeal to new contributors, but those contributors haven't actually brought anything to the table yet. There are a bunch of contributors that have written and maintain large chunks of chirp code that didn't know another system and learned mercurial to be able to do that. Switching may not be a problem for them, but it's not a zero effort change, and I really (really) want to continue to make things easy for them. I certainly don't want to prioritize the contributors that may exist over those that do. Mercurial is so similar to git that I also really don't understand people that say they don't want to contribute because it requires learning a new (but similar) tool. Learning what you need to write a coherent patch against chirp is like an order of magnitude more work than learning how to hg clone, hg commit, hg email.
Moving to git is also a separate concern from moving to github to me. The two need not be tied together, IMHO.
There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made. • No XP support past Python 3.5. I think this is actually a good thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade.
Well, you can think it's silly but it's a reality. Not long ago I refreshed the build image for Windows and used Windows 7, thinking it was time. The next two days of emails I got from people made it pretty clear that a ton of users still run on XP and so I re-re-built it on XP. I am not a windows user, but the only physical windows machine I have is XP, which is purpose-built for specific tasks, so I get it. It's also the only one I have with a real serial port, which is, quite relevant.
• With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows).
No, we don't "get" GTK3, we are "forced" to move to PyGObject. Now, this is not a problem in and of itself, except that it's a big chunk of work that nobody has done yet. If you want to queue up all the changes required to change the UI to use PyGObject, I will happily review it and do the work to make the build image use it. Several people have expressed interest, but none have actually done it.
If this happens, then we can move to Python 3 by default for sure, and allow things up to 3.5 or whatever still runs on XP. I don't think I'm ready to drop support for XP yet, and since I'm the recipient of all the complaints that will come, hopefully that's understandable.
Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...)
What does this have to do with writing new UIs? There is a very clean seam between the UI and the non-UI stuff. There are routines in the UI that would be re-usable by others, and could easily be brought across that seam for re-use, but that would be very minor compared to the work of actually writing a new UI to meet the level of functionality we currently have. If you're interested in this, please feel free.
• Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests.
I definitely don't understand this. Mercurial and git are extremely similar. Branches in mercurial are a thing, if you want to use them, and you can use the commit workflow instead of mq and patchbomb those the same way. The mq workflow makes a lot of sense for small changes against upstream which are easy to add, remove, update and delete. Patchbomb just emails the commits that mq creates, and you can patchbomb any other commit that you want, if you don't want to use mq.
I've used github extensively, as well as many other similar git-based things. I'm not a huge fan of the PR workflow, the way code gets reviewed (or not) on github, and definitely not a fan of the really nasty commit history patterns that github tends to encourage of people. That said, I use it a lot and can certainly deal with it.
• Git is destructive - This is not really true. In fact, the opposite is true. When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow.
I'm not sure what your point here is. I've never heard this argument, so it definitely doesn't factor into my feelings on the matter :)
• Github comes with its own documentation/hosting system with native support for markdown.
It does, and it works reasonably well for developers. Good luck with the average ham wading through a github repo page to find the docs.
• Python itself is hosted on GitHub.
This isn't really an argument, right? :)
• GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python).
For some definition of easy I guess. Since I'm not a fan of that workflow, I'm biased. However, if you're going to undertake the PyGObject conversion, you can certainly import the repo into github for the collaboration process. But, just like if everything was on github, once you're done I'd expect a sanitized commit history with well-formed commits to come out of that and not just "please merge this branch of 500 messy commits". Unfortunately, that's the way people tend to do stuff in github and I do not think that's a good thing.
• Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.
Moving the code and relevant history there is trivial. Even setting up travis to run the tests wouldn't be hard (and arguably would be the major benefit from moving to github in my mind).
Here are other things you didn't cover, which I think are very important:
1. A github repo page is not going to be something the average ham can digest. That means we still need a website for them to land on. It wouldn't make sense to keep using redmine for that, so I/we have to build something else.
2. Related to the above, the docs on the redmine page have to make it to the new page and not just to the github repo.
3. Right now we have code and bugs in the same place. If we move to a github repo, people _will_ file bugs there, but the average ham is not going to be able to create a github account and file bugs there, IMHO. We can't have two places and maintain sanity. I don't know if we can bulk import bug history to github or not, but if we can't then we lose all that history. I can't tell you how many times a week I'm answering direct emails from people working through the very simple process of creating an account on our redmine site so that they can file or comment on a bug. Github makes that not my problem (which might be good), but it also means I don't control it (for helping them) and I think will be more confusing for that level of user, since github is a lot of stuff, not just about chirp. They're very developer-focused, and people are going to be confused about signing up for an account and being presented with their own profile page instead of just going right back to the chirp repo to file their bug.
I would definitely like to have more contributions to chirp, but there will always be more users than developers. Doing what is right by the users is always going to pay off with more adoption, even if it's less desirable for us.
In summary, I'm happy to take contributions for the PyGObject thing if you want to work on it. If you have solutions to the github concerns I have, then I'd be glad to hear them.
--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
Hi dan - Thanks for the well thought out responses. To be clear, I am an avid user of chirp first and foremost. I am also not they type of person to complain about a problem without proposing a solution. For me, personally, the main issue with using Chirp is that it doesn't work and feel like a windows app. Things like tab and ctrl+c don't work the way you would expect, and operting on memories in the grid view doesn't work like most windows apps that have grid views. So the upgrading frameworks and python is all about trying to do what's right for the users. It's also worth noting that I have several little things i have worked on for my suported radios that have not made it back in because I'm a bit daunted by the process (not that they are high demand features - likely I'm one of the very few who cares about scan edges, call channels and settings for an ic2720h).
Re: git/github - I have very little experience with hg (chirp is it), so most of my comments are based on experience with git and reading about hg.
To clarify, when I was talking about documentation, I was specifically talking about github.io, not simply the repo docs (and of course Jens' reply comes in as I am writing this saying the same thing). There are utils out there to convert docs from redmine to md/gitlab/etc... including workitems and history. I actually think it's easier to create a giuthub account and report an issue than the current workflow. Currently, the link to issues takes me to a page that shows issues, but ther eis no "new issue" button there. I have to create an account, login and then there is a new issue tab that subtly shows up in the navbar. With github, you provide a link from the main page to issues, there is a new issue button right there, and when you click it, if you are not logged in it opens a popup to create an account or login. Yes, they may go to a profile page, but that's really okay. I don't tihnk most people will have a hard time figuring out how to get back to the issues page. There is the added benefit that once they have an account, they are all set to become a contributor should they so desire, and their bugs and contributions will all be tied to that account.
Also, not to get too argumentative, but you say that you don't want to force existing contributors to learn git but also say that git and hg are so similar that git users should have no problem using HG. So far the only discussion I have seen indicates that contributors know how to use git today, and if it's easy to convert from git to hg then it should be easy to provide a simple guide to converting from hg to git.
At work, we enforce squash before committing to master, so we have a very clean commit history in master. The downside is that in many cases the rebase that was originally 50 commits should really be several commits, but ends up as 1 commit. As Jens alluded to, this can be addressed by requiring contributors to rebase into a sane branch with commits that make sense (e.g. for feature X, commit 1 is backend added function y, 2 is added unit test, 3 is added UI support, etc...).
Re: Python 2.7 vs 3, this is a psychological thing. We hire a lot of young developers at work, and they tend to gravitate towards the projects that are using the more modern technologies. E.g. if I have an old service using entity framework, .net 4 and mvc + node js, or a service using .net core microservices with a kendo/angular based ui, they want to work on the latter (at least I didn't propose moving the UI to .net core 😊 ).
As a new contributor myself, I would like to bring something to the table. I'm a service engineer by trade, so coding is secondary to my day job, but I am trying to write more code.I was thinking for a start, I would work through Python's own guide for upgrading. To me the following makes sense:
Run the non-ui through the python guide to upgrading which starts with supporting both. Stop short of cutting 2.7 support. This is necessary to upgrade regardless of the UI choice so I think it should come first. Evaluate the UI functions for anything else that can be further abstracted. In parallel, keep up the UI discussion. If we have to port to PyGObject, does it make sense to stick with GTK, or should we looks at other UI frameworks?
Thanks, Derek
________________________________ From: Dan Smith dsmith@danplanet.com Sent: Saturday, June 9, 2018 8:25 AM To: Derek Chauran; chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Modernizing
I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub?
Before I answer further, I'd like to say that I write python3 for my day job, I use git exclusively these days, I contribute to many projects on github (large and small), and maintain several projects there and take PRs from people. I say this to make it clear that I'm definitely not afraid of the unknown :)
Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language.
Honestly I really don't understand this argument. There is so little (that affects chirp) that differs between 2.7 and 3.x. Unless it's just a psychological thing or something, but.. meh :)
As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.
I get that. I use git exclusively now myself. I understand the desire to appeal to new contributors, but those contributors haven't actually brought anything to the table yet. There are a bunch of contributors that have written and maintain large chunks of chirp code that didn't know another system and learned mercurial to be able to do that. Switching may not be a problem for them, but it's not a zero effort change, and I really (really) want to continue to make things easy for them. I certainly don't want to prioritize the contributors that may exist over those that do. Mercurial is so similar to git that I also really don't understand people that say they don't want to contribute because it requires learning a new (but similar) tool. Learning what you need to write a coherent patch against chirp is like an order of magnitude more work than learning how to hg clone, hg commit, hg email.
Moving to git is also a separate concern from moving to github to me. The two need not be tied together, IMHO.
There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made. • No XP support past Python 3.5. I think this is actually a good thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade.
Well, you can think it's silly but it's a reality. Not long ago I refreshed the build image for Windows and used Windows 7, thinking it was time. The next two days of emails I got from people made it pretty clear that a ton of users still run on XP and so I re-re-built it on XP. I am not a windows user, but the only physical windows machine I have is XP, which is purpose-built for specific tasks, so I get it. It's also the only one I have with a real serial port, which is, quite relevant.
• With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows).
No, we don't "get" GTK3, we are "forced" to move to PyGObject. Now, this is not a problem in and of itself, except that it's a big chunk of work that nobody has done yet. If you want to queue up all the changes required to change the UI to use PyGObject, I will happily review it and do the work to make the build image use it. Several people have expressed interest, but none have actually done it.
If this happens, then we can move to Python 3 by default for sure, and allow things up to 3.5 or whatever still runs on XP. I don't think I'm ready to drop support for XP yet, and since I'm the recipient of all the complaints that will come, hopefully that's understandable.
Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...)
What does this have to do with writing new UIs? There is a very clean seam between the UI and the non-UI stuff. There are routines in the UI that would be re-usable by others, and could easily be brought across that seam for re-use, but that would be very minor compared to the work of actually writing a new UI to meet the level of functionality we currently have. If you're interested in this, please feel free.
• Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests.
I definitely don't understand this. Mercurial and git are extremely similar. Branches in mercurial are a thing, if you want to use them, and you can use the commit workflow instead of mq and patchbomb those the same way. The mq workflow makes a lot of sense for small changes against upstream which are easy to add, remove, update and delete. Patchbomb just emails the commits that mq creates, and you can patchbomb any other commit that you want, if you don't want to use mq.
I've used github extensively, as well as many other similar git-based things. I'm not a huge fan of the PR workflow, the way code gets reviewed (or not) on github, and definitely not a fan of the really nasty commit history patterns that github tends to encourage of people. That said, I use it a lot and can certainly deal with it.
• Git is destructive - This is not really true. In fact, the opposite is true. When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow.
I'm not sure what your point here is. I've never heard this argument, so it definitely doesn't factor into my feelings on the matter :)
• Github comes with its own documentation/hosting system with native support for markdown.
It does, and it works reasonably well for developers. Good luck with the average ham wading through a github repo page to find the docs.
• Python itself is hosted on GitHub.
This isn't really an argument, right? :)
• GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python).
For some definition of easy I guess. Since I'm not a fan of that workflow, I'm biased. However, if you're going to undertake the PyGObject conversion, you can certainly import the repo into github for the collaboration process. But, just like if everything was on github, once you're done I'd expect a sanitized commit history with well-formed commits to come out of that and not just "please merge this branch of 500 messy commits". Unfortunately, that's the way people tend to do stuff in github and I do not think that's a good thing.
• Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.
Moving the code and relevant history there is trivial. Even setting up travis to run the tests wouldn't be hard (and arguably would be the major benefit from moving to github in my mind).
Here are other things you didn't cover, which I think are very important:
1. A github repo page is not going to be something the average ham can digest. That means we still need a website for them to land on. It wouldn't make sense to keep using redmine for that, so I/we have to build something else.
2. Related to the above, the docs on the redmine page have to make it to the new page and not just to the github repo.
3. Right now we have code and bugs in the same place. If we move to a github repo, people _will_ file bugs there, but the average ham is not going to be able to create a github account and file bugs there, IMHO. We can't have two places and maintain sanity. I don't know if we can bulk import bug history to github or not, but if we can't then we lose all that history. I can't tell you how many times a week I'm answering direct emails from people working through the very simple process of creating an account on our redmine site so that they can file or comment on a bug. Github makes that not my problem (which might be good), but it also means I don't control it (for helping them) and I think will be more confusing for that level of user, since github is a lot of stuff, not just about chirp. They're very developer-focused, and people are going to be confused about signing up for an account and being presented with their own profile page instead of just going right back to the chirp repo to file their bug.
I would definitely like to have more contributions to chirp, but there will always be more users than developers. Doing what is right by the users is always going to pay off with more adoption, even if it's less desirable for us.
In summary, I'm happy to take contributions for the PyGObject thing if you want to work on it. If you have solutions to the github concerns I have, then I'd be glad to hear them.
--Dan
P.S. As Dan has said we are free to do so, I am going to setup a GitHub project for futurizing chirp so that others may contribute. The general principles will be that it must work on 2.7 and 3.5 (for now), and must work on Mac/Linux/Windows.
I will send out the info as soon as it is ready. ________________________________ From: chirp_devel-bounces@intrepid.danplanet.com chirp_devel-bounces@intrepid.danplanet.com on behalf of Derek Chauran via chirp_devel chirp_devel@intrepid.danplanet.com Sent: Saturday, June 9, 2018 1:31 PM To: Dan Smith; chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Modernizing
Hi dan - Thanks for the well thought out responses. To be clear, I am an avid user of chirp first and foremost. I am also not they type of person to complain about a problem without proposing a solution. For me, personally, the main issue with using Chirp is that it doesn't work and feel like a windows app. Things like tab and ctrl+c don't work the way you would expect, and operting on memories in the grid view doesn't work like most windows apps that have grid views. So the upgrading frameworks and python is all about trying to do what's right for the users. It's also worth noting that I have several little things i have worked on for my suported radios that have not made it back in because I'm a bit daunted by the process (not that they are high demand features - likely I'm one of the very few who cares about scan edges, call channels and settings for an ic2720h).
Re: git/github - I have very little experience with hg (chirp is it), so most of my comments are based on experience with git and reading about hg.
To clarify, when I was talking about documentation, I was specifically talking about github.io, not simply the repo docs (and of course Jens' reply comes in as I am writing this saying the same thing). There are utils out there to convert docs from redmine to md/gitlab/etc... including workitems and history. I actually think it's easier to create a giuthub account and report an issue than the current workflow. Currently, the link to issues takes me to a page that shows issues, but ther eis no "new issue" button there. I have to create an account, login and then there is a new issue tab that subtly shows up in the navbar. With github, you provide a link from the main page to issues, there is a new issue button right there, and when you click it, if you are not logged in it opens a popup to create an account or login. Yes, they may go to a profile page, but that's really okay. I don't tihnk most people will have a hard time figuring out how to get back to the issues page. There is the added benefit that once they have an account, they are all set to become a contributor should they so desire, and their bugs and contributions will all be tied to that account.
Also, not to get too argumentative, but you say that you don't want to force existing contributors to learn git but also say that git and hg are so similar that git users should have no problem using HG. So far the only discussion I have seen indicates that contributors know how to use git today, and if it's easy to convert from git to hg then it should be easy to provide a simple guide to converting from hg to git.
At work, we enforce squash before committing to master, so we have a very clean commit history in master. The downside is that in many cases the rebase that was originally 50 commits should really be several commits, but ends up as 1 commit. As Jens alluded to, this can be addressed by requiring contributors to rebase into a sane branch with commits that make sense (e.g. for feature X, commit 1 is backend added function y, 2 is added unit test, 3 is added UI support, etc...).
Re: Python 2.7 vs 3, this is a psychological thing. We hire a lot of young developers at work, and they tend to gravitate towards the projects that are using the more modern technologies. E.g. if I have an old service using entity framework, .net 4 and mvc + node js, or a service using .net core microservices with a kendo/angular based ui, they want to work on the latter (at least I didn't propose moving the UI to .net core 😊 ).
As a new contributor myself, I would like to bring something to the table. I'm a service engineer by trade, so coding is secondary to my day job, but I am trying to write more code.I was thinking for a start, I would work through Python's own guide for upgrading. To me the following makes sense:
Run the non-ui through the python guide to upgrading which starts with supporting both. Stop short of cutting 2.7 support. This is necessary to upgrade regardless of the UI choice so I think it should come first. Evaluate the UI functions for anything else that can be further abstracted. In parallel, keep up the UI discussion. If we have to port to PyGObject, does it make sense to stick with GTK, or should we looks at other UI frameworks?
Thanks, Derek
________________________________ From: Dan Smith dsmith@danplanet.com Sent: Saturday, June 9, 2018 8:25 AM To: Derek Chauran; chirp_devel@intrepid.danplanet.com Subject: Re: [chirp_devel] Modernizing
I have been thinking about this for a while, but Terrence's API/module & Dan's feedback have spurred me to put it out there.
What are people's thoughts on starting to port Chirp to Python 3/GTK+, and moving to GitHub?
Before I answer further, I'd like to say that I write python3 for my day job, I use git exclusively these days, I contribute to many projects on github (large and small), and maintain several projects there and take PRs from people. I say this to make it clear that I'm definitely not afraid of the unknown :)
Both are things that I think would help encourage more people to develop for Chirp. Most young and enthusiastic developers don't want to work with old versions of a programming language.
Honestly I really don't understand this argument. There is so little (that affects chirp) that differs between 2.7 and 3.x. Unless it's just a psychological thing or something, but.. meh :)
As to the GitHub question, while it may seem like a small thing, I also believe that comfort level with the development process is important to attract developers. GitHub has massive adoption, and most developers I know have some degree of comfort working in git environments, whereas I get blank stares when I mention mercurial.
I get that. I use git exclusively now myself. I understand the desire to appeal to new contributors, but those contributors haven't actually brought anything to the table yet. There are a bunch of contributors that have written and maintain large chunks of chirp code that didn't know another system and learned mercurial to be able to do that. Switching may not be a problem for them, but it's not a zero effort change, and I really (really) want to continue to make things easy for them. I certainly don't want to prioritize the contributors that may exist over those that do. Mercurial is so similar to git that I also really don't understand people that say they don't want to contribute because it requires learning a new (but similar) tool. Learning what you need to write a coherent patch against chirp is like an order of magnitude more work than learning how to hg clone, hg commit, hg email.
Moving to git is also a separate concern from moving to github to me. The two need not be tied together, IMHO.
There are a few discussion points that jump out at me. I'll throw them out there to start the discussion, but I know there are many other points to be made. • No XP support past Python 3.5. I think this is actually a good thing. I have never used XP for anything HAM radio related and it has not held me back. As technology enthusiasts, I tihnk it's silly that many hams still client to an old, unsupported and insecure OS. I have old EF Johnson land mobile radios that i can program from Windows 10 using DOSBox. Given that Chirp is a major part of the amateur radio world, deciding to no longer support an OS that the maker doesn't even support would be a factor in getting people to upgrade.
Well, you can think it's silly but it's a reality. Not long ago I refreshed the build image for Windows and used Windows 7, thinking it was time. The next two days of emails I got from people made it pretty clear that a ton of users still run on XP and so I re-re-built it on XP. I am not a windows user, but the only physical windows machine I have is XP, which is purpose-built for specific tasks, so I get it. It's also the only one I have with a real serial port, which is, quite relevant.
• With Python 3, we get GTK3+. GTK+ has many enhancements that will help with some of the kunkiness inherent in the version of GTK that Chirp is built agianst. (see e.g. GIMP for windows).
No, we don't "get" GTK3, we are "forced" to move to PyGObject. Now, this is not a problem in and of itself, except that it's a big chunk of work that nobody has done yet. If you want to queue up all the changes required to change the UI to use PyGObject, I will happily review it and do the work to make the build image use it. Several people have expressed interest, but none have actually done it.
If this happens, then we can move to Python 3 by default for sure, and allow things up to 3.5 or whatever still runs on XP. I don't think I'm ready to drop support for XP yet, and since I'm the recipient of all the complaints that will come, hopefully that's understandable.
Of course, if Terrence's API idea pans out, then there are many other GUI options for Python 3 (PyQT, Kivy, Tkinter, etc...)
What does this have to do with writing new UIs? There is a very clean seam between the UI and the non-UI stuff. There are routines in the UI that would be re-usable by others, and could easily be brought across that seam for re-use, but that would be very minor compared to the work of actually writing a new UI to meet the level of functionality we currently have. If you're interested in this, please feel free.
• Git is too complex - while this can be true, when it comes to developing on GitHub, there are established patterns and simple commands to accomplish most tasks. This complexity also comes with flexibility. If I am working on a major change in git (say, upgrading from Python 2.7 to 3.6), but I run across a small bug in the production code that I want to fix, git makes it easy to put aside my other changes and fix the quick bug. During my daily workflow at work, I often switch between several branches in a repo, wiith a small set of commands. There are something like 5 commands that I use on a day to day basis with git. (git pull, git push, git checkout, git commit). Conversely, I find the patchbomb process to be a bit convoluted vs pull requests.
I definitely don't understand this. Mercurial and git are extremely similar. Branches in mercurial are a thing, if you want to use them, and you can use the commit workflow instead of mq and patchbomb those the same way. The mq workflow makes a lot of sense for small changes against upstream which are easy to add, remove, update and delete. Patchbomb just emails the commits that mq creates, and you can patchbomb any other commit that you want, if you don't want to use mq.
I've used github extensively, as well as many other similar git-based things. I'm not a huge fan of the PR workflow, the way code gets reviewed (or not) on github, and definitely not a fan of the really nasty commit history patterns that github tends to encourage of people. That said, I use it a lot and can certainly deal with it.
• Git is destructive - This is not really true. In fact, the opposite is true. When you roll back a commit in HG, that commit is gone. In GIT, that commit is still available via the reflog for 30 days. The main repo will be controlled with gated checkins anyhow.
I'm not sure what your point here is. I've never heard this argument, so it definitely doesn't factor into my feelings on the matter :)
• Github comes with its own documentation/hosting system with native support for markdown.
It does, and it works reasonably well for developers. Good luck with the average ham wading through a github repo page to find the docs.
• Python itself is hosted on GitHub.
This isn't really an argument, right? :)
• GitHub makes it easy to share branches, so we can have multiple people collaborate on large projects (e.g. upgrading Python).
For some definition of easy I guess. Since I'm not a fan of that workflow, I'm biased. However, if you're going to undertake the PyGObject conversion, you can certainly import the repo into github for the collaboration process. But, just like if everything was on github, once you're done I'd expect a sanitized commit history with well-formed commits to come out of that and not just "please merge this branch of 500 messy commits". Unfortunately, that's the way people tend to do stuff in github and I do not think that's a good thing.
• Time - moving to GitHub is fairly straightforward. They provide examples of exporting from HG into git. That said, unless Dan wants to (temporarily) hand over control of the repo, it's his time, not mine so I cannot speak for him there. Once that move is complete, again the python work can be staged in a separate brach and worked on as time permits while being set aside for other features that need attention in mainline.
Moving the code and relevant history there is trivial. Even setting up travis to run the tests wouldn't be hard (and arguably would be the major benefit from moving to github in my mind).
Here are other things you didn't cover, which I think are very important:
1. A github repo page is not going to be something the average ham can digest. That means we still need a website for them to land on. It wouldn't make sense to keep using redmine for that, so I/we have to build something else.
2. Related to the above, the docs on the redmine page have to make it to the new page and not just to the github repo.
3. Right now we have code and bugs in the same place. If we move to a github repo, people _will_ file bugs there, but the average ham is not going to be able to create a github account and file bugs there, IMHO. We can't have two places and maintain sanity. I don't know if we can bulk import bug history to github or not, but if we can't then we lose all that history. I can't tell you how many times a week I'm answering direct emails from people working through the very simple process of creating an account on our redmine site so that they can file or comment on a bug. Github makes that not my problem (which might be good), but it also means I don't control it (for helping them) and I think will be more confusing for that level of user, since github is a lot of stuff, not just about chirp. They're very developer-focused, and people are going to be confused about signing up for an account and being presented with their own profile page instead of just going right back to the chirp repo to file their bug.
I would definitely like to have more contributions to chirp, but there will always be more users than developers. Doing what is right by the users is always going to pay off with more adoption, even if it's less desirable for us.
In summary, I'm happy to take contributions for the PyGObject thing if you want to work on it. If you have solutions to the github concerns I have, then I'd be glad to hear them.
--Dan
Jim, Rick, if you've been ignoring this repeat discussion: questions for you at the end.
Derek, passion and snark to follow, please read to the end :)
Hi dan - Thanks for the well thought out responses. To be clear, I am an avid user of chirp first and foremost. I am also not they type of person to complain about a problem without proposing a solution. For me, personally, the main issue with using Chirp is that it doesn't work and feel like a windows app. Things like tab and ctrl+c don't work the way you would expect, and operting on memories in the grid view doesn't work like most windows apps that have grid views. So the upgrading frameworks and python is all about trying to do what's right for the users.
I thought python3 was a psychological thing? :)
The keybindings thing is something we can solve, and moving to GTK3 won't have any effect. I'm not sure GTK3 will make the gridview behave any more natively, but if so, that would be great. It works natively for me on my platforms, and even when I use it on Windows I don't really notice that it's any different, but I know some people have issues with it.
It's also worth noting that I have several little things i have worked on for my suported radios that have not made it back in because I'm a bit daunted by the process (not that they are high demand features - likely I'm one of the very few who cares about scan edges, call channels and settings for an ic2720h).
Re: git/github - I have very little experience with hg (chirp is it), so most of my comments are based on experience with git and reading about hg.
Seriously? I mean, there are a lot of not-even-developers that figure it out all on their own. With all due respect, if you haven't actually gone through the process of generating a patch and sending it yet, I'd like you to do that before you judge it and suggest we all move to the thing you're most comfortable with :)
With all due respect, people show up all the time complaining about our process (or something else), having never submitted a patch and wanting the process to change before they do. People who have actually contributed something have a lot more voice around here than those that haven't. Since a move to github and working on python3/GTK3/whatever-else are relatively separate, maybe you could help work on some of the latter to build some familiarity with what we have? The "I want to contribute, but not until you change everything about how you work to be like I want" sort of attitude really rubs me the wrong way. I know that's an exaggeration of what you've said, I'm just hyperbolizing it for effect :)
To clarify, when I was talking about documentation, I was specifically talking about github.io, not simply the repo docs (and of course Jens' reply comes in as I am writing this saying the same thing). There are utils out there to convert docs from redmine to md/gitlab/etc... including workitems and history. I actually think it's easier to create a giuthub account and report an issue than the current workflow. Currently, the link to issues takes me to a page that shows issues, but ther eis no "new issue" button there. I have to create an account, login and then there is a new issue tab that subtly shows up in the navbar. With github, you provide a link from the main page to issues, there is a new issue button right there, and when you click it, if you are not logged in it opens a popup to create an account or login.
Are you really suggesting that the lack of a "create" button that makes you log in is a major factor for moving our entire platform? I mean, really now :)
We have a "how do I report an issue" FAQ entry and could do plenty to make it more obvious if you really find that to be a struggle. To be honest, I hear more people complain that they can't find the download that they need than anything about not knowing how to report issues, FWIW.
Yes, they may go to a profile page, but that's really okay. I don't tihnk most people will have a hard time figuring out how to get back to the issues page. There is the added benefit that once they have an account, they are all set to become a contributor should they so desire, and their bugs and contributions will all be tied to that account.
Yeah, and again, you're not on the other end of all the emails I get about the process, so you'll just have to trust me that the above sounds very simple to you, as you're familiar with it and clearly much more technically capable than the average bug-filing contributor. I used to get a ton of emails from people who couldn't find the Download link at the top of the page until Tom put a comically-large "CLICK HERE TO DOWNLOAD" icon (which has since been de-comically-ized a bit).
Also, not to get too argumentative, but you say that you don't want to force existing contributors to learn git but also say that git and hg are so similar that git users should have no problem using HG. So far the only discussion I have seen indicates that contributors know how to use git today, and if it's easy to convert from git to hg then it should be easy to provide a simple guide to converting from hg to git.
For someone that knows nothing to learn hg and then convert to git, it's a hurdle. For someone who already knows a distributed SCM and the ideas, it's much less of an issue.
At work, we enforce squash before committing to master, so we have a very clean commit history in master. The downside is that in many cases the rebase that was originally 50 commits should really be several commits, but ends up as 1 commit. As Jens alluded to, this can be addressed by requiring contributors to rebase into a sane branch with commits that make sense (e.g. for feature X, commit 1 is backend added function y, 2 is added unit test, 3 is added UI support, etc...).
Yep, I know you can do this, and document it for people that read them before submitting. I'm just saying that the workflow tends to generate that behavior, which is definitely does. It's manageable and not insurmountable.
Re: Python 2.7 vs 3, this is a psychological thing. We hire a lot of young developers at work, and they tend to gravitate towards the projects that are using the more modern technologies. E.g. if I have an old service using entity framework, .net 4 and mvc + node js, or a service using .net core microservices with a kendo/angular based ui, they want to work on the latter (at least I didn't propose moving the UI to .net core 😊 ).
On the other hand, chirp deals with relatively legacy technology anyway, in the form of crusty old radios. Maybe we're missing a huge batch of young, enthusiastic people that want to contribute and just can't get over the fact that we're not on github, but I just don't get that feeling.
As a new contributor myself, I would like to bring something to the table. I'm a service engineer by trade, so coding is secondary to my day job, but I am trying to write more code.I was thinking for a start, I would work through Python's own guide for upgrading. To me the following makes sense:
Run the non-ui through the python guide to upgrading which starts with supporting both. Stop short of cutting 2.7 support. This is necessary to upgrade regardless of the UI choice so I think it should come first. Evaluate the UI functions for anything else that can be further abstracted. In parallel, keep up the UI discussion. If we have to port to PyGObject, does it make sense to stick with GTK, or should we looks at other UI frameworks?
If you pursue the PyGObject thing, I think you can do that without python3-ifying everything if I'm not mistaken. That might be a path worth going down first just to decide if it's worth doing that or going with a different framework. If you sanitize the non-UI code and then the UI replacement never materializes (and let's be honest, it's a lot of work that may very well never happen), then you've done that work for relatively little gain. But, it's your time and thus your call. You're more than welcome to do that on github if you like, but it would sure build a lot of karma if you used it as an opportunity to bolster your list of grievances with mercurial :)
On the git and/or github conversation, I really want to hear from people like Jim and maybe Rick. Jim has contributed a ton to chirp, and if he was less likely to work on stuff if it was in git, then that's a non-starter for me. Rick has (I think, not sure) been struggling with the SCM process in general, so I'd like to hear if he's more comfortable with git, or if he'd be okay pivoting to something else with a slightly different workflow. If these guys are okay with switching and learning something else (or with trying to continue using mercurial from a mirrored tree, which I could maintain), then we could think about moving to git.
I'd like to maybe separate the github discussion from git, as I do think they're different things. I really feel strongly about the concern for users having to use github for filing bugs, but I can disable that on the repo to avoid forking the bug history for the moment. And I guess I could respond to patches on the ML and PRs in parallel, at least as a trial. Would that be a reasonable step for the github-loving crowd?
--Dan
On the git and/or github conversation, I really want to hear from people like Jim and maybe Rick. Jim has contributed a ton to chirp, and if he was less likely to work on stuff if it was in git, then that's a non-starter for me. Rick has (I think, not sure) been struggling with the SCM process in general, so I'd like to hear if he's more comfortable with git, or if he'd be okay pivoting to something else with a slightly different workflow. If these guys are okay with switching and learning something else (or with trying to continue using mercurial from a mirrored tree, which I could maintain), then we could think about moving to git.
I got my Baofeng UV-5R back in April of 2012. I started using CHIRP when the initial support for the UV-5R was added in May or June of 2012. the same year. I for get how or why, but soon after I started using CHIRP, I mapped out all of the unsupported settings of the UV-5R factory software and offered a copy to Dan. Dan replied with some snippets for Python and 2 or 3 links reference material for developers on the CHIRP website and asked if I thought I could do it myself.
I am not a computer programmer. I did some BASIC programming back in the days of the COMMODORE PET, but I have never had any formal training in computer programming. I didn't know anything about Python or Mercurial. Even still, I decided to give it a go. With some help and a lot of patience from Dan, I submitted my first patch on December 22, 2012. Five years later, I am just starting to get comfortable with Mercurial. I am still a hack with Python.
I am not opposed to change. But if git/github thing requires me to take another 5 years to get comfortable, it might be time for me to retire. But like before, I'd probably give it a go.
Jim KC9HI
participants (4)
-
af5mi＠yahoo.com -
Dan Smith -
Derek Chauran -
Jim Unroe