[IAEP] Proposed Trac - > Launchpad migration

[Luke Faraone]

Hi all,


So far, the experiment with SoaS has been a success. Sebastian
Dziallasreports satisfaction with Launchpad's bug and blueprint
functionality, as
well as inter-tool integration.

== Overview ==
Launchpad has a number of strengths that differentiate it from other tools
we have explored, the most important is the integration of the following
components into a cohesive whole:

   - Questions/Answers


   - Bugs


   - Blueprints


   - Translations


   - Code hosting (bzr)


Moreover, if Sugar Labs decides not to make use of all of these components,
we can disable them from within the Launchpad UI.

Finally, Launchpad is not a PITA to manage. Rather than requiring Bernie
(the only person other than Ivan who has access to dev.sl.o AFAICT) to
constantly wrangle with system updates, scalability issues, and general
maintenance, Launchpad is externally hosted by Canonical.

== Comparisons ==

Compared to Trac:

   - Project-level optional access control on priority, milestone targeting,
   etc


   - intergreted spesification/blueprint functionality, with support for
   milestone targeting, etc.


   - differentiation between support requests and bugs


   - the ability to link bugs as affecting multiple projects, and to pull in
   status updates from other projects, even if they use different bug trackers


   - hosted gratis, and supported by a team of competent Canonical system
   administrators


   - support for translating projects using POT files


   - a cleaner user interface (opinion)


   - group support


Compared to GetSatisfaction:

   - free and open source software, written in Zope


   - acts as both a bug tracker, a question/answers site, and everything
   described above



== Migration ==

If Sugar Labs does decide to migrate, the process is fairly
straightforward.

All bugs can be exported from Trac using a well-documented and supported
tool, and be imported into Launchpad projects.

Users who have Trac accounts will have corresponding Launchpad accounts
pregenerated, but they will not be active until the user generates a
password. Users who already have Launchpad accounts will be able to merge
them, or (if they used the same email address) automagically have bugs
reported at SL associated with their extant accounts. (we can opt to not go
this route and have all imported data owned by ~launchpad-janitor)

All Sugar Labs projects would be associated with the "sugarlabs"
super-project, and would be seen from http://launchpad.net/sugarlabs. We
still get the benefit of having a single page to point people who are
reporting bugs <https://launchpad.net/sugarlabs/+filebug> or asking
questions <https://answers.launchpad.net/sugarlabs/+addquestion>.

Since Launchpad does not support native bzr hosting, we have three options:

   - convert to bzr (not probable)


   - use bzr git imports with Launchpad


   - integrate Gitorious with Launchpad via OpenID, write a script for
   project mirroring


   - don't integrate Gitorious at all, and just have slight duplication of
   effort on the developer's part. (even light-weight LP-OID is easy to do)


Based on the above, we'd like to propose that Sugar Labs migrate to
Launchpad, at least for Blueprints, Answers, and Bugs, within a release
cycle.

--
This email was jointly constructed by Sebastian Dziallas and Luke Faraone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sugarlabs.org/archive/iaep/attachments/20090831/206d3ae9/attachment.htm