Pulp3 Problem Tracking: Proposed move to Github Issues

Hello Pulp Comunity!

As you know, Pulp currently relies on the Redmine instance at pulp.plan.io for recording issues, stories, and tasks. This has served us well for a number of years, but comes with a number of downsides. As a result, we’ve been considering the possibility of moving issue-tracking from plan.io into Github issues.

This isn’t a new discussion, and was far enough advanced to have been a topic at PulpCon 2020, “Leaving Redmine for Github Issues” You can read details of the proposal, various pros and cons, as well as responses to some of the potential problems, in that document.

Post-PulpCon, more thought on the specifics happened and was documented in “Github Issues Migration Plan”, with specific steps identified. In addition, several of the smaller/newer repositories under the Pulp project started using Github Issues in preference to Redmine in order to get a feel for the realities of potential benefits/drawbacks. These Pulp repositories include

As a result of this experience, the team is now contemplating moving the remaining Pulp3 repositories out of Redmine and into Github Issues. We hope this will make it easier for people to open and follow up on problem-reports, in an environment that is more familiar to more people than Redmine is. It will also allow us to have a single answer for “where do I report problems,” instead of the current situation of “it depends on what project you’re talking about”.

Before we push The Big Button - we’d like feedback from the community. The proposal was received well at last year’s PulpCon, but it’s been a year, there are new people involved in Pulp, and we’d like to hear everyone’s input on this proposal.

Thanks for reading this far! We’d love to hear from you on this; feel free to add your thoughts as replies to this thread!

Grant

References:

5 Likes

My recollection (which is often akin to swiss cheese so be warned) is that we pretty much decided to move off redmine and onto Github Issues. We even put the work onto a few sprints only to remove it as we identified repeatedly that we didn’t have the bandwidth to actually migrate. So I imagine that’s going to be the biggest or one of the biggest challenges.

I’m hoping just to expand upon your point here to shed light on the downsides from a user perspective.

I think the document ggainey linked to does a good job listing them:

1 Like

I believe the script needs some tweaks, but this is what I got so far:

3 Likes

Lookit all those issues! Woohoo!

We prob want to think about the redmine-label-to-tag mappings, instead of letting the tool invent new ones for everything it finds. But this is great!

2 Likes

pulp-operator and pulp-npm were migrated today

1 Like

I did more experiments today,
and addressed the labels and comments issues

Note: I added random colors for the labels, if you have any preference, please let me know!
I intend to migrate pulp_ansible tomorrow (Nov 17)

2 Likes

Holy cow, that is much nicer! I don’t have much of an eye for color, so I won’t comment - but I def like the list here, nice work!

just finished the first “real” migration on pulp_ansible:

it gets pretty spammy!

for having pulpbot to create the issues, we moved redmine2github to pulp org:

For migrating, it is just triggering the workflow:

2 Likes