"Roman V. Shaposhnik" <rvs@xxxxxxx> 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 ;-) -- 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
