I can't answer all of that, but I can give you the notes I've put together so far from what I've been able to figure out about how our process works and what will need to be done to build AutoKey. This is a work in progress and you're getting my sloppy copy here, but maybe some of it will be useful:

Our Git Flow workflow:

1. Use this structure for the repository:
   • master has been deployed as the current release and can currently be deployed.
   • develop is branched off of master and is intended to be used for active development.
   • beta is branched off of master and is intended to be used for all commits from develop that we want to keep.
   • Features are worked on or created on feature branches off of the develop branch and are merged into the develop branch when each feature is finished.
   • Hotfixes (critical changes) are done on hotfix branches off of the master or develop branch that are merged into the master or develop branch when each hotfix is finished.
2. Do the development on feature branches off of the develop branch or do development on the develop branch in an AutoKey fork.
3. When you're satisfied with the develop branch and are ready to create a beta release:
   1. Announce a development freeze to the developers.
   2. Update the CHANGELOG.rst file on the develop branch with the new beta release version and a new, empty Develop section at the top.
   3. Update the Version line in the PKG-INFO file on the develop branch, if applicable.
   4. Change to the beta branch: git checkout beta
   5. Ensure that the beta and master branches are synchronized by doing a hard reset of beta'' to master, removing all staged and unstaged changes from beta, resolving conflicts in favor of master, and updating the beta tip (its most recent commit) to the commit at the tip of the master branch, making beta exactly the same as master**: **git reset --hard master''
   6. Use cherry-pick or merge to bring any or all commits that we want to include from develop onto beta.
   7. Tag the beta branch with a beta release version number.
   8. Push the change to the remote repository: git push
   9. Put the beta files onto GitHub for download.
   10. Announce the beta for testing by others.
4. Pick one:
   • If you're not happy with beta, return to to step 2 above and continue development.
   • Or, if you are happy with beta, create an AutoKey release:
     1. Change to the master branch: git checkout master
     2. Back up the master branch in your stash so you can recover if it all goes badly: git stash
     3. ????? Wipe out all differences in the working tree on the master branch (ignore everything up to now) (I believe this gets rid of the X commits ahead and X commits behind messages so you'll start clean): git reset --hard
     4. Merge beta into master, favoring beta for all conflicts (make master an identical copy of beta):
        1. Change to the master branch: git checkout master
        2. Merge beta into master using beta's's history (resolving all conflicts in favor of beta): git merge -s theirs beta
        3. Enter your commit message and save when prompted.
     5. Update the VERSION line in the common.py file on the master branch with a new AutoKey version.
     6. Create an AutoKey release by tagging the master branch with a version number on git or GitHub.
     7. Update the VERSION line in the common.py file on the develop branch with a new beta version.
     8. ????? Do a hard reset to wipe out all differences in the working tree on the master branch (ignore everything up to now): git reset --hard
     9. ????? Do a hard reset to wipe out all differences in the working tree on the develop branch (ignore everything up to now): git reset --hard
     10. Push the changes to the remote repository:
         1. Change to the beta branch: git checkout beta
         2. Push the changes to the remote remotisoty:git push
         3. Change to the develop branch: git checkout develop
         4. Push the changes to the remote remotisoty:git push
         5. Change to the master branch: git checkout master
         6. Push the changes to the remote remotisoty:git push
     11. Put the AutoKey files onto GitHub for download.
     12. Announce the new AutoKey release to our contacts at the various distributions.
     13. Return to step 2 to begin work on the next release.

Build AutoKey

If you've got what seems like a good working copy of the code, it's time to build it into files that can be installed on a machine so you can try it out and see if it works.

TODO: Find out if there's any difference between doing the build from the zip file, the way we do below, and doing it from a cloned copy of the fork.
TODO: An alternative to the following instructions may be to run autokey/debian/build.sh to build the .deb files, but I'm thinking that will be run automatically when following the steps above. I'll update this once I do a successful build.

1. Open your virtual machine.
2. Open a browser inside the virtual machine.
3. Go to the AutoKey repository's main page on GitHub.
4. Choose the branch that you'd like to build.
5. Click the Code button.
6. Click Download ZIP from the drop-down menu.
7. Extract the zip file, creating a directory that contains the contents of the repository.
8. Open that directory in a terminal window.
9. Pick one:

• Install AutoKey:

  pip3 install .

• Build AutoKey:
  1. Build the packages in the parent directory of AutoKey:

     dpkg-buildpackage -us -uc

  2. Test the build:
     1. Change to the parent directory:

        cd ..

  3. Install the GTK version:

     sudo dpkg --install autokey-gtk_<version>.deb autokey-common_<version>.deb
     ```					```

  4. Install the Qt version:

     sudo dpkg --install autokey-qt_<version>.deb autokey-common_<version>.deb

  5. Install any missing dependencies:

     sudo apt install -f

  6. See if the build works, where it puts AutoKey, and any messages/errors it generates.
  7. If everything works, copy the .deb files it produced to a clean virtual machine and repeat steps c through f to see if they install and work properly there.
  8. ??? I GOT THIS FROM THE DEBIAN WEBSITE ??? If everything is working and the build is satisfactory, sign the .dsc and .changes files with your private GPG key using the debsign command. You'll need to enter your secret pass-phrase twice.

Getting this down will be a major infrastructure enhancement.

AFAIK, the only packaging we do is our local debs and tarballs - which I believe are already automatically generated when a release tag is made and the PyPI/pip stuff. (IDK how that stuff works.)

Although there are two aur packages. I don't think AutoKey makes them. Bluedrink9 was listed as their maintainer last I looked.

There are other packages. RPM and DNF and whatever OpenSuse does come to mind, but they are all done by distribution team packagers (which is also the case for Debian who don't use ours). I think there's even a BSD package.

I'm pretty sure distros want full control of the packages they include, so our efforts should be to ping them when a new release occurs.

Two Debian packagers have communicated with us in the past, but neither are still involved with AutoKey. (Luke Faarone (probably misspelled) and Anthony Fok) Luke was only involved with the original branch of the project. Now the link shows "Debian packaging team" or some similar generic designation.