{"thread":{"id":"61163","subject":"A note from the maintainer","startedAt":"2024-03-20T16:07:09Z","lastAt":"2024-03-22T02:44:34Z","messageCount":9,"participants":["Junio C Hamano","Brian Lyles"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"491018","messageId":"xmqqr0g4hopl.fsf@gitster.g","threadId":"61163","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-20T16:07:02Z","receivedAt":"2024-03-20T16:07:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"I used to send this soon after each feature release, but somehow I\nforgot for about a full year X-<. Better late than never, I guess.\n\n--- >8 ---\nWelcome to the Git development community.\n\nThis message is written by the maintainer and talks about how Git\nproject is managed, and how you can work with it.\n\nThe current maintainer is Junio C Hamano . Spam\nfilters learned that legitimate messages come only from a very few\nsender addresses that are known to be good to this address, and all\nother messages are likely to be spam unless they are also sent to the\nmailing list at the same time (i.e. \"Reply-all\" to the list message\nwould reach the mailbox, but \"Reply\" will likely be thrown into the\nspam folder), so please do not send a message to this address unless\nit is also sent to the mailing list as well.\n\n\n* Mailing list and the community\n\nThe development is primarily done on the Git mailing list. Help\nrequests, feature proposals, bug reports and patches should be sent to\nthe list address . You don't have to be\nsubscribed to send messages. The convention on the list is to keep\neverybody involved on Cc:, so it is unnecessary to say \"Please Cc: me,\nI am not subscribed\".\n\nAs an anti-spam measure, the mailing list software rejects messages\nthat are not text/plain and drops them on the floor. If you are a\nGMail user, you'd want to make sure \"Plain text mode\" is checked.\n\nBefore sending patches, please read Documentation/SubmittingPatches\nand Documentation/CodingGuidelines to familiarize yourself with the\nproject convention.\n\nIf you sent a patch and you did not hear any response from anybody for\nseveral days, it could be that your patch was totally uninteresting,\nbut it also is possible that it was simply lost in the noise. Please\ndo not hesitate to send a reminder message in such a case. Messages\ngetting lost in the noise may be a sign that those who can evaluate\nyour patch don't have enough mental/time bandwidth to process them\nright at the moment, and it often helps to wait until the list traffic\nbecomes calmer before sending such a reminder.\n\nThe list archive is available at a few public sites:\n\n https://lore.kernel.org/git/\n https://marc.info/?l=git\n https://www.spinics.net/lists/git/\n\nFor those who prefer to read it over NNTP:\n\n\tnntp://nntp.lore.kernel.org/org.kernel.vger.git\n nntp://news.public-inbox.org/inbox.comp.version-control.git\n\nare available.\n\nWhen you point at a message in a mailing list archive, using its\nmessage ID is often the most robust (if not very friendly) way to do\nso, like this:\n\n\thttps://lore.kernel.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org\n\nOften these web interfaces accept the message ID with enclosing <>\nstripped (like the above example to point at one of the most important\nmessage in the Git list).\n\nSome members of the development community can sometimes be found on\nthe #git and #git-devel IRC channels on Libera Chat. Their logs are\navailable at:\n\n https://colabti.org/ircloggy/git/last\n https://colabti.org/ircloggy/git-devel/last\n\nThere is a volunteer-run newsletter to serve our community (\"Git Rev\nNews\" https://git.github.io/rev_news/).\n\nGit is a member project of software freedom conservancy, a non-profit\norganization (https://sfconservancy.org/). To reach a committee of\nliaisons to the conservancy, contact them at .\n\nFor our expectations on the behaviour of the community participants\ntowards each other, see CODE_OF_CONDUCT.md at the top level of the source\ntree, or:\n\n https://github.com/git/git/blob/master/CODE_OF_CONDUCT.md\n\n\n* Reporting bugs\n\nWhen you think git does not behave as you expect, please do not stop\nyour bug report with just \"git does not work\". \"I used git in this\nway, but it did not work\" is not much better, neither is \"I used git\nin this way, and X happend, which is broken\". It often is that git is\ncorrect to cause X happen in such a case, and it is your expectation\nthat is broken. People would not know what other result Y you\nexpected to see instead of X, if you left it unsaid.\n\nPlease remember to always state\n\n - what you wanted to achieve;\n\n - what you did (the version of git and the command sequence to reproduce\n the behavior);\n\n - what you saw happen (X above);\n\n - what you expected to see (Y above); and\n\n - how the last two are different.\n\nSee https://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further\nhints. Our `git bugreport` tool gives you a handy way you can use to\nmake sure you do not forget these points when filing a bug report.\n\nIf you think you found a security-sensitive issue and want to disclose\nit to us without announcing it to wider public, please contact us at\nour security mailing list . This is\na closed list that is limited to people who need to know early about\nvulnerabilities, including:\n\n - people triaging and fixing reported vulnerabilities\n - people operating major git hosting sites with many users\n - people packaging and distributing git to large numbers of people\n\nwhere these issues are discussed without risk of the information\nleaking out before we're ready to make public announcements.\n\n\n* Repositories and documentation.\n\nMy public git.git repositories are (mirrored) at:\n\n https://git.kernel.org/pub/scm/git/git.git/\n https://kernel.googlesource.com/pub/scm/git/git\n https://repo.or.cz/alt-git.git/\n https://github.com/git/git/\n https://gitlab.com/git-vcs/git/\n\nThis one shows not just the main integration branches, but also\nindividual topics broken out:\n\n https://github.com/gitster/git/\n\nA few web interfaces are found at:\n\n https://git.kernel.org/pub/scm/git/git.git\n https://kernel.googlesource.com/pub/scm/git/git\n https://repo.or.cz/w/alt-git.git\n\nPreformatted documentation from the tip of the \"master\" branch can be\nfound in:\n\n https://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/\n https://repo.or.cz/git-{htmldocs,manpages}.git/\n https://github.com/gitster/git-{htmldocs,manpages}.git/\n\nThe manual pages formatted in HTML for the tip of 'master' can be\nviewed online at:\n\n https://git.github.io/htmldocs/git.html\n\n\n* How various branches are used.\n\nThere are four \"integration\" branches in git.git repository that track\nthe source tree of git: \"master\", \"maint\", \"next\", and \"seen\". They\nhowever almost never get new commits made directly on them. Instead,\na branch is forked from either \"master\" or \"maint\" for each \"topic\",\nwhether it is a new feature or a fix for a bug, and holds a set of\ncommits that belong to the same theme. Such a \"topic branch\" is then\nmerged to these integration branches.\n\nThe \"master\" branch is meant to contain what are very well tested and\nready to be used in a production setting. Every now and then, a\n\"feature release\" is cut from the tip of this branch. They used to be\nnamed with three dotted decimal digits (e.g., \"1.8.5\"), but we have\nswitched the versioning scheme and \"feature releases\" are named with\nthree-dotted decimal digits that ends with \".0\" (e.g., \"1.9.0\").\n\nThe last such release was 2.44 done on Feb 22nd, 2024. We aim to keep\nthat the tip of the \"master\" branch is always more stable than any of\nthe released versions.\n\nWhenever a feature release is made, \"maint\" branch is forked off from\n\"master\" at that point. Obvious and safe fixes after a feature\nrelease are merged to this branch and maintenance releases are cut\nfrom it. Usually the topic branches that contain these fixes are\nmerged to the \"master\" branch first, before getting merged to the\n\"maint\" branch, to reduce the chance of last-minute issues, but\nthings like embargoed security fixes may first appear in the \"maint\"\nand merged up to \"master\" at the same time. The maintenance releases\nused to be named with four dotted decimal, named after the feature\nrelease they are updates to (e.g., \"1.8.5.1\" was the first maintenance\nrelease for \"1.8.5\" feature release). These days, maintenance releases\nare named by incrementing the last digit of three-dotted decimal name\n(e.g., \"2.43.2\" was the second maintenance release for the \"2.43\" series).\n\nNew features almost never go to the \"maint\" branch. It is merged into\n\"master\" primarily to propagate the description in the release notes\nforward.\n\nWhen you send a series of patches, after review discussions on the\nmailing list, a separate topic branch is forked from the tip of\n\"master\" (or somewhere older, especially when the topic is about\nfixing an earlier bug) and your patches are applied on that topic\nbranch, and kept out of \"master\" while people test it out. The\nquality of topic branches are judged primarily by the mailing list\ndiscussions.\n\nTopic branches that are in good shape are merged to the \"next\" branch.\nThe \"next\" branch is where new and exciting things take place. In\ngeneral, the \"next\" branch always contains the tip of \"master\". It\nmight not be quite rock-solid, but is expected to work more or less\nwithout major breakage. A topic that is in \"next\" is expected to be\npolished to perfection before it is merged to \"master\". Please help\nthis process by building & using the \"next\" branch for your daily\nwork, and reporting any new bugs you find to the mailing list, before\nthe breakage is merged down to the \"master\".\n\nThe \"seen\" (formerly \"pu\", proposed updates) branch bundles the\nremaining topic branches the maintainer happens to have seen to remind\nthe maintainer that the topics in them might become interesting when\nthey are polished.\n\nThe contributors can use it to anticipate what topics from others\nmay cause conflict with their own work, and find people who are\nworking on these topics to talk to before the potential conflicts\nget out of control. It would be a good idea to fork from maint or\nmaster to grow a topic and to test (1) it by itself, (2) a temporary\nmerge of it to 'next' and (3) a temporary merge to it to 'seen',\nbefore publishing it.\n\nConsider that a topic only in \"seen\" is not part of \"git\" yet. When a\ntopic that was in \"seen\" proves to be in a testable shape, it is\nmerged to \"next\".\n\nYou can run \"git log --first-parent master..seen\" to see what topics\nare currently in flight. Sometimes, a topic that looked promising\nproves to be a bad idea and the topic gets dropped from \"seen\" in such\na case. The output of the above \"git log\" talks about a \"jch\" branch,\nwhich is an early part of the \"seen\" branch; that branch contains all\ntopics that are in \"next\" and a bit more (but not all of \"seen\") and\nis used by the maintainer for his daily work.\n\nThe two branches \"master\" and \"maint\" are never rewound, and \"next\"\nusually will not be either. After a feature release is made from\n\"master\", however, \"next\" will be rebuilt from the tip of \"master\"\nusing the topics that didn't make the cut in the feature release.\nSome topics that used to be in \"next\" during the previous cycle may\nget ejected from \"next\" when this happens.\n\nA natural consequence of how \"next\" and \"seen\" bundles topics together\nis that until a topic is merged to \"next\", updates to it is expected\nby replacing the patch(es) in the topic with an improved version, and\nonce a topic is merged to \"next\", updates to it needs to come as\nincremental patches, pointing out what was wrong in the previous\npatches and how the problem was corrected. The idea is that if many\nreviewers thought it has seen enough eyeballs and is good enough for\n\"next\", yet we later find that there was something we all missed, that\nis worth a separate explanation, e.g., \"The primary motivation behind\nthe series is still good, but for such and such reasons we missed this\ncase we are fixing.\", hence we prefer follow-up incremental patches.\n\nNote that being in \"next\" is not a guarantee to appear in the next\nrelease, nor even in any future release. There were cases that topics\nneeded reverting a few commits in them before graduating to \"master\",\nor a topic that already was in \"next\" was reverted from \"next\" because\nfatal flaws were found in it after it was merged to \"next\".\n\n\n* Other people's trees.\n\nDocumentation/SubmittingPatches outlines to whom your proposed changes\nshould be sent. As described in contrib/README, I would delegate fixes\nand enhancements in contrib/ area to the primary contributors of them.\n\nAlthough the following are included in git.git repository, they have their\nown authoritative repository and maintainers:\n\n - git-gui/ comes from git-gui project, maintained by Pratyush Yadav:\n\n https://github.com/prati0100/git-gui.git\n\n - gitk-git/ comes from Paul Mackerras's gitk project:\n\n git://ozlabs.org/~paulus/gitk\n\n - po/ comes from the localization coordinator, Jiang Xin:\n\n\thttps://github.com/git-l10n/git-po/\n\nWhen sending proposed updates and fixes to these parts of the system,\nplease base your patches on these trees, not git.git (the former two\neven have different directory structures).\n"},{"id":"491083","messageId":"17be9ebbcb24ec98.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61163","inReplyTo":"xmqqr0g4hopl.fsf@gitster.g","subject":"Re: A note from the maintainer","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-21T00:03:57Z","receivedAt":"2024-03-21T00:04:00Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"Hi Junio\n\nOn Wed, Mar 20, 2024 at 11:18 AM Junio C Hamano wrote:\n\n> If you sent a patch and you did not hear any response from anybody for\n> several days, it could be that your patch was totally uninteresting,\n> but it also is possible that it was simply lost in the noise. Please\n> do not hesitate to send a reminder message in such a case. Messages\n> getting lost in the noise may be a sign that those who can evaluate\n> your patch don't have enough mental/time bandwidth to process them\n> right at the moment, and it often helps to wait until the list traffic\n> becomes calmer before sending such a reminder.\n\nI think it would be good to revise this wording in future iterations.\n\"Totally uninteresting\" is a bit ambiguous, and also sounds quite\nnegative (at least to me).\n\nTo me, this initially sounded like it meant \"your patch was not\nsomething that the git maintainers would be interested in accepting\". I\n*suspect* that what is actually meant here is \"your patch was\nstraightforward and non-controversial to the point that no members of\nthe list saw it and felt the need to comment on it\", though to be honest\nI am not 100% sure.\n\nIf it is expected that a \"totally uninteresting\" patch might, in fact,\nend up in your tree without further comment, I think it could be helpful\nto indicate that as well.\n\nHere is what comes to my mind based on my (very likely not full)\nunderstanding of the process:\n\n If you have sent a patch to the list and have not heard any response\n\tfor several days, a few things may have happened:\n\t\n\t- Your patch was straightforward and non-controversial, so no\n\t members of the list felt the need to comment on it\n\t- The members of the list that would review your patch do not have\n\t the time to process them at the moment\n\t- Your patch was simply lost in the noise\n\n\tIf you are unsure, keep an eye on the next few \"What's cooking in\n\tgit.git\" emails. If your patch does not make an appearance there\n\twithin a week or so, you may want to send out a reminder. It often\n\thelps to wait until the list traffic becomes calmer before sending a\n\treminder.\n\nI don't know how accurate that actually is, but I think it conveys the\ntone and clarity that I am getting at.\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491086","messageId":"xmqq4jd0fle4.fsf@gitster.g","threadId":"61163","inReplyTo":"17be9ebbcb24ec98.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-21T01:01:39Z","receivedAt":"2024-03-21T01:01:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" writes:\n\n> To me, this initially sounded like it meant \"your patch was not\n> something that the git maintainers would be interested in accepting\". I\n> *suspect* that what is actually meant here is \"your patch was\n> straightforward and non-controversial to the point that no members of\n> the list saw it and felt the need to comment on it\", though to be honest\n> I am not 100% sure.\n\nI actually meant what I wrote.\n\nIt is possible that the reason why your patch did not receive any\nresponse was because it was uninspiring, looked useless, and did not\ndeserve anybody's attention. But it is also possible that it was\nlost in the noise.\n\nAnd pinging on the topic by responding to your own message is not\njust acceptable but very much appreciated way to remind others who\nmay have missed it, in case it is the latter.\n\nIf a topic is truly obvious and straight-forward, it may be taken\nsilently to 'seen' and even to 'next', and since it is suggested for\nthe contributors to look at \"master..seen\", such a topic would not\nfall into the \"hear nothing about it from anybody for a long time\"\ncategory anyway.\n"},{"id":"491089","messageId":"17bea3e3320609ca.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61163","inReplyTo":"xmqq4jd0fle4.fsf@gitster.g","subject":"Re: A note from the maintainer","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-21T01:38:24Z","receivedAt":"2024-03-21T01:38:26Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"On Wed, Mar 20, 2024 at 8:01 PM Junio C Hamano wrote:\n\n> \"Brian Lyles\" writes:\n> \n>> To me, this initially sounded like it meant \"your patch was not\n>> something that the git maintainers would be interested in accepting\". I\n>> *suspect* that what is actually meant here is \"your patch was\n>> straightforward and non-controversial to the point that no members of\n>> the list saw it and felt the need to comment on it\", though to be honest\n>> I am not 100% sure.\n> \n> I actually meant what I wrote.\n> \n> It is possible that the reason why your patch did not receive any\n> response was because it was uninspiring, looked useless, and did not\n> deserve anybody's attention. But it is also possible that it was\n> lost in the noise.\n> \n> And pinging on the topic by responding to your own message is not\n> just acceptable but very much appreciated way to remind others who\n> may have missed it, in case it is the latter.\n> \n> If a topic is truly obvious and straight-forward, it may be taken\n> silently to 'seen' and even to 'next', and since it is suggested for\n> the contributors to look at \"master..seen\", such a topic would not\n> fall into the \"hear nothing about it from anybody for a long time\"\n> category anyway.\n\nThanks for the clarification. I do still think that a change in the\nwording and tone of this section could help make the project appear more\nfriendly to new contributors. Phrases like \"totally uninteresting\",\n\"uninspiring\", \"looked useless\", and \"did not deserve anybody's\nattention\" are all fairly harsh sounding, even if sometimes true.\n\nSomething more along the lines of \"Mailing list members may not have\nseen the value of the proposed changes\" or \"Your patch may not have\npresented a convincing argument for being accepted\" might land a little\nmore gently and make someone more willing to make another attempt at a\nmore compelling patch rather than feeling harshly rejected and leaving\nwith a bad taste in their mouth about the project like has happened in\nthe past [1].\n\n[1]: https://lore.kernel.org/git/xmqq7ck7x10y.fsf@gitster.g/\n\nSimply food for thought from someone relatively new to the list.\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491134","messageId":"xmqqwmpvbufw.fsf@gitster.g","threadId":"61163","inReplyTo":"17bea3e3320609ca.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-21T13:12:03Z","receivedAt":"2024-03-21T13:12:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" writes:\n\n>> I actually meant what I wrote.\n>> \n>> It is possible that the reason why your patch did not receive any\n>> response was because it was uninspiring, looked useless, and did not\n>> deserve anybody's attention. But it is also possible that it was\n>> lost in the noise.\n>> ...\n> Thanks for the clarification. I do still think that a change in the\n> wording and tone of this section could help make the project appear more\n> friendly to new contributors. Phrases like \"totally uninteresting\",\n> \"uninspiring\", \"looked useless\", and \"did not deserve anybody's\n> attention\" are all fairly harsh sounding, even if sometimes true.\n\nYou completely lost me. How much harsh words are used before \"But\nit is also possible\" would not make the project sound less friendly\nat all.\n\nLet me try again.\n\nYou see your patch was sent but did not receive any reaction. You\nmight start thinking: \"hmm, perhaps my patch was so horrible\" and\nyou might think all the bad and harsh things about the quality of\nyour patch.\n\nBut do not let such thought stop you from pinging the thread again,\nbecause the quality of your patch may not at all be the reason why\nyou did not receive any reaction. It could be just people were\nswamped and your patch fell into cracks, and there was nothing wrong\nwith it.\n"},{"id":"491197","messageId":"17bef1274bfb2614.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61163","inReplyTo":"xmqqwmpvbufw.fsf@gitster.g","subject":"Re: A note from the maintainer","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-22T01:14:19Z","receivedAt":"2024-03-22T01:14:21Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"\n\n> \"Brian Lyles\" writes:\n> \n>>> I actually meant what I wrote.\n>>> \n>>> It is possible that the reason why your patch did not receive any\n>>> response was because it was uninspiring, looked useless, and did not\n>>> deserve anybody's attention. But it is also possible that it was\n>>> lost in the noise.\n>>> ...\n>> Thanks for the clarification. I do still think that a change in the\n>> wording and tone of this section could help make the project appear more\n>> friendly to new contributors. Phrases like \"totally uninteresting\",\n>> \"uninspiring\", \"looked useless\", and \"did not deserve anybody's\n>> attention\" are all fairly harsh sounding, even if sometimes true.\n> \n> You completely lost me. How much harsh words are used before \"But\n> it is also possible\" would not make the project sound less friendly\n> at all.\n> \n> Let me try again.\n> \n> You see your patch was sent but did not receive any reaction. You\n> might start thinking: \"hmm, perhaps my patch was so horrible\" and\n> you might think all the bad and harsh things about the quality of\n> your patch.\n> \n> But do not let such thought stop you from pinging the thread again,\n> because the quality of your patch may not at all be the reason why\n> you did not receive any reaction. It could be just people were\n> swamped and your patch fell into cracks, and there was nothing wrong\n> with it.\n\nAh, okay -- I think I am better understanding the intent vs. how I\n(mis)interpreted it initially. My initial interpretation was more along\nthe lines of \"there are two possibilities: Either it was uninteresting,\nor it got missed\". This re-phrasing reads more as \"don't assume it was\nuninteresting, it may have simply been missed\". Both true, but the\nlatter reads better in my opinion.\n\nThank you for clarifying. I will let you decide if some updated wording\nis warranted in future notes from the maintainer, or if I simply\ninterpreted things in a way that you do not think others would.\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491205","messageId":"xmqq7chv58by.fsf@gitster.g","threadId":"61163","inReplyTo":"17bef1274bfb2614.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-22T02:06:09Z","receivedAt":"2024-03-22T02:06:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" writes:\n\n> Thank you for clarifying. I will let you decide if some updated wording\n> is warranted in future notes from the maintainer, or if I simply\n> interpreted things in a way that you do not think others would.\n\nPerhaps like this, then?\n\ndiff --git a/MaintNotes b/MaintNotes\nindex 57aa6dd..18d8bcb 100644\n--- a/MaintNotes\n+++ b/MaintNotes\n@@ -34,8 +34,8 @@ and Documentation/CodingGuidelines to familiarize yourself with the\n project convention.\n \n If you sent a patch and you did not hear any response from anybody for\n-several days, it could be that your patch was totally uninteresting,\n-but it also is possible that it was simply lost in the noise. Please\n+several days, it does not necessarily mean that your patch was totally\n+uninteresting; it may mearly mean that it was lost in the noise. Please\n do not hesitate to send a reminder message in such a case. Messages\n getting lost in the noise may be a sign that those who can evaluate\n your patch don't have enough mental/time bandwidth to process them\n"},{"id":"491213","messageId":"17bef592f076ab87.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","threadId":"61163","inReplyTo":"xmqq7chv58by.fsf@gitster.g","subject":"Re: A note from the maintainer","fromName":"Brian Lyles","fromEmail":"brianmlyles@gmail.com","sentAt":"2024-03-22T02:35:19Z","receivedAt":"2024-03-22T02:35:21Z","isPatch":false,"sender":{"key":"brianmlyles@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1123282?v=4"},"body":"Hi Junio\n\nOn Thu, Mar 21, 2024 at 9:06 PM Junio C Hamano wrote:\n\n> \"Brian Lyles\" writes:\n> \n>> Thank you for clarifying. I will let you decide if some updated wording\n>> is warranted in future notes from the maintainer, or if I simply\n>> interpreted things in a way that you do not think others would.\n> \n> Perhaps like this, then?\n> \n> diff --git a/MaintNotes b/MaintNotes\n> index 57aa6dd..18d8bcb 100644\n> --- a/MaintNotes\n> +++ b/MaintNotes\n> @@ -34,8 +34,8 @@ and Documentation/CodingGuidelines to familiarize yourself with the\n> project convention.\n> \n> If you sent a patch and you did not hear any response from anybody for\n> -several days, it could be that your patch was totally uninteresting,\n> -but it also is possible that it was simply lost in the noise. Please\n> +several days, it does not necessarily mean that your patch was totally\n> +uninteresting; it may mearly mean that it was lost in the noise. Please\n> do not hesitate to send a reminder message in such a case. Messages\n> getting lost in the noise may be a sign that those who can evaluate\n> your patch don't have enough mental/time bandwidth to process them\n\nI think that makes the intended meaning much clearer. Minor spelling\ncorrection: s/mearly/merely/\n\n-- \nThank you,\nBrian Lyles\n"},{"id":"491214","messageId":"xmqqr0g33rzp.fsf@gitster.g","threadId":"61163","inReplyTo":"17bef592f076ab87.70b1dd9aae081c6e.203dcd72f6563036@zivdesk","subject":"Re: A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2024-03-22T02:44:26Z","receivedAt":"2024-03-22T02:44:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Brian Lyles\" writes:\n\n> I think that makes the intended meaning much clearer. Minor spelling\n> correction: s/mearly/merely/\n\nThanks.\n"}]}