{"thread":{"id":"61801","subject":"Best practices for indicating what address to send patches to?","startedAt":"2024-07-18T10:49:53Z","lastAt":"2024-07-19T18:25:17Z","messageCount":4,"participants":["Philip Kaludercic","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"498915","messageId":"87msmfrn3r.fsf@posteo.net","threadId":"61801","inReplyTo":null,"subject":"Best practices for indicating what address to send patches to?","fromName":"Philip Kaludercic","fromEmail":"philipk@posteo.net","sentAt":"2024-07-18T10:49:44Z","receivedAt":"2024-07-18T10:49:53Z","isPatch":false,"sender":{"key":"philipk@posteo.net","avatar":null},"body":"\nHi, I was wondering if anyone had a good suggestion on how to indicate\nwhere to send a patch to.  Ideally I'd like to have \"sendemail.to\"\nconfigured on cloning, but that isn't possible IIUC.  There also doesn't\nseem to be a conventional file like \".git-email\" that would list where\nto send a patch, without having to look it up.\n\nIs this intentional, has it been discussed in the past or is there the\nchance that it might be improved upon in the future?\n\n-- \n\tPhilip Kaludercic on peregrine\n"},{"id":"498918","messageId":"xmqqh6cmzspe.fsf@gitster.g","threadId":"61801","inReplyTo":"87msmfrn3r.fsf@posteo.net","subject":"Re: Best practices for indicating what address to send patches to?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-18T14:21:33Z","receivedAt":"2024-07-18T14:21:38Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Kaludercic <philipk@posteo.net> writes:\n\n> Hi, I was wondering if anyone had a good suggestion on how to indicate\n> where to send a patch to.  Ideally I'd like to have \"sendemail.to\"\n> configured on cloning, but that isn't possible IIUC.  There also doesn't\n> seem to be a conventional file like \".git-email\" that would list where\n> to send a patch, without having to look it up.\n>\n> Is this intentional, has it been discussed in the past or is there the\n> chance that it might be improved upon in the future?\n\nThe usual convention is to have the patch submission address (if a\nproject uses e-mail based patch as its workflow) together with other\nrules and guidelines the contributors are expected to adhere to in\ndocuments like README, CONTRIBUTING, etc.  As an e-mailed patch that\ndoes not follow established conventions is not necessarily useful to\nthe receiving projects, it is a good practice to put these pieces of\ninformation crucial to start contributing in a single place.\n\nIt would not be an improvement to add a mechanism to make it easier\nto find \"here is the address\" to a reader who hasn't even discovered\nwhere these contributor guide documents are.\n\nThanks.\n"},{"id":"498972","messageId":"87msmdmfwc.fsf@posteo.net","threadId":"61801","inReplyTo":"xmqqh6cmzspe.fsf@gitster.g","subject":"Re: Best practices for indicating what address to send patches to?","fromName":"Philip Kaludercic","fromEmail":"philipk@posteo.net","sentAt":"2024-07-19T17:48:51Z","receivedAt":"2024-07-19T17:49:00Z","isPatch":false,"sender":{"key":"philipk@posteo.net","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Philip Kaludercic <philipk@posteo.net> writes:\n>\n>> Hi, I was wondering if anyone had a good suggestion on how to indicate\n>> where to send a patch to.  Ideally I'd like to have \"sendemail.to\"\n>> configured on cloning, but that isn't possible IIUC.  There also doesn't\n>> seem to be a conventional file like \".git-email\" that would list where\n>> to send a patch, without having to look it up.\n>>\n>> Is this intentional, has it been discussed in the past or is there the\n>> chance that it might be improved upon in the future?\n>\n> The usual convention is to have the patch submission address (if a\n> project uses e-mail based patch as its workflow) together with other\n> rules and guidelines the contributors are expected to adhere to in\n> documents like README, CONTRIBUTING, etc.  As an e-mailed patch that\n> does not follow established conventions is not necessarily useful to\n> the receiving projects, it is a good practice to put these pieces of\n> information crucial to start contributing in a single place.\n>\n> It would not be an improvement to add a mechanism to make it easier\n> to find \"here is the address\" to a reader who hasn't even discovered\n> where these contributor guide documents are.\n\nBut is that an argument to prevent projects with mild or now contributor\nguidelines to make the patch-driven workflow more difficult?  I've often\ncontributed to a project by quickly checking out the source code,\nchanging something and then sending a patch (this is easier in the\ncontext of Emacs, because we have the a `vc-default-patch-addressee'\nvariable).  My suggestion is by no means to mandate this kind of an\noption, but there are situations where this kind of configurability\nwould be useful, e.g. for Sourcehut projects.\n\n> Thanks.\n\n-- \n\tPhilip Kaludercic on peregrine\n"},{"id":"498974","messageId":"xmqqv811i6ij.fsf@gitster.g","threadId":"61801","inReplyTo":"87msmdmfwc.fsf@posteo.net","subject":"Re: Best practices for indicating what address to send patches to?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-07-19T18:25:08Z","receivedAt":"2024-07-19T18:25:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Philip Kaludercic <philipk@posteo.net> writes:\n\n>> It would not be an improvement to add a mechanism to make it easier\n>> to find \"here is the address\" to a reader who hasn't even discovered\n>> where these contributor guide documents are.\n>\n> But is that an argument to prevent projects with mild or now contributor\n> guidelines to make the patch-driven workflow more difficult?\n\nProjects can actively refuse to use such a \"feature\", if it is\nexpected to encourage undesirable behaviour by new contributors.\nAnd projects that do not care can use such a \"feature\". In that\nsense, I can see a future in which such a \"feature\" exists but not\nused by everybody.  But introducing such a \"feature\" that is not\nnecessarily an improvement and can actively harm projects that use\nit is tricky.  You'd have to document the upsides and the downsides\nto allow projects to make informed decisions if they want to adopt\nit.\n\nStepping back to your original question, you asked if this is\nintentional and if this was discussed in the past.\n\nThe answer is this is more organic and not with an explicit\nintention, but in hindsight, because submission address is just a\nsmall piece of information projects want to publish together with\nother guidelines, not having a mechanism only to give the submission\naddress would *not* have helped projects all that much.  With the\nexplanation behind the answer to the first question it should be\neasy to see why nobody talked about such a \"feature\" in the past,\nwhich is the answer to your second question.\n"}]}