Today we have a situation where some repositories track their issues in GitHub where some of the more core repositories use Redmine. This is largely historical where GitHub issue tracking was too limited for release management.
Today release engineering relies on Redmine for a few things, most notably it’s used to generate the release notes and track release blockers. Nothing that can’t be rewritten.
For the release notes we can look at towncrier, which is also used by the Pulp project.
The release blockers could also be tracked on a board. There’s already Foreman Releases · GitHub so perhaps it’s already not really an issue (pun not intended)?
There are 2 outcomes I’d like to get:
Do we even want to use GitHub issues?
What do we use Redmine that GitHub can’t do (today)?
To add to the use of redmine in our projects, Katello uses it to track which commits need to be cherry-picked at release time. We set the target version on issues, and then tool belt compares version information in the specific version config files with what is set to that release (or older) in redmine. We have a nice process of triaging issues weekly which lets us not think about the issue versions until it’s time to cherry-pick.
I don’t think this process is tied to redmine in any way, but we’d be looking for a drop-in replacement for target version tracking.
Foreman itself has a different policy: cherry pick ASAP. It has the challenge that in advance you can’t really set the target cherry picks (like Redmine can). Pulp uses patchback.
I recently contributed to an open source project, and I had a good experience with the process they used. I can show this and we can get some ideas from it. The k8s autoscaler repo[1] uses labels for many things that we would display on redmine.
When opening my PR I did not have to leave GitHub at all I would simply add the things needed in the PR description and a contributor would do a slash command that would handle whatever was needed.
Here is my PR[2] for example, it includes release notes, what kind of issue, what it fixes and etc. Compared to opening a PR and having to leave or even create an account on redmine. I enjoyed this experience much better.
Maybe we could take some ideas from this? K8s seem to use this process along all there repos.
How would we lock ourselves with Github further? Couldn’t we migrate off of it like we can now with Redmine?
Personally I’d prefer
unification across all the subprojects, using one issue tracker ease up cross repo collaboration
use github because that’s where we spend our time already for code contributions, PR reviews, quality assurance and various other automation through github actions. Having issues at hand doing these activities seems a good step
not introducing another tool and keeping some subprojects using github issues
