Code review strategies

[Colin Watson]

We've never had much in the way of code review in Ubuntu. In freeze
periods, sometimes mdz or jdub or I will review patches before approving
packages for upload, which is very human-intensive; new packages get a
security and supportability review before being added to main; and of
course we occasionally look over each other's code when working on a
variety of patches. However, it's difficult to get a feel for the
quality and consistency of people's work, or to keep up well enough to
suggest improvements on a routine basis, or to pick up skills and
knowledge from other people by watching their commits go past, which is
something I've found very valuable at previous workplaces.

(Ultimately, we may be able to improve this by harvesting commits from
HCT archives, filtering them, and mailing them somewhere. That's still
some way off, though; even when we have it it'll take a while before all
changes will be available this way; and it depends on people publishing
their archives to a central location.)

In the meantime, one way we might be able to improve this would be to
attach debdiffs against the previous version of the source package to
the mails that are sent to breezy-changes and similar lists. They'd have
to be limited to a certain size - we don't want to mailbomb people with
upstream diffs between OpenOffice.org versions, say - and we would need
to think about possible ways to separate out changes made upstream or in
Debian from changes made in Ubuntu so that we can see what's going on.

Any ideas on this, or other suggestions?

Cheers,

-- 
Colin Watson                                       [cjwatson at ubuntu.com]