Diff for "ReviewingCodeImports"

Not logged in - Log In / Register

Differences between revisions 3 and 4
Revision 3 as of 2010-02-15 20:12:53
Size: 5306
Editor: mwhudson
Comment:
Revision 4 as of 2010-02-24 15:32:58
Size: 5316
Editor: mars
Comment:
Deletions are marked like this. Additions are marked like this.
Line 65: Line 65:
 * The import is https with an invalid (self-signed, expired, ...) certificate. These imports will work after 10.02 is rolled out, so just leave them in review for now.  * The import is https with an invalid (self-signed, expired, ...) certificate. '''''These imports will work after 10.02 is rolled out, so just leave them in review for now.'''''

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

The main rule for imports is that 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. Note that, as of April 3, 2009, Subversion and CVS both have this limitation, but our upcoming Git and Hg support will keep track of merges; and Subversion support will keep track of branches once we switch to bzr-svn. Eventually, only CVS should have this limitation.)

Usually, you can easily tell whether a request is for a mainline branch or not from the URL/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

  • The import is https with an invalid (self-signed, expired, ...) certificate. These imports will work after 10.02 is rolled out, so just leave them in review for now.

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. Change that to http: before you approve -- it's much much more likely to succeed over plain old http.

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".

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.

ReviewingCodeImports (last edited 2020-04-20 09:10:18 by doismellburning)