Questions on patch lifecycle

Questions on patch lifecycle

[Roman V. Shaposhnik]

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.

Re: Questions on patch lifecycle

[Shawn O. Pearce]

"Roman V. Shaposhnik" <rvs@sun.com> wrote:
>    0. Junio, are you the only Git maintainer or are there
>       others responsible for particular subsystems of Git?

There are a number of subsystem maintainers, but most stuff
does go through Junio, yes.
   
>    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?

Docmentation/SubmittingPatches

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

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.

-- 
Shawn.

Re: Questions on patch lifecycle

[Paolo Bonzini]

> 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.

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

Re: Questions on patch lifecycle

[Junio C Hamano]

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

> Anyway, here are the questions:
>
>    0. Junio, are you the only Git maintainer or are there others
>    responsible for particular subsystems of Git?

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").

>    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?

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.

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

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".

> 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.

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 ;-)