Brent Goodrick <bgoodr@xxxxxxxxx> writes:
> While I'm at it, what is the standard procedure for submitting git
> patches for review once I've cooked up and validated it on my end? I'm
> guessing posting the patch into this mailing list is part of the
> answer to that question.
Yes, a guideline is in Documentation/SubmittingPatches for the initial
submission. After that, the lifecycle of a patch submitted on the list
goes like this:
(1) A patch is shown to the list participants.
(2) People may like it, or may have issues with it, and responds with
their comments describing problems, suggestions for improvements,
etc. People who are not interested in the topic may stay silent.
(3) The original author responds with updated patch. Sometimes people
who commented on in step 2 may even send "here is how I would do this
one; don't you think this is better?", and the original author may
say "Yeah, let's use yours instead".
(4) After steps 2 and 3 repeats zero or more times, the latest patch may
become one that everyone likes, or at least nobody has trouble with
inclusion. The author sends such a patch saying "this is meant for
inclusion based on discussion and refinements in these threads...".
(5) The maintainer picks it up when it looks polished enough.
Your patch may appear in the periodical "What's cooking" or "What's in"
summary with zero iteration of steps 2 and 3 if it is obvious enough.
I act as just one of the list participant during steps 1-3. I may stay
silent during this period but that only means the topic is not interesting
to me and nothing more. It does not mean that the topic has no chance of
getting included.
I act as the maintainer for steps 4 and 5. If you do not hear from me
after step 4, then I am either being lazy, busy, or sick, or the patch got
lost in the noise and I need a reminder. Note that I may reject or ask
further refinement at step 4 to ensure overall quality throughout the
system even in areas I am not interested in and didn't say anything during
steps 1-3.
--
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
