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 tthat 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
- License is an open source license.
- No proprietary dependencies.
- 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.
- 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.
- 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.
- 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.
- For pypi: python setup.py register