Latest Posts


Widelands moving away from

This page will help deciding on a new Hoster for the development of Widelands.

If you want to know why, please check the forum at


After SirVer's authoritative vote to move to (see Forum post), this page is dedicated to get knowledge about Launchpad's services, possibilities and solutions, and create a scenario for moving.

SirVer's toughts on a launchpad scenario.

I am pro for a move to launchpad mainly for the following reasons

  • open source itself -
  • many developers behind it
  • good support (as far as I needed it which was some times)
  • excellent bug tracker zero page reload for bug modification good comments for bugs (including email discussion) a python API to automatically modify bugs import of bugs is (theoretically) possible
  • good coding support bzr (I prefer git, but bzr is much better then SVN). No wars here. that also means many branches with cheap merging ** per user branches means people can contribute without commit rights and without patches needed
  • Web based translation that can get automerged into the repository

It has some down sides. Please put more if you are aware of more:

  • I have no Idea if mailinglists are supported.

Roadmap to move

This is my suggestion for a Roadmap to move to Launchpad.

  1. Moving source code I will move svn/trunk and svn/cmake into two branches on launchpad and make the official in some sense. The SVN on will then be completely disabled overnight (It will stay as read only documentation of our long, long history). We will use our tagging history in this move, which is unfortunate but can't be changed. We can restore it in branches on launchpad if we want to later on.
  2. Moving bugs. This will mean that first the bug tracker on will be disabled, then I export and XML file an hand it to the launchpad staff to import it for us. This means for a week or so, we won't be able to track bugs.
  3. Moving widelands-public. If Launchpad offers us Mailinglists, we will move them after everything is stable and set. This is so that our main communication channel stays open in case anything goes wrong.

So to sum up:

Phase 1

Code in bzr branches on launchpad. Bugs & Mailinglists on

Phase 2a

Bug trackers disabled. Export of bug trackers get imported to launchpad.

Phase 2b

Only Mailinglists on

Phase 3

widelands-public get's moved to launchpad. Widelands-annouce will stay around because we only announce releases over it.

QCS' expeditions:

General offers from Launchpad

  • Created and hosted by Canonical, the company behind Ubuntu, in UK and all over Europe
  • Free (and apparently Adfree) hosting of the project development, on a free platform
  • excellent Bugtracker
  • Code hosting repository - Bazaar (bzr), which is comparable to Subversion, in several parts better (can ýou spell "file rename tracking"?)
  • Mailing list
  • Answer tracking (kind of "users have problems, people answer" forum) and FAQ for the project
  • Translation service (online translation!!!) which uses GetText system, so it's usable for Widelands
  • Downloadpage for distribution
  • OpenID Login
  • More personal help from the support than in

Additional offers, may be fun to use

  • Feature/Spec tracking ("Blueprint")
  • Ubuntu packaging for building and delivering nightly builds with an "update repository" in Ubuntu format
  • Answers and help from the whole Launchpad community. That is somehow influenced by their "karma" system (gratification for helping the community). With "karma"

What they don't offer

  • Git support
    • SirVer commented that Git is not official anyway and can be used from Sourceforge by Devs in the future
  • SVN support
    • Bazaar is comparable to SVN, at some parts superior.
  • Wiki and Forum
    • What platform is the current Homepage/Forum/Wiki running on? Can this be kept for the future? Then we wouldn't need it from Launchpad.


  • One really cool feature of Launchpad is the Translation. There's nothing on the market which is comparable to that feature. And tinkering with CMake build at the moment, I really have problems finding a feasable and effortless solution for the upgrade of the translation scripts to the CMake build. That problem would be gone for good.
Tagged with: archived