Skip to content

Launchpad Migration

Be.ing edited this page May 9, 2020 · 85 revisions

Problems with Launchpad Bugs

Many people have expressed frustration with bug tracking on Launchpad. This is a place to enumerate the problems so we have an objective list when comparing alternate solutions.

Note that Launchpad is open-source, so it is possible for us to directly improve it. (See below.) It also now supports Git repositories and has a Web services API.

(Discussion on the forum.)

  • Login process is complex: it is a multi step process and the platform keeps asking about showing some username The Ubuntu One registration/login only asks for your name, E-mail address and a password.
  • No formatting
  • Can't edit comments
  • They can be hidden on bugs though.
  • E-mail notifications are slow
  • There is an intentional 5-minute delay so that modifications done close together are sent in one message. Beyond that, running our own instance could fix this.
  • "Wishlist" designation is mutually exclusive with a priority designation, making it impossible to prioritize feature requests
  • Can't @mention people
  • Posting code and screenshots requires attaching a separate file that isn't displayed inline in the conversation.
  • Can't make templates for bug reports (e.g. to have people attach mixxx.log in the initial report)
  • No integration with the code review system (side effect of no longer hosting code in LP)
  • Yet another account needed. (Now six total: forum, Freenode, wiki, Launchpad, GitHub, mailing list)
  • OpenID Connect (which uses OAuth) would be a good solution to this in general. See bug #1732715.
  • Run by Canonical, which does not have the greatest track record
  • Development of Launchpad has stagnated slowed in recent years. https://github.com/live-clones/launchpad/graphs/contributors
  • LP had its staffing heavily cut a few years back, but there are still a couple paid full-time developers working on it -- and several major features that have been developed since that cut.
  • launchpad, sourceforge, savannah once played and important role in OSS, but are now rather niche. New users and developers are less likely to be familiar with it, and thus less likely to interact with the platform.
  • No integration with the source code on GitHub. Automatic PR/issue interactions not possible.

Possible solutions

List of Application Lifecycle Management suites

Comparison chart of different project management software packages on Wikipedia

GitHub Issues

Many have suggested using GitHub's issue tracker since it naturally integrates with its code review system.

Migration tools: http://lp2gh.readthedocs.io/en/latest/moving_issues.html

Advantages

Disadvantages

  • Doesn't explicitly support rich states other than just open/closed
  • Using labels for this is just a workaround and might become confusing.
  • Not possible to link related issues
  • Not possible to specify different kinds of relationships (parent/child, predecessor/successor, duplicates, etc.)
  • Someone needs to commit to managing migration
  • Closed-source
  • Company is not very responsive to community feature requests and has no public issue tracker for their server software
  • Requires nonfree client-side JavaScript

GitLab

https://about.gitlab.com/ https://blueprints.launchpad.net/mixxx/+spec/gitlab-migration

Advantages

Note that for public open source repositories, the GitLab.com hosted service has all the features of the paid proprietary Enterprise Edition Premium server software.

Disadvantages

  • Write access to GitLab wikis is coupled with write access to source code, so we still need to run our own wiki. https://gitlab.com/gitlab-org/gitlab-ce/issues/19798
  • Someone needs to commit to managing migration
  • Has had issues with page load speed and uptime in the past but has improved lately and they're continuing to work very hard on this
  • Some features only available in paid Enterprise editions for self-hosted server software. https://about.gitlab.com/products/

Improve Launchpad

https://dev.launchpad.net/

Advantages

  • Very good bug tracking and release management features
  • No need to migrate
  • Can run our own instance (if ever GitHub closes or decides to charge)
  • Open-source
  • Would (eventually) suit us perfectly

Disadvantages

  • Maintaining our own bug tracker would be an enormous drain for Mixxx developers that would be better spent developing Mixxx

Apache Allura

http://allura.apache.org/

Advantages

  • Integrated code, wiki and tickets/issues
  • Can run our own instance (if ever GitHub closes or decides to charge)
  • Open-source

Disadvantages

  • Must run our own instance (no pre-hosted environments, though possibly from third party)
  • Looks like old SourceForge
  • Indeed, SourceForge (used to?) use(s) it
  • Need to migrate data from three different systems
  • Someone needs to commit to managing migration

Tuleap

https://www.tuleap.org/

Advantages

  • Complete integration (code hosting & versioning with Git, code review, bugs/tickets, docs/files, CI/Jenkins, project management, collaboration)
  • Can run our own instance (if ever GitHub closes or decides to charge)
  • Open-source

Disadvantages

  • Must run our own instance to avoid charges
  • Manual test management is only available in the paid version
  • Must also run Gerrit for code review functionality, Mattermost for chat
  • Someone needs to commit to managing migration

JIRA

from https://www.mixxx.org/forums/viewtopic.php?f=1&t=9425&start=10

Jira seems to be popular for open source projects and free Jira hosting is available for public open source projects.

