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 CDO 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'. 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 setup.py 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.

Governance

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.