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

The lifecycle of a patch and the maintainer involvement

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 25, 2009, 20:35 UTC
Message-ID
<7v3af7dsz1.fsf@gitster.siamese.dyndns.org>
In-Reply-To
<18811.32772.728276.923430@hungover.brentg.com>
Brent Goodrick <bgoodr@gmail.com> 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.

Previous: Brent GoodrickNext: Brent Goodrick
Message 21 of 24 in “CR codes from git commands”
  1. Brent GoodrickJan 20, 2009
  2. Johannes SchindelinJan 20, 2009
  3. Daniel BarkalowJan 22, 2009
  4. Brent GoodrickJan 22, 2009
  5. Daniel BarkalowJan 22, 2009
  6. Junio C HamanoJan 22, 2009
  7. Mike RalphsonJan 22, 2009
  8. Brent GoodrickJan 22, 2009
  9. Mike RalphsonJan 22, 2009
  10. Johannes SchindelinJan 22, 2009
  11. Daniel BarkalowJan 22, 2009
  12. Johannes SchindelinJan 22, 2009
  13. Brent GoodrickJan 23, 2009
  14. Junio C HamanoJan 23, 2009
  15. Johannes SchindelinJan 23, 2009
  16. Brent GoodrickJan 24, 2009
  17. Johannes SchindelinJan 24, 2009
  18. Boyd Stephen Smith Jr.Jan 25, 2009
  19. Brent GoodrickJan 25, 2009
  20. Brent GoodrickFeb 2, 2009
  21. The lifecycle of a patch and the maintainer involvementJunio C Hamano, Jan 25, 2009
  22. Brent GoodrickJan 21, 2009
  23. Johannes SchindelinJan 21, 2009
  24. Brent GoodrickJan 22, 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.