{"thread":{"id":"13206","subject":"Questions on patch lifecycle","startedAt":"2008-04-22T04:11:21Z","lastAt":"2008-04-22T07:47:35Z","messageCount":4,"participants":["Roman V. Shaposhnik","Shawn O. Pearce","Paolo Bonzini","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"74902","messageId":"1208837481.26863.374.camel@goose.sun.com","threadId":"13206","inReplyTo":null,"subject":"Questions on patch lifecycle","fromName":"Roman V. Shaposhnik","fromEmail":"rvs@sun.com","sentAt":"2008-04-22T04:11:21Z","receivedAt":"2008-04-22T04:11:21Z","isPatch":false,"sender":{"key":"rvs@sun.com","avatar":null},"body":"I'm a bit confused by the etiquette around submitting\nproposals for patches in Git and I would like to\nunderstand this process better. Especially since the\nonly way to get closure on .gitconfig issue seems to\nbe to show the code ;-)\n\nAnyway, here are the questions:\n\n 0. Junio, are you the only Git maintainer or are there\n others responsible for particular subsystems of Git?\n \n 1. What's the official way of submitting a patch?\n Is git-send-email(1) to this mailing list\n good enough? Does a submitter have to have\n a public tree that maintainer(s) can pull from?\n\n 2. Once the patch is submitted how does the author\n get notified whether it is accepted, rejected\n or needs additional work.\n\nNow, #2 is especially important for me, simply because\nthe project I come from (FFmpeg) has a bit of different \npolicy around the status of each submitted patch. \nPretty much within a 48 hour window a submitter gets \nnotified whether the patch was accepted, rejected, needs \nmore work or the maintainer of a particular subsystem needs \nmore time in order to review the changes. What's confusing to \nme with Git, are the examples like some patches from Ping Yin \nnot receiving any public acknowledgment at all and some of the \npatches from other submitters (Dmitry Potapov) getting sort of \nlost.\n\nThanks,\nRoman.\n"},{"id":"74903","messageId":"20080422044336.GA29771@spearce.org","threadId":"13206","inReplyTo":"1208837481.26863.374.camel@goose.sun.com","subject":"Re: Questions on patch lifecycle","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-04-22T04:43:36Z","receivedAt":"2008-04-22T04:43:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"\"Roman V. Shaposhnik\" wrote:\n> 0. Junio, are you the only Git maintainer or are there\n> others responsible for particular subsystems of Git?\n\nThere are a number of subsystem maintainers, but most stuff\ndoes go through Junio, yes.\n \n> 1. What's the official way of submitting a patch?\n> Is git-send-email(1) to this mailing list\n> good enough? Does a submitter have to have\n> a public tree that maintainer(s) can pull from?\n\nDocmentation/SubmittingPatches\n\n> 2. Once the patch is submitted how does the author\n> get notified whether it is accepted, rejected\n> or needs additional work.\n\nRejections get emailed to the author, and generally also to the list.\n\nAcceptance needs to be watched for by the author by fetching Junio's\nnightly updates, and seeing if your patch made it into next, or into\npu, or not at all.\n\nIf it isn't there after a couple of days and if you have also not\nreceived a rejection notice indicating why it was not applied,\nit probably got dropped. A polite reminder would then be OK.\n\n-- \nShawn.\n"},{"id":"74911","messageId":"480D85F3.5060707@gnu.org","threadId":"13206","inReplyTo":"20080422044336.GA29771@spearce.org","subject":"Re: Questions on patch lifecycle","fromName":"Paolo Bonzini","fromEmail":"bonzini@gnu.org","sentAt":"2008-04-22T06:30:11Z","receivedAt":"2008-04-22T06:30:11Z","isPatch":false,"sender":{"key":"bonzini@gnu.org","avatar":"https://avatars.githubusercontent.com/u/42082?v=4"},"body":"\n> Acceptance needs to be watched for by the author by fetching Junio's\n> nightly updates, and seeing if your patch made it into next, or into\n> pu, or not at all.\n\nAlso, if it is not, you can use the \"What's cooking\" messages to \nunderstand if it fell through the cracks of Junio's mailboxes or if he \njust had no time to look at it.\n\nPaolo\n"},{"id":"74920","messageId":"7vve2a2uw8.fsf@gitster.siamese.dyndns.org","threadId":"13206","inReplyTo":"1208837481.26863.374.camel@goose.sun.com","subject":"Re: Questions on patch lifecycle","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-04-22T07:47:35Z","receivedAt":"2008-04-22T07:47:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Roman V. Shaposhnik\" writes:\n\n> Anyway, here are the questions:\n>\n> 0. Junio, are you the only Git maintainer or are there others\n> responsible for particular subsystems of Git?\n\nI delegate some parts of the git.git tree to others to different degrees,\nbut the overall idea is this.\n\nI do not do this as a full time job (is there a big pocket Open Source\ncompany who wants to buy bragging rights to say \"we support git\" by\nemploying me and letting me do git and nothing else? ;-).\n\nThere are many occasions that I would say \"I do not see this patch helping\nmy use of git personally, neither I see how this would help people. I\nmight find a valid use case for some workflows other people may use _if_ I\nthink about it long enough, but I am pressed on time, so I'll pass and see\nwhat others on the list say\".\n\n\"What others on the list say\" does not mean simply majority for several\nreasons. Judgement of some people I trust more than others, simply\nbecause I worked with them longer and know their strength and weakness\nwell, but more importantly, a single convincing argument explaining why it\nis a bad (or good) idea clearly far outweighs a dozen mee-too's that\nwithout stating their reasoning well enough to make people with other\nopinions reconsider their positions.\n\nThe strongest trust comes from trees I pull from others, such as gitk and\ngit-gui. Unless I have a very strong reason to judge their newly added\nhistory as a crap that needs to be rebuilt (luckily which never happened\nas far as I recall so far), I honor the subsystem maintainer's\njudgements. The same applies to various pieces and people, such as Eric\non git-svn, Nico on pack generation, etc (see \"A note from the\nmaintainer\").\n\n> 1. What's the official way of submitting a patch? Is\n> git-send-email(1) to this mailing list good enough? Does a submitter\n> have to have a public tree that maintainer(s) can pull from?\n\nCurrently a review on the list is considered mandatory, even if you\nmaintain a clean history people (not limited to me) can pull from.\n\nMy preference of the patch flow is that the initial round of the series\n(unless it is unarguably correct bugfix and/or a pure enhancement that is\nunarguably a good thing to do --- the latter is almost never true, though)\nis sent to the list, with people who have been involved in the part of the\nsystem in the past CC'ed, and after some discussion and improvements if\nand when the list reaches concensus that it is a good thing to do, a final\nsubmission is made To: me with list CC'ed.\n\n> 2. Once the patch is submitted how does the author get notified\n> whether it is accepted, rejected or needs additional work.\n\nYou forgot two more important cases. \"Nobody seemed to be interested in\nit.\" and \"Objections and/or improvement suggestions have been raised\".\n\nI try to send a single-liner \"applied\" message (often off-list) to the\nsubmitter but again I am not doing this full-time, so I often omit this\nwhen I know I am soon going to send out \"What's cooking\".\n\nObjections and suggestions can come from me or more often from list\nmembers. That's review process. I may or may not pick it up while a such\npatch is \"in flight\".\n\n> What's confusing to me with Git, are the examples like some patches from\n> Ping Yin not receiving any public acknowledgment at all and some of the\n> patches from other submitters (Dmitry Potapov) getting sort of lost.\n\nPatches that do get negative reviews and left as initially posted without\nimprovement tend to get dropped, but obviously good ones can also get lost\nwhen there is not much interest from the list. Be persistent and patient.\n\nI still remember that it took me more than half a dozen tries to get\nformat-patch in when Linus was running the show ;-)\n"}]}