Questions on patch lifecycle

I'm a bit confused by the etiquette around submitting proposals for patches in Git and I would like to understand this process better. Especially since the only way to get closure on .gitconfig issue seems to be to show the code ;-)

Anyway, here are the questions:

   0. Junio, are you the only Git maintainer or are there
      others responsible for particular subsystems of Git?
  
   1. What's the official way of submitting a patch?
      Is git-send-email(1) to this mailing list
      good enough? Does a submitter have to have
      a public tree that maintainer(s) can pull from?

   2. Once the patch is submitted how does the author
      get notified whether it is accepted, rejected
      or needs additional work.

Now, #2 is especially important for me, simply because the project I come from (FFmpeg) has a bit of different policy around the status of each submitted patch. Pretty much within a 48 hour window a submitter gets notified whether the patch was accepted, rejected, needs more work or the maintainer of a particular subsystem needs more time in order to review the changes. What's confusing to me with Git, are the examples like some patches from Ping Yin not receiving any public acknowledgment at all and some of the patches from other submitters (Dmitry Potapov) getting sort of lost.

Thanks, Roman.

"Roman V. Shaposhnik" <rvs@sun.com> wrote:

There are a number of subsystem maintainers, but most stuff
does go through Junio, yes.
   

Docmentation/SubmittingPatches

Rejections get emailed to the author, and generally also to the list.

Acceptance needs to be watched for by the author by fetching Junio's nightly updates, and seeing if your patch made it into next, or into pu, or not at all.

If it isn't there after a couple of days and if you have also not received a rejection notice indicating why it was not applied, it probably got dropped. A polite reminder would then be OK.

Also, if it is not, you can use the "What's cooking" messages to understand if it fell through the cracks of Junio's mailboxes or if he just had no time to look at it.

Paolo

"Roman V. Shaposhnik" <rvs@sun.com> writes:

I delegate some parts of the git.git tree to others to different degrees, but the overall idea is this.

I do not do this as a full time job (is there a big pocket Open Source company who wants to buy bragging rights to say "we support git" by employing me and letting me do git and nothing else? ;-).

There are many occasions that I would say "I do not see this patch helping my use of git personally, neither I see how this would help people. I might find a valid use case for some workflows other people may use _if_ I think about it long enough, but I am pressed on time, so I'll pass and see what others on the list say".

"What others on the list say" does not mean simply majority for several reasons. Judgement of some people I trust more than others, simply because I worked with them longer and know their strength and weakness well, but more importantly, a single convincing argument explaining why it is a bad (or good) idea clearly far outweighs a dozen mee-too's that without stating their reasoning well enough to make people with other opinions reconsider their positions.

The strongest trust comes from trees I pull from others, such as gitk and git-gui. Unless I have a very strong reason to judge their newly added history as a crap that needs to be rebuilt (luckily which never happened as far as I recall so far), I honor the subsystem maintainer's judgements. The same applies to various pieces and people, such as Eric on git-svn, Nico on pack generation, etc (see "A note from the maintainer").

Currently a review on the list is considered mandatory, even if you maintain a clean history people (not limited to me) can pull from.

My preference of the patch flow is that the initial round of the series (unless it is unarguably correct bugfix and/or a pure enhancement that is unarguably a good thing to do --- the latter is almost never true, though) is sent to the list, with people who have been involved in the part of the system in the past CC'ed, and after some discussion and improvements if and when the list reaches concensus that it is a good thing to do, a final submission is made To: me with list CC'ed.

You forgot two more important cases. "Nobody seemed to be interested in it." and "Objections and/or improvement suggestions have been raised".

I try to send a single-liner "applied" message (often off-list) to the submitter but again I am not doing this full-time, so I often omit this when I know I am soon going to send out "What's cooking".

Objections and suggestions can come from me or more often from list members. That's review process. I may or may not pick it up while a such patch is "in flight".

Patches that do get negative reviews and left as initially posted without improvement tend to get dropped, but obviously good ones can also get lost when there is not much interest from the list. Be persistent and patient.

I still remember that it took me more than half a dozen tries to get format-patch in when Linus was running the show ;-)