git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [RFH] How to review patches: Documentation/ReviewingPatches?

From
Johannes Schindelin <johannes.schindelin@gmx.de>
Date
Feb 13, 2009, 00:08 UTC
Message-ID
<alpine.DEB.1.00.0902130055370.26370@racer>
In-Reply-To
<200902130045.59395.jnareb@gmail.com>
Hi,
On Fri, 13 Feb 2009, Jakub Narebski wrote:
> What I'd like to have is Documentation/ReviewingPatches to help with (at 
> least technical side of) reviewing patches, which is very important but 
> a hard work, c.f. http://www.kroah.com/log/linux/ols_2006_keynote.html

As I found out quite painfully recently, reviewing is a matter of trust, much more so than a matter of form or style.

I mean, it does not really hurt when somebody says ACK not understanding that an ACK is expected to come from people who wrote that particular code, or are at least very familiar with it. We know what the guy means, and that's it.

However, it does hurt when somebody says "I tested this extensively, and it works, I also reviewed the code, and it is correct" and you find out much later that the review consisted of a run through "indent" and seeing that there were no differences. Unsurprisingly, the patch had to be reverted entirely.

It's much better to have somebody prove her capability as an excellent reviewer, for example by offering comments that result in a better patch, earning respect by others in the process.

Speaking for myself, it is also quite possible that you find out that your reviewing fu is leaving to be desired. Concretely, it is widely known that patches I reviewed still contain several issues after I find no more.

But at least I can serve as an early filter as long as I have the time.

There is another reason why I do not want any ReviewingPatches: reviewing is already such a tedious process; let's not make it harder by forcing a potential reviewer to sift through a document (the same could be said about SubmittingPatches; IMHO it just repeats what common sense would do anyway when imitating existing code).

I'd rather suggest to patch submitters to make such a good case that all the world is interested in their patch, throwing a lot of eyeballs (AKA review) at it.

BTW this is a pretty valuable skill, also (maybe especially) outside of this mailing list, to get people interested in your work.

Ciao, Dscho

Previous: Jakub NarebskiNext: Marius Storm-Olsen
Message 2 of 6 in “[RFH] How to review patches: Documentation/ReviewingPatches?”
  1. Jakub NarebskiFeb 12, 2009
  2. Johannes SchindelinFeb 13, 2009
  3. Marius Storm-OlsenFeb 13, 2009
  4. Junio C HamanoFeb 13, 2009
  5. Johannes SchindelinFeb 13, 2009
  6. Jakub NarebskiFeb 15, 2009

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.