How to review code import requests

Before you begin

To review code import requests on Launchpad, you need to be a member of the ~vcs-imports team. All Canonical Launchpad & Bazaar folk are members of this team, and we are happy to extend membership to responsible community members. If you'd like to join, just ask us.

Once you've got the right permissions, go to the pending import requests and start reviewing.

Whiteboard

Whenever you change the status of an import, or otherwise want to leave a note for the next CHR, use the whiteboard. Be sure though to leave the date and your name/nick in the whiteboard so we know who wrote it, e.g.

20090305 barry - there's no branch here; marking invalid

Note that the whiteboard in this context can be read and written by the import requester and the CHR. If you need to request action or more information you can just leave a note on the whiteboard.

Assess The Import

Now that we use bzr-svn, non-mainline svn branches can be imported in such that they will be compatible with mainline svn imports. However, they will not be compatible with old svn imports based on CSCVS.

For Git and Hg, there's no way to specify anything other than the mainline at the moment (Bug #380871).

For CVS, we usually only import the mainline development branch. This is mostly for expectation management: cscvs does not in any way track branching or merging in the source repository, so an import of trunk and an import of a branch would have, from bzr's point of view, totally separate histories.

Usually, you can easily tell whether a request is for a mainline branch or not from the CVS details.

Subversion Repositories

If the branch being imported is a Subversion branch, the easiest thing to do is to 'ls' it and see if it looks like a trunk:

% svn ls http://pydza.labo-linux.org/svn/trunk
COPYING
README
README-EDITOR
TODO
builds/
media/
pydza-reflex-gobby
share/
src/

That looked pretty reasonable to me, so I said so in the whiteboard and approved the code import. If it doesn't look reasonable, but you can still kind of figure out where the trunk is, just hack the url and approve it.

Do not approve a Subversion import if:

• The 'svn ls' command fails
• The repository requires a password

• The import is from svn.apache.org. They hate us. See bug 327126

In such cases, mark the import as "Invalid" and make a note on the whiteboard explaining why you did so.

A special note for SF: the user will probably provide a https: URL. If you remember, change that to http: before you approve -- the import will be faster and more reliable if you do.

GoogleCode only supports authenticated use over https so you need to change https to http in URLs before approving, otherwise the import will fail.

CVS Repositories

CVS repositories are trickier because they don't support 'ls'. In that case, do a CVS checkout and see if that makes sense. The code import request page will probably have a :pserver: detail and a module name. You need both of these pieces of information to do the CVS checkout.

% cvs -d :pserver:anonymous:OpenLDAP@cvs.OpenLDAP.org:/repo/OpenLDAP co openldap
cvs checkout: Updating openldap
U openldap/COPYRIGHT
U openldap/INSTALL
U openldap/LICENSE
U openldap/Makefile.in
U openldap/README
U openldap/aclocal.m4
U openldap/configure
U openldap/configure.in
...

If the project is coming from SourceForge, and the branch details don't look sane, you can always try to find the project on the SF site and see if you can figure out what the user actually meant.

Sometimes the obvious branch is not the most appropriate one. Unfortunately, determining this requires dialog with whoever requested the import and we don't know who that is, so the usual approach if things don't look obvious is to update the whiteboard and select "Mark invalid".

Or you can just be a JFDI Knight.

Other than that, the details should be vetted for sanity. The guideline (mostly useful for subversion) is that we import whatever would be packed up into a release tarball, i.e. the directory containing the README, configure, etc files. Users certainly don't always type this directory into the form, so do a few 'svn ls's and fix the details as appropriate.

CVS can be made to do some very strange things which most of us have blessedly forgotten, so it's probably worth trying the import out first on your machine to check that the repo at least works somewhat.

Approve or decline the import

Choose "Edit import source or review import." Choose "Approve".

Imports that fail

20100602 maxb: I started FailingBzrSvnImports to attempt to pick up on common failure causes.

I don't know what do. Who can help me?

To start with, follow our regular channels for developer help.

If all else fails, you can try contacting Michael Hudson or Paul Hummer specifically.

Once you have an answer from them, update this page with the info so others can benefit too.