git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Brent Goodrick <bgoodr@gmail.com>
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>,
	Daniel Barkalow <barkalow@iabervon.org>,
	Mike Ralphson <mike.ralphson@gmail.com>,
	git@vger.kernel.org
Subject: The lifecycle of a patch and the maintainer involvement
Date: Sun, 25 Jan 2009 12:35:30 -0800	[thread overview]
Message-ID: <7v3af7dsz1.fsf@gitster.siamese.dyndns.org> (raw)
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.

      parent reply	other threads:[~2009-01-25 20:37 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-20 16:26 CR codes from git commands Brent Goodrick
2009-01-20 17:08 ` Johannes Schindelin
     [not found]   ` <18806.44057.477379.215492@hungover.brentg.com>
     [not found]     ` <alpine.DEB.1.00.0901210930370.7929@racer>
2009-01-21 14:42       ` Brent Goodrick
2009-01-21 15:38         ` Johannes Schindelin
2009-01-22  4:00           ` Brent Goodrick
2009-01-22  4:47 ` Daniel Barkalow
2009-01-22  7:34   ` Brent Goodrick
2009-01-22  7:46     ` Daniel Barkalow
2009-01-22  8:04       ` Junio C Hamano
2009-01-22 10:04         ` Mike Ralphson
2009-01-22 16:13           ` Brent Goodrick
2009-01-22 16:41             ` Mike Ralphson
2009-01-22 16:50               ` Johannes Schindelin
2009-01-22 16:44             ` Daniel Barkalow
2009-01-22 16:52               ` Johannes Schindelin
2009-01-23 16:12                 ` Brent Goodrick
2009-01-23 16:59                   ` Junio C Hamano
2009-01-23 18:41                   ` Johannes Schindelin
2009-01-24 20:54                     ` Brent Goodrick
2009-01-24 21:14                       ` Johannes Schindelin
2009-01-25  9:19                       ` Boyd Stephen Smith Jr.
2009-01-25 18:47                         ` Brent Goodrick
2009-02-02  7:09                         ` Brent Goodrick
2009-01-25 20:35                       ` Junio C Hamano [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7v3af7dsz1.fsf@gitster.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=barkalow@iabervon.org \
    --cc=bgoodr@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=mike.ralphson@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).