Project

General

Profile

Actions

ChirpNextBuild » History » Revision 16

« Previous | Revision 16/31 (diff) | Next »
Dan Smith, 12/19/2022 04:30 PM


About CHIRP-next

The CHIRP project is working on a major project to re-write some of the core components necessary for longevity in the years to come.

This page explains the chirp-next build, why it is necessary, what to expect, and how you can help.

Why is this necessary?

When CHIRP started in 2008, it was based on two core pieces of modern-at-the-time software, Python 2.x (the language) and PyGTK (the GUI toolkit). Since then, the Python development team defined Python 3.0, which is an evolution of the language, but with many incompatible changes, specifically in the areas that affect CHIRP. Further, the developers of PyGTK decided to mothball the project and not ever move to support Python 3. This left CHIRP in a tough spot, as moving to Python 3 not only required significant changes to almost every radio driver (of which there are about 350) and basically a complete re-write of the GUI at the same time. There are various shims and hacks for temporary compatibility that we could have (and in some cases, did) explore, but the end result was the same: something had to change.

Mac and Linux users are likely painfully aware of the increasing difficulty in running CHIRP that has been creeping up for the last few years. Python 2.7 was officially End-of-Lifed in 2020, and many Linux distros dropped support around then. Apple held on a little longer, but has removed Python 2.7 from MacOS now. Windows' users have been largely unaffected directly by the deprecation issue, but developers have an increasingly shrinking set of platforms they can use to continue CHIRP development.

How you can help

Perhaps the biggest hurdle to this transition has been the radio drivers. CHIRP supports hundreds of unique radio models, and in many cases, those were developed with borrowed radios, or radios that a developer owned at the time, but no longer has. Rewriting those drivers and testing them with real hardware is an enormous task for an all-volunteer project like this. To get to where we are today, we had to find and test as many real radios as possible. Developers borrowed, bought on eBay (yes, really), and dug out of the woodwork as many as possible, but there is (and likely will be) a long tail of models that we're looking for.

Re-writing the GUI also brings many challenges, as this is largely maintained by one person in the development team. A re-write gives us an opportunity simplify, eliminate complex features that are rarely used, and also make CHIRP behave a little better on each of the platforms. Instead of being "A Linux program that runs on Windows," we have also used this opportunity to try to make it feel more like a native app on each of the platforms we support. See ChirpNextBuildChanges for details on some of the larger GUI changes.

We now need to engage the larger community of users, power-users, and enthusiasts to try to close the gap on radio testing, GUI testing, etc.

1. Test obscure radio models

If you have one of the radios on the list of un-tested models, please consider giving it a try and filing a bug. Even if it works fine, please let us know so we can mark it down. If it doesn't, it would be great if you would be willing to test some changes to help us get it fixed. If it's an older radio, consider donating it to a developer (this is the most helpful thing you can do).

When filing a bug, please consider:

  1. Please search or consult the list of bugs to see if your issue is already reported
  2. Be sure to choose "next" in the Chirp Version field so we know this is related to the new build
  3. Make sure to tell us which radio you're reporting. Both in the subject of the bug, but also in the "Model Affected" box
  4. Make sure to update the "Platform" field so we know which system you are using
  5. If you are able to download and save an image of the radio, please attach it
  6. If the problem occurs while changing memories or settings, please include detailed steps to reproduce it.
  7. Perhaps the most important thing is to include your debug.log. Use Help > Show debug log location

2. Further test well-supported models

We attempted to "smoke test" converted drivers for the new platform, but it's possible that bugs still lurk in strange configurations. Even if you only have radios that have already been tested, we welcome more comprehensive tests. Note: if you find a bug, it would be helpful if you can test the same issue on the legacy build and include in your bug report whether or not it's broken there, or only in the new build.

When filing a bug, please consider:

  1. Please search or consult the list of bugs to see if your issue is already reported
  2. Be sure to choose "next" in the Chirp Version field so we know this is related to the new build
  3. Make sure to tell us which radio you're reporting. Both in the subject of the bug, but also in the "Model Affected" box
  4. Make sure to update the "Platform" field so we know which system you are using
  5. If you are able to download and save an image of the radio, please attach it
  6. If the problem occurs while changing memories or settings, please include detailed steps to reproduce it.
  7. Perhaps the most important thing is to include your debug.log. Use Help > Show debug log location

3. Poke around with the new GUI

The GUI is all new from scratch, so it is likely to have bugs. If you find something, please report it. If there is some feature you consider to be missing from the new GUI that was present in the old one, we want to hear that too. Please understand that we will probably have to prioritize bugs over features for some time to come, but your feedback is still valuable. Please check the list of requested features before reporting one.

Things that appear to be GUI bugs can often be specific to a radio driver, so please try to follow the same instructions for GUI bugs as well:

  1. Please search or consult the list of bugs to see if your issue is already reported
  2. Be sure to choose "next" in the Chirp Version field so we know this is related to the new build
  3. Make sure to tell us which radio you're reporting. Both in the subject of the bug, but also in the "Model Affected" box
  4. Make sure to update the "Platform" field so we know which system you are using
  5. If you are able to download and save an image of the radio, please attach it
  6. If the problem occurs while changing memories or settings, please include detailed steps to reproduce it.
  7. Perhaps the most important thing is to include your debug.log. Use Help > Show debug log location

4. Donate money or radios

One of the hardest things of this process has been re-surveying all the supported models to make sure we get their drivers fixed for the new platform. A few of us have a large collection of radios with which to test, and even still, it's a fraction of what is needed. Some of us trawl eBay and other forums looking for older models (sometimes with damage) we can purchase to close a gap, but that's not really sustainable for a volunteer-run project. Donating money (links on the Download page) to help with these activities, or even better, an old radio that you no longer use, but could help us close a gap for someone that still does is very helpful.

What to expect for the future

In 2023, the legacy builds of CHIRP will be frozen for development. This means only some bug fixes will be backported and no new features will be added. At some point the current builds (called "chirp-daily") will be renamed to "chirp-legacy" and it will stop being released.

What is now "chirp-next" is what we want all users to be running as soon as possible, and is what will receive almost all of the development effort going forward.

What if my radio does not work in CHIRP-next yet?

Please file a bug, attach a debug.log, and a radio image if possible. For the time being, you can still use the old legacy build for radios that aren't supported properly in the newer builds. If you're on Windows, consider installing the new version with the installer, and keeping a standalone (the .zip download) of the legacy build around for radios that need it. Mac users can keep both copies of the .app around in a similar way, just rename one of them to make it easier to tell them apart.

Updated by Dan Smith almost 2 years ago · 16 revisions