Code Imports are now automatically approved, so manual review is generally only needed if there's some kind of error we're trying to fix.
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.
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.
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 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.
Once you have an answer from them, update this page with the info so others can benefit too.