move bugs to github?

[Nico Schlömer]

Right now, mixxx development seems somewhat fragmented. The code is on GitHub [1] (or not? [2]), bug reports are on launchpad [3]. This prevents useful usage patterns like the automatic closing of issues, but most of all it deprives users and developers of a contemporary user interface. Compared to its impact 15 years ago, nowadays launchpad plays virtually no role anymore as a code-hosting platform [4]. The development of launchpad itself is cut down to maintenance for number of years now [5].

Perhaps it's time to consider moving the development entirely over to GitHub.

[1] https://github.com/mixxxdj/
[2] https://code.launchpad.net/mixxx
[3] https://bugs.launchpad.net/mixxx
[4] https://github.com/nschloe/popular-on-stackoverflow#code-hosting-platforms
[5] https://github.com/live-clones/launchpad/graphs/contributors

[Daniel Schürmann (daschuer)]

This topic is under considerations.
This is not an easy decision, because the risk of loosing data.

We have set up a wiki page to collect pro and cons. Feel free to add missing points if there are any https://www.mixxx.org/wiki/doku.php/launchpad_migration

Thank you for the nice link [4] we will switch to CMake for Mixxx 2.4 by the way. The build system with the top number of questions. Is this a good sign?

[Nico Schlömer (nschloe)]

Aha, thanks for the pointer!

> Is this a good sign?

YES. If you're coming to a software project from the outside and you see obscurities (scons, launchpad, sourceforge), you're less likely to dive deeper.

[Nico Schlömer (nschloe)]

Okay, I read a bit on the Wiki and made some contributions. My god, what did I read. Under advantages for launchpad, one finds

> Can run our own instance (if ever GitHub closes or decides to charge)
> Open-source
> Would (eventually) suit us perfectly

It would eventually suit us perfectly, because we're writing the bug tracker ourselves? How about implementing our own bug tracker from scratch in assembly, it would suit all our needs and also be super efficient!

And for everyone who finds launchpad isn't obscure enough: Apache Allura, Tuleap, even JIRA! Goodness gracious. Only sourceforge is missing from the list.

No wonder the discussion isn't going anywhere after two years. This kind of decision-making really isn't for me. :)

[Uwe Klotz (uklotzde-deactivatedaccount)]

Listing all possible advantages and disadvantages is a prerequisite for making an informed decision. Even if some of these arguments might seem obscure to you, please don't discredit those who have spend time to collect them.

What seems easy and straightforward at first sight might be more complex than expected. We should better consider all possible implications before starting a migration.

[Be (be.ing)]

We have had lots of discussion about this on Zulip:
https://mixxx.zulipchat.com/#narrow/stream/109122-general/topic/GitHub.20Issues

I completely agree, there is no justification for continuing to use Launchpad. It is awful, out of date software that turns people away from using the bug tracker, myself included.

[Nico Schlömer (nschloe)]

> Listing all possible advantages and disadvantages is a prerequisite for making an informed decision.

Fair enough. Now you've listed all the pros and cons. What happens next? What's the procedure here?

[Uwe Klotz (uklotzde-deactivatedaccount)]

From the discussions there is trend for using GitHub. But now someone must come up with a concrete plan how such a migration could actually work in conjunction with a precise description of all consequences. You still need to consider alternatives, e.g. to migrate all the data or to leave everything on Launchpad behind (and how to not lose all this knowledge).

[Nico Schlömer (nschloe)]

It is my experience that, as soon as you enable issues on GitHub, no user will bother with launchpad anymore. More so if you don't advertise it on the website.
It's then a matter of taste of the core developers if the launchpad bugs need to be moved or not. I personally wouldn't bother with it. A move helps you get rid of launchpad right away, but can be complicated as you point out correctly. Fading it out seems much easier, and worth having to switch back and forth a little longer.

[Nico Schlömer (nschloe)]

Ping.

[Daniel Schürmann (daschuer)]

Why are you pinging here? We will not just enable GitHub issues, because of the missing bug workflow. First we need to decide for one, which is basically a set of labels and colors.
Then we need a contributor who dies the migration.
Do you have interest to jump in here?

[Nico Schlömer (nschloe)]

> Why are you pinging here?

I had had the impression that the discussion was stalled.

> First we need to decide for one, which is basically a set of labels and colors.

Aha. Well, what are we using on launchpad right now?

> Then we need a contributor who dies the migration.

I argued above that it might not be necessary to migrate the existing bugs from launchpad to github. Key points:

  * Deciding on a migration strategy has prevented the switch from happening for approx 2 years now, so for something to move, things have to simplify.
  * Leaving the old bugs on launchpad is a certain inconvenience, but so is having to keep launchpad as a main bug tracker. And that gets more outdated every month.
  * Even when leaving launchpad open, users will hardly post bugs here if there's the GitHub alternative.
  * The remaining relevant bugs need to be tracked on launchpad, so there'll be switching forth and back. That's not worse than what's currently done though.

What do you think about it?

[Daniel Schürmann (daschuer)]

Switching between two bug tackers is worse than sticking with Launchpad. Managing 1300 GitHub issues will be a pain without a strikt tagging strategy.
However this bug report is the wrong place to discuss details. You may share you migration strategy on the Wiki or discuss it on Zulip.

[Nico Schlömer (nschloe)]

> Switching between two bug tackers is worse than sticking with Launchpad.

I disagree here, see above.

There are some tools for migrating bugs [1,2], but even those are almost ten years old and not working anymore. (I tried both.) It seems we'll have to write our own migration scripts.

[1] https://github.com/johnf/github-issue-importer
[2] https://github.com/termie/lp2gh

[Nico Schlömer (nschloe)]

Here is how inkscape handled their move to GitLab three years ago:
```
Martin Owens @doctormo · 1 year ago
Some work was done on lp to gitlab migrations, (https://gitlab.com/doctormo/lpout) but the main issue is an issue that effects the GitHub importer too, which is one of user account information being scrubbed from issues and other meta information.

Inkscape only uses launchpad for bugs and will likely decommission launchpad bug tracker WITHOUT a transition. There are too many bugs going back too far for it to make sense and the old issues tracker will be kept as an archive, while new issues in GitLab will be focused per team. This is our movement plan.
```
https://gitlab.com/gitlab-org/gitlab/-/issues/22600#note_215163122

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/9823