Hi,
This commitfest will soon finish and we can already say, I think, that
the support software is doing a pretty good job helping through
it. Congrats!
Now after some discussion about it on IRC, we have some ideas to improve
the situation some more. Specifically, reviews are touching several
areas and all reviewers aren't comfortable in all of them (it's about
skills, time, or perf testing lab equipment, mainly). What about
refining what parts of reviewing a specific review touches? Here's a
first try at a list of those:
- patch (applies, merge, compiles, pass regression)- code reading (looks like it was already there, no WTF?) [1]-
documentation(covers code, targets users, is sufficient)- testing (code behavior is what is documented, works well)-
creativetesting (tried hard to crash it)- perf testing (profiling, no regression in non optimized cases...)- you name
it
On the application side of things, having checkboxes to check at review
submit and little icons on the "action lines" in general view could do
it.
When we have that, some reviewers could concentrate on code review only
and waits for the patch to have been reviewed first for the other points
(patch, documentation, testing, e.g.). And reviewers feeling they won't
help reviewing code would omit checking this particular box.
Ideas, comments?
Regards,
--
dim
[1] http://www.osnews.com/images/comics/wtfm.jpg
