Introduction

This page provides a sensible-default path for creating new projects for split-out parts of Launchpad itself. These instructions should be followed unless there is a particular reason not to.

If you are looking for end user instructions about setting up hosting for a project, please see the relevant help documentation.

Prerequisites

You need a name, a license, no dependencies on proprietary components and an initial landing story.

Picking a name

• If in doubt, check with the LP TA or LP project lead about the name of a new project.
• Choose simple focused names.
• Don't be overly cute.
• Check that the name is free or claimable on Launchpad and the relevant language namespace (e.g. for python projects check on pypi).
• Like our UI the name should be clear about what the service is and does.
• Codenames can be ok, but see above about cute.
• If the component is particularly coupled to Launchpads stack, you are welcome to use the lazr. namespace if you want. Note though that this implies a namespace package, and these are poorly supported in Ubuntu - perhaps when 3.3 comes around they will be better.

Picking a license

See Choosing A License.

Checklist

1. License is an open source license.
2. No proprietary dependencies.
3. A clean trunk branch for the project.
   • If it was at any point proprietary confirm with your line manager whether to keep the history or do a fresh export + import.

   • You can, if you choose, use an export from the template branch lazr.yourpkg to get rolling. PythonProjectTemplate discusses that more.

4. A well configured Launchpad project.
   • The project maintainer should be '~launchpad'.
   • The project should be part of 'launchpad-project' (see under +edit).

   • The project bug supervisor and security contact should both be '~launchpad-security'. Visit /project/+subscriptions and remove the launchpad-security subscription that this causes.

   • The project description should be clear and engaging, and provide links to e.g the ~launchpad-dev mailing list to help folk get in contact with us.
   • Bug tracking, answers should be enabled, translations disabled unless the package is translatable.
   • trunk should have a reviewer of '~launchpad-reviewers'
   • If the initial landing story is 'commit to trunk', then the trunk should be owned by '~canonical-launchpad-branches' or '~lazr-developers'. Be sure to change the subscription for canonical-launchpad-branches to 'no email' as PQM is a member of that team.

5. A README.txt or HACKING.txt file describing how to get the source from Bazaar, bug tracker locations, patch submission rules, coding rules (e.g. PEP8) etc.

   • Do not reference the Launchpad-wide hacking rules: they are far too broad for small subordinate projects.
6. Project registered on any language specific sites (like PyPI)

   • For pypi: python setup.py register

     • And then add in at least the current Launchpad TA and Project lead as maintainers, to provide for bus-factor.