[2991] in BarnOwl Developers
Re: Thoughts on our current code review policy
daemon@ATHENA.MIT.EDU (Anders Kaseorg)
Wed Mar 23 23:24:04 2011
Date: Wed, 23 Mar 2011 23:23:59 -0400 (EDT)
From: Anders Kaseorg <andersk@MIT.EDU>
To: Nelson Elhage <nelhage@nelhage.com>
cc: barnowl-dev@mit.edu
In-Reply-To: <AANLkTimpiLgdAo=YHtZMxctP_R7YK-LPEdtG3F+TFpbw@mail.gmail.com>
On Wed, 23 Mar 2011, Nelson Elhage wrote:
> I'm curious what people about how our current code review policy is=20
> working out.
I haven=E2=80=99t personally had a problem with it on the coder side. I=E2=
=80=99ve seen=20
some things get forgotten about, but that tends to get fixed when I send=20
out a zephyr poke.
On the reviewer side, it would be great if I could click on something and=
=20
see all the commits that are still waiting for review. Some kind of=20
Gerrit, for instance. And we=E2=80=99re far from the only greater-SIPB-rel=
ated=20
project that has this need, so we could do a lot of good if we either=20
figure out how to get something like Gerrit working on Scripts, or set it=
=20
up on an XVM that several projects can use.
If we had that, it would be much easier to draw conclusions about whether=
=20
code review is stifling development. As things stand, I=E2=80=99m not real=
ly=20
sure.
By the way, it would also be great if when you forked barnowl on Github,=20
it didn=E2=80=99t make a copy of every damn branch. It=E2=80=99s hard to s=
ee anything=20
about what=E2=80=99s going on when
$ git branch -r | wc -l
164
(You can help! If you have a barnowl fork on Github, please delete all=20
the branches from it that aren=E2=80=99t yours.)
> so I'm not convinced anyone can effectively review changes for e.g.=20
> subtle interactions with other pieces of the code,
This argument cuts both ways: code review is a good way to cause more than=
=20
one person to be familiar with the code.
Anders
