Not logged in - Log In / Register


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.


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

Picking a name

Picking a license

See Choosing A License.


  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'. Some existing branches are owned by '~lazr-developers'. Do not use '~lazr-developers' for new shared branches.
      • 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 register

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

Not part of Launchpad proper?

A growing number of the projects the Launchpad team work on are not part of 'Launchpad' although they are usually closely related. Such projects may need their own governance and or mailing lists.


Rather than setting the project maintainer to '~launchpad':

  1. create a dedicated moderated team such as '~$PROJECT-maintainers'
    • Either make '~launchpad~ own that team OR
    • Have an appropriate role based owner (e.g. '~ubuntu-council') own it
  2. Assign the dedicated team to be the project owner.

Mailing lists

For mailing lists, sometimes the project will be offtopic for the Launchpad-dev list, or the other traffic on launchpad-dev would distract from the new project's discussions. In these cases:

  1. Create an open team called '$PROJECT-devel'
  2. make it be owned by '~launchpad' (or '~PROJECT-maintainers' if such a team was made (see Governance)).
  3. Create a mailing list for team.
  4. Announce the list's creation so other Launchpad developers can turn on delivery.

If a private list is needed (which is sometimes the case), follow the same process but make it private not public.

CreatingNewProjects (last edited 2012-01-06 04:59:28 by lifeless)