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

We used to require that svn imports were imports of trunk/mainline, but now they can be branches, too.

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 branch:

% 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

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

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

Our old svn imports were based on CSCVS, so a branch imported using bzr-svn will not have common history with an old svn import. (You can see the type of import. It will be "Subversion via CSCVS" or "Subversion via bzr-svn".) In those cases, we recommend doing a new import of trunk, which will use bzr-svn.

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.

If you want to try out a CSCVS import on your local machine:

export PATH=$PATH:$HOME/launchpad/lp-sourcedeps/sourcecode/cscvs
export PYTHONPATH=$HOME/launchpad/lp-sourcedeps/sourcecode/cscvs/modules
cvs -d CVSROOT_GOES_HERE co -d foreign_tree MODULE_GOES HERE
bzr init bzr_branch
cd foreign_tree
cscvs -D3 totla --strict -b ../bzr_branch -SI MAIN.1 ../bzr_branch
cscvs -D3 totla --strict -b ../bzr_branch -SC MAIN.1:: ../bzr_branch

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.