Publishing code reviews

[Mark Wielaard]

Hi,

On Fri, 2007-10-12 at 07:55 +0200, Roman Kennke wrote:
> > Having review traffic on mailing lists, where it can be indexed by
> > search engines, proved invaluable to me time after time when I was
> > dealing with some obscure 'not_quite_a_bug' in some piece of software,
> > as it let me read my way into figuring out 'what the hell were they
> > thinking' without having to tri-jump around mailing list archives,
> > bugzilla, and CVS/SVN data.
> > 
> > So I'd suggest, for the sake of the future generations trying to find
> > lost needles in the growing OpenJDK haystack, to flood the review lists.
> 
> I second that.

I believe I am not even the third anymore, but I would strongly support
the same. Having email as the common backend is really, really
convenient. mailinglists are archived everywhere, you can easily turn
them into nntp or rrs feeds (like gmane does) and writing little bots to
monitor the lists and take appropriate actions is super easy (if you
aren't dirty of a little perl now and then).

As an example here are the mailinglists in use for GNU Classpath, but I
believe most larger free software projects have something similar:

classpath at gnu.org general discussion, announcements, developer talk,
ideas, etc. but not formal patch proposals. Formal patch proposals go
to...

classpath-patches at gnu.org posting of proposed patches (in diff -u
format) for review. All replies and suggestions for improvements and
final approval of the patches also go to this list. Some projects (like
gcc) also have a bot that you can inform of the formal patch proposal so
it can monitor whether there was any reply. In classpath we require
developers to ping their patches themselves if there is no reply in a
reasonable time.

classpath-commits at gnu.org - a robot posts all commit messages plus the
CVSWeb URLs of anything that actually hits the archives. Another robot
picks up any commit messages from this list to update the bugzilla bug
entries mentioned in the commit message (and humans double check every
commit to make sure that the accompanying patch was discussed on the
patches list).

classpath-bugs at gnu.org All new or modified bugzilla entries get posted
here (which includes the commit-bot updates when a commit message
contains a bug number). Replying to these emails also updates the
bugzilla entries, so it is an easy way to interact with the bug
reporters and to monitor when a particular issue is often reported or
commented on.

classpath-testresults at gnu.org posting of autobuilder results of
compiling classpath in various configurations, with different compilers,
runtimes and against different (replies go to the general list). There
should be a robot behind this one also, but currently it is the sharp
eyes of the various developers pinging every involved developer and the
general list when a commit hit the autobuilders that triggers a
regression (or worse!) a build failure. - This list is super handy when
there was a continuous stream of build/test results on various
conficurations, it enables sonmeone to easily hunt down when a
particular issue arose on a particular architecture over time.

So there are different backends to some of these lists (cvs, bugzilla,
custom build bots), but humans value the actual email messages the most.
Also humans can kind of adjust their involvement, someone just sending
an occasional patch will most likely only monitor the general and
patches list (a requirement for committers), but maintainers, bugmasters
and integrators will most likely subscribe to all lists. And everybody
can use the various email archive search tools to easily locate past
information.

Cheers,

Mark