Chris,
your post is interesting:
Chris Howe wrote:
...
2) What are the obstacles in attracting more
patches/improvements and how can we get more
non-commiter involvement in JIRA reviews?
The number of patches and contributors is slowly growing every day and
this is a great thing.
However it's true that the committer/non-commiter involvement in JIRA
reviews is low and usually the only person that reviews/comments on it
is the committer to which the issue is assigned.
And this is a problem and I think that there is something we could do to
improve this.
For everyone: there are many ways to review a patch:
a) open it with a text editor to study it; this is not a reliable way of
reviewing a patch but it is very quick and can be very useful to
understand if the patch is formally correct (e.g. doesn't contain
absolute filepaths), if the formatting/coding standards are accurate
(e.g. it doesn't contain tabs), if there are license issues (for
example, are all the license headers in place?) and also to discover
possible issues with it
b) ask questions to the author of the patch (adding a comment to the
Jira issue) to get more information, if you need it
c) apply the patch and verify if the system builds and runs correctly
(ant clean, ant build) with no new warnings or error messages in the log
files; if xml files have been updated, check the syntax agains their xsd
files using an xml parser
d) test the patch by reproducing the use case scenario
In my opinion, even if a guy doesn't have time (or knowledge) to deeply
test a patch (from #a to #d), he/she could at least help with #a and
#b... then he/she should post a comment to the issue with his/her
opinion, for example:
"I don't have time to apply the patch, however, after a quick review it
seems formally correct, except for some formatting issues (tabs instead
of spaces) in the class ExampleClass; here is a new patch that fixes this."
And the committers, that have the power of veto, *should* ideally
comment every issue, even the ones for areas they don't know well, even
just to state that they don't have time to comment, so that the other
committers can get a better understanding of the feeling of the group;
for an example of this, a few minutes ago I've added a comment to the
following issue:
http://issues.apache.org/jira/browse/OFBIZ-405#action_12446546
Another example could be:
"No time to review this patch, I fear that there could be some problems
with promotions; please test carefully before committing."
Jacopo
