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
In redmine we used projects which logically grouped areas on functionality (like ansible or remote execution), but in github issues seem to be tied to a specific repository. Would that mean that a user going to report a problem with ansible would have to know whether to report it against foreman_ansible or smart_proxy_ansible?
Should we maybe also think about moving to gitlab? They have issue boards, wiki, and other tools, too. And, I think some of the downstream projects are using gitlab, too - so maybe easier to share pipelines. But, it would be a lot of work - for sure.
That’s a good point. While Ansible project in redmine made it easier, I’d say a user still sometimes had a hard time to tell, which project to report the issue into. Keeping issues per repos would make this harder.
I looked at the issues reported in 2026 and out of 131, around 17 authors were community users (majority is from devs familiar with repo structure). That’s not the number we can ignore.
The best course of action is having a one place to open an issue at and then have it correctly assigned (by the author if possible, automatically, manually). That would work well if we had a monorepo with all projects in directories. Then we could use labels/projects for organizing (with the permissions caveat). Or we could create small monorepos per projects, e.g. ansible repo combining foreman-ansible, smart-proxy-ansible and hammer-cli-ansible.
I don’t want to get to implementation details nor side-track this conversation too much, I wanted to say we have options if we move to github.
Github has wiki too, issue boards are probably projects (I’m not that familiar with gitlab), are there some unique features of gitlab worth exploring? Cause I’m mostly worried about the thing you said at the end - a lot of work for sure
With permissions correctly setup you can move issues around. So yes, it may be a bit more work then just changing a field like with the current setup in redmine, but should be doable. And I assume we will have labels synced over the org, so we should not lose anything by moving an issue around.
And this would be also possible for an issue really misplaced like “I have no idea where the problem is, so I choose Foreman”, perhaps because of permissions not by everyone, but at least someone could do it. Not sure how often we see something like this in redmine nowadays.
We can create a new repository, like github.com/theforeman/issues that we use as the entry point. IIRC we don’t need to move issues around because you can link up issues between repositories, but we can if that makes it easier.
