User Tools

Site Tools


Replacement of Launchpad and/or Gitolite in 2017

We have been using Launchpad for several years for bug/feature request tracking and managing our translations. Separately, we have been using Gitolite and Gitweb to manage our Git repositories. However, some dissatisfaction has been building up over the years, and during the hackfest at the 2017 EIC, we decided to start exploring alternatives.

Reasons for change

Launchpad (bugs)

What we like about LP

  • Series and milestone targeting of bugs.
    • Particularly helpful for tracking whether a bugfix has been backported to a maintenance branch

What we don't like about LP

  • UI supplies no way to batch-edit bugs
  • The API is hard to use, particularly for command-line applications
  • LP has timeout errors rather more often than one would like
  • No direct links from the bugs to the commits fixing them.
  • Bug search is limited, even with advanced search. Most effective way to search is to start opening a new bug.
  • There's no way to edit, delete, or suppress a comment, which is a problem if somebody has inadvertently left in patron or a description of a security exploit.
  • There's no way to update a bug without triggering an email, which is a problem for batch updates.


What we like about Gitolite

  • It is easy to control access to branches and directories
  • The working repository contains nearly all submitted changes; no need to juggle a lot of remotes.

What we don't like about Gitolite

  • Keys for new users must be added manually, adding a bit of friction to the process.
  • Similarly, human intervention is required whenever a user has new or updated keys.
  • No direct links from commits to the bugs describing them.

Launchpad (translations)

What we like about LP

  • Some (many? all?) translators find the UI easy to use.

What we don't like about LP

  • It requires bzr when nothing else in our workflow does.
  • The promise of grabbing translations from other projects hosted on LP has not really panned out.

Requirements for replacements

Hard requirements

  • Interface for reporting bugs should be easy for non-technical folks to use
  • Can import bug history, including comments
  • Can import existing PO and POT files

Soft requirements

  • Has the ability to host a private repo for the security team. (If not, we could keep using Gitolite for that)
  • Ability to find and retrieve bugs by their old LP number


  • Ability to report or comment on bugs without requiring a user account




  • Defacto standard site for many projects.
  • "Everyone" has a GitHub account.


  • Offers no integrated i18n/l10n tools
  • Private repos are not free (as in beer).
  • Not F/OSS itself, so we can't host it ourselves if desired.



  • F/OSS: We can host it ourselves or host at


  • Offers no integrated i18n/l11n tools



  • F/OSS: We can (must?) host it ourselves.


  • Offers no integrated bug reporting and repository management tools

Fork LP


  • We could add what we want without fundamentally changing existing workflows on ourselves


  • It would be a lot of work
dev/2017_new_tools.txt · Last modified: 2017/04/11 12:31 by gmcharlton

© 2008-2017 GPLS and others. Evergreen is open source software, freely licensed under GNU GPLv2 or later.
The Evergreen Project is a member of Software Freedom Conservancy.