@GaryGriffin made a good point that several addons PRs are in the wrong branch to be eligible for Merging into the 5.2 branch.
In another conversation, @Nick-Hall has said that the Master branch in gramps-project/addons-source serves no purpose. So, after migrating open PRs in the Master branch, could that branch be removed?
And since the 5.2 registering is greatly expanded, could all the ready-to-merge PRs in the 50 and 51 maintenance branches be migrated to maintenance/gramps52? Should all the stale Work In progress PRs could be migrated to a 53 branch?
5.2 compatibility creates challenges because some Attributes were made valid in all Plugin types and others added that are specific to certain Plugin types. Unfortunately, the 5.2 (and earlier) Registration module is not at ALL fault tolerant of unrecognized Attributes for a plugin type.
The list of branches is a bit cluttered too. It has some personal branches that seem like they could be archived too.
I wondered if there were applicable workflows for these issues. Perplexity gave some interesting responses. But they were a page or two longā¦ too much to include here.
A prompt for Perplexity.ai for some strategies for cleaning up
In GitHub, what are the best practices for managing and archiving dead branches of code? Iām looking for a workflow that would effectively āfreezeā these branches and remove them from the active branch list, simplifying choices for new contributors. Please provide strategies in a logical order, starting with preservation methods (like tagging or archiving) before discussing deletion. Also, include any automated solutions using GitHub Actions that could help with this process.
a followup prompt someGitHub Actions workflows to move open PRs:
In the āGitHub Actions to automateā include a process to migrate open Pull Requests to the active branch.