Re: Our cumbersome mailing list workflow

Stefan Beller wrote:

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