On Tue, Dec 16, 2014 at 8:09 AM, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
> For the spare time that I have for review, one of these projects
> requires me to download attachment(s), apply them to a git tree
> (hopefully it still applies), run a complete "make check" regression
> series, try and analyse a patch which will often reference parts to
> which I have no understanding, and then write up a coherent email and
> submit it to the mailing list. Realistically to do all this and provide
> a review that is going to be of use to a committer is going to take a
> minimum of 1-2 hours, and even then there's a good chance that I've
> easily missed obvious bugs in the parts of the system I don't understand
> well.
>
> For the second project, I can skim through my inbox daily picking up
> specific areas I work on/are interested in, hit reply to add a couple of
> lines of inline comments to the patch and send feedback to the
> author/list in just a few minutes.
Notice though that on the second project, the review is made "in the
air". You didn't build, nor ran tests, you're guessing how the code
performs rather than seeing it perform, so the review is "light"
compared to the first.
Some of the effort of the first review is pointless, but not all of
it. Running make check may be a good task for a CI tool, but if you
ignore the result of make check, your review is missing an important
bit of information to be weighted.
There's something to be learned from the open build service (
http://openbuildservice.org/ ), there, review requests contain in the
interface the results of the build and rpmlint (it's for rpms). It
makes the review easy yet informed.
