Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > 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. This can go both ways. A trivial improvement can be suggested that way by the reviewer. > * 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.... > * 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). Overall, good suggestions. Thanks. -- 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