It's a far better issue tracker than what GitHub offers. Someone wrote about porting issues fro Launchpad to Jira: https://mariadb.org/scripts-for-migrating-bug-reporting-from-launchpad-to-jira/

QT uses Jira https://bugreports.qt.io as well

Advantages

Disadvantages

 * Source Code available for review only
 * Not FOSS

BitBucket

It has a issue tracker similar to Launchpad but not that complicated the Jira. It combines code hosting, code review and issue tracking in the same was as GitHub does.

Example https://bitbucket.org/tortoisehg/thg/issues?status=new&status=open

Advantages

Disadvantages

 * Source Code available for review only
 * Not FOSS

Selected solution: GitHub issues

We have selected GitHub issues, because our source code lives on GitHub and we want to have the benefit of the integration of source code repository and bug tracking.

Proposal daschuer

Workflow

We will not be mirroring Launchpad'​s states on GitHub. We will be using a simplified workflow:

New Bugs are created by the reporter without label, no expiration, whining after 14 days.

A reviewer classifies the bug with one STATUS label and with one IMPORTANCE labels to stop whining.

  • STATUS:INCOMPLETE - Responds from the reporter is required, expiration after 60 days
  • STATUS:OBSERVATION - Bug-report is complete, but no one has been able to reproduce the issue or shares the opinion, expiration after one year.
  • STATUS:CONFIRMED - One else is able to reproduce the bug or shares the opinion, issue is waiting to be adopted form a contributor, no expiration.
  • STATUS:WONTFIX - A valid bug report, which will not be fixed for some reasons described in the comment. Close Bug
  • STATUS:INVALID - Observation error or support request. Close Bug
  • IMPORTANCE:BLOCKER - If a Blocker is on a Milestone, the Milestone cannot be released this is the only priority state
  • IMPORTANCE:PATYSTOPPER - For things like crashes or other things that makes the crown stop dancing
  • IMPORTANCE:REGRESSION - can be added in addition if a previous working feature has an issue
  • IMPORTANCE:WISHLIST - A feature request
  • IMPORTANCE:BUG - for all other misbehavior not one of above.
  • GOODSTARTER - Can be set in addition for easy bugs that do not require a deep knowledge of the code base and have a limited scope

To adopt a bug and start to work, set Assign it to yourself and to a milestone.

A a bug can also be closed. It is automatically closed if a connected PR has been merged. If it is closed manually a comment is required, explaining why.

If it is closed by automatic expiration the bot will add a comment.

For duplicates type "Duplicate of" followed by the issue number and close the issue.GitHub will automatically catch that.

Lable Color Code

  • STATUS:INCOMPLETE - dark Purple/Pink
  • STATUS:OBSERVATION - light Purple/Pink
  • STATUS:CONFIRMED - medium Purple/Pink
  • STATUS:WONTFIX - grey
  • STATUS:INVALID - grey
  • IMPORTANCE:BLOCKER - Dark red
  • IMPORTANCE:PATYSTOPPER - darker red
  • IMPORTANCE:REGRESSION - lighter red
  • IMPORTANCE:BUG - light red
  • IMPORTANCE:WISHLIST - celeste
  • Tags: yellow

Launchpad Migration

  • STATUS:INCOMPLETE - Status Incomplete
  • STATUS:OBSERVATION - Status New
  • STATUS:CONFIRMED - Status Confirmed / Triaged / In Progress
  • STATUS:WONTFIX - Status Won't fix
  • STATUS:INVALID - Status Invalid / Opinion
  • IMPORTANCE:BLOCKER
  • IMPORTANCE:PATYSTOPPER - Importance Critical
  • IMPORTANCE:BUG - Importance High / Medium / Low
  • IMPORTANCE:WISHLIST - Importance Wishlist

Tags are imported one by one as labels,

In addition a "Launchpad" label is added to all imported issues

Status Fix Released / Fix Committed / Status Won't fix / Invalid / Opinion are not imported.

Proposal Be

Workflow

We will not be mirroring Launchpad's states on GitHub. We will be using a simplified set of tags:

  • beta blocker
  • release blocker
  • feature request
  • good-first-pr

We will use Close Stale Issues to prevent issues from piling up. The "feature request", "beta blocker", and "release blocker" labels will be exempt from automatic closing.

We are explicitly choosing not to have more "priority" states than "beta blocker" and "release blocker" because these only cause useless disagreements over subjective priorities. What matters is having a clear view of what must be done for a release. We all have different priorities for Mixxx; if you think something is important, do it yourself.

For duplicates type "Duplicate of" followed by the issue number and close the issue. GitHub will automatically catch that.

In addition a "Launchpad" label is added to all imported issues. Imported issues will be closed automatically by Close Stale Issues like any other issue. Bugs marked "wishlist" on Launchpad will be imported with the "feature request" label. Status Fix Released / Fix Committed / Status Won't fix / Invalid / Opinion are not imported from Launchpad.

Clone this wiki locally