Specification

• Launchpad Entry: https://features.launchpad.net/distros/ubuntu/+spec/code-review

• Created: Fri, 10 Nov 2006 14:21:21 -0800 by DanielHolbach

• Contributors: DanielHolbach, MattZimmerman, TollefFogHeen

Summary

We would like to offer a service level to MOTU's offering code for inclusion in main, or for new developers offering code for inclusion in universe or multiverse. This topic is a placeholder for that discussion.

Rationale

Comparing the amount of fixes and patches contributed by community members and the amount of packages and fixes landing in Ubuntu, it becomes clear that we're currently doing well at sponsoring uploads for existing packages, but don't do well at nurturing NEW packages and mentoring new members of the community. The spec identifies needs and tries to address them.

Use cases

• Sébastien packages a new KDE module he happens to be upstream for. The packages does not exist in Ubuntu yet. He finds good documentation and throughout the process people are helping him quickly and he ends up with a well done package in Ubuntu's Universe.
• Sarah helps out with reviewing. She goes to her bookmarked overview page, easily finds a new entry, checks out the branch, runs a basic testing tool on the packaging, does a quick change, commits it to launchpad.net and updates the summary.
• Daniel does a package together with Michael. He can easily check out Michael's last changes and update to the newest Python policy, he just learned about.
• Melissa wants to get an impression of how good the REVU team works, she checks the mailing list (which reflects the team's bzr branch changes) and sees how many packages were approved.

Scope

In order to fix the problems outlined above, the following changes are going to happen:

• we move our review system for NEW packages to bazaar.launchpad.net
• we subscribe the team's mailing list to the bazaar branches

Design & Implementation

A revu team will be created on Launchpad which will be a restricted team for either

• reviewers or
• developers who want to get their packages reviewed.

To submit a NEW package to Launchpad, you

• create a product in Launchpad,

• push the packaging (just the debian/ directory) of it to sftp://<launchpad-id>@bazaar.launchpad.net/~revu/<product>/ubuntu

  • the upstream source is not necessary as
    • it mostly comes in tarball form,
    • is not easy to keep up with (added files, removed files)
    • it is seldom being worked on by the package maintainers.

• mark the branch as 'Development' as long as you work on it

• mark it as 'New' as soon as you're sufficiently happy with it and request a review

• can expect it to be uploaded as soon as it's marked as 'Mature'.

To review a package, you

• check the list of 'New' product branches on http://launchpad.net/people/revu/+branches

• choose a package
• check the whiteboard
• check out the packaging
• run a set of basic tests on it
• update the whiteboard and probably the status of the branch.

The advantage of this approach is:

• members of the team can help each other to perfect the packaging and help and teach each other until they mark the branch as 'New'.
• the branch whiteboard can be used for comments, examining the branch diff will be of huge help,
• it will teach new MOTUs to use bzr and the launchpad services,
• new products are added as we go,
• the overview pages are created anyway,
• we don't have to maintain separate servers or code bases.

Outstanding Issues

• [https://launchpad.net/products/launchpad-bazaar/+bug/73975 Bug 73975]. This plan is not going to work unless subscribing to a branch actually causes emails to be sent.

• [https://launchpad.net/products/launchpad-bazaar/+bug/55096 Bug 55096] prevents teams from subscribing to its bazaar branches.

• [https://launchpad.net/products/launchpad-bazaar/+bug/71303 Bug 71303] would make the /+branches overview page much cleaner and easier to read. The [http://launchpad.net/people/revu/+branches revu branches page] will be quite full really soon.

• We're lacking bzr-buildpackage - this would speed up usage and development quite a lot.

Comments

SebastienBacher: Having a "bzr-buildpackage" tool working "out of the box" would be appreciated. I've experimented debian directories stored to bzr from the telepathy-team and not figured a good workflow for them. If people have to get the tarball by somewhere else, move the debian directory around, clean .bzr from it, move changes the other way around to commit, etc that's going to discourage some people to do review. Maybe store the whole package to bzr so people only have to "bzr get" and build for the moment would be a better option?

• ColinWatson: With regard to cleaning .bzr, what's wrong with debuild -i (or debuild -i -I.bzr -I.bzrignore for native packages)? It's easy to put those options in DEBUILD_DPKG_BUILDPACKAGE_OPTS in ~/.devscripts as well, and we could trivially document that.

[:CategoryMOTU]BR [:CategorySpec]