Stefan Beller wrote: > How are non-regulars/newcomers, who supposingly need more iterations on > a patch, supposed to handle the inter patch change log conveniently? I think this is one of the more important issues. I don't think there's any reason that newcomers should need more iterations than regulars to finish a patch. Regulars are actually held to a higher standard, so they are likely to need more iterations. A common mistake for newcomers, that I haven't learned yet how to warn properly against, is to keep re-sending minor iterations on a patch too quickly. Some ways to avoid that: * feel free to respond to review comments with something like "how about this?" and a copy/pasted block of code that just addresses that one comment. That way, you can clear up ambiguity and avoid the work of applying that change to the entire patch if it ends up seeming like a bad idea. This also avoids having to re-send a larger patch or series multiple times to clear up a small ambiguity from a review. * be proactive. Look for other examples of the same issue that a reviewer pointed out once so they don't have to find it again elsewhere in the next iteration. Run the testsuite. Build with the flags from https://kernel.googlesource.com/pub/scm/git/git/+/todo/Make#106 in CFLAGS in config.mak. Proofread and try to read as though you knew nothing about the patch to anticipate what reviewers will find. * feel free to get more review out-of-band, too. If you're still playing with ideas and want someone to take a quick glance before the patches are in reviewable form, you can do that and say so (e.g., with 'RFC/' before 'PATCH' in the subject line). Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html