PolicyForDocumentingCustomDistributions

Not logged in - Log In / Register

Revision 3 as of 2009-08-18 18:01:43

Clear message

Policy for Documenting Custom Distributions

Problem

Sometimes we need to make custom, local distributions of packages that we use. We want all developers to know how to get an original copy of the code that we are using for our distributions, so that we can all make subsequent changes and releases, and we can all try to push patches upstream.

Why do we sometimes need to make custom distributions?

Here are some concrete examples from recent Launchpad usage.

feedvalidator

zc.buildout, zc.recipe.egg, z3c.recipe.filetemplate

We have contributed changes to make these packages work more smoothly with a system Python. They are in branches in the zope.org repository, awaiting review.

Storm

Considerations

Do we need to keep all branches in Launchpad, or is it acceptable to defer to canonical upstream repositories for a given project?

The current proposed solution specifies that it is OK to defer to upstream repositories if we do not have an import of the branch. It is particularly suggested that you defer to upstream if you are using a (hopefully) short-lived branch from the upstream repository. Otherwise, if you are using a revision of the project's trunk, it is preferred that you use a Launchpad automatic import.

Proposed Solution

versions.cfg (in the top level of the Launchpad tree) is where we specify our versions. Whenever we add a custom local distribution there, we should precede it with at least three comment lines.

The first should indicate the location of the sourcecode (trunk or branch or tag), that was used to create the distribution. The location may be in Launchpad or in the canonical upstream repository for the code, if it uses bzr, git, hg, or svn (excluding cvs because I suspect many of us have forgotten how to work with it.

The second should indicate the revision number of the sourcecode.

The last comment lines should show the exact command(s) used to generate the local distribution from the given branch. This can be important because of setuptools flags like -r and -b that allow you to change the effective version identifier.

The idea is that another developer should be able to check out the sourcecode at the given revision id and run the listed command to get an exact copy of the custom distribution we are using.