{"thread":{"id":"38738","subject":"Is the Git Mailing List dropping messages?","startedAt":"2015-03-07T05:12:45Z","lastAt":"2015-03-09T06:33:28Z","messageCount":3,"participants":["Kyle J. McKay","Matthieu Moy","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"257224","messageId":"43504C6C-5F97-480F-8543-350E04041C11@gmail.com","threadId":"38738","inReplyTo":null,"subject":"Is the Git Mailing List dropping messages?","fromName":"Kyle J. McKay","fromEmail":"mackyle@gmail.com","sentAt":"2015-03-07T05:12:45Z","receivedAt":"2015-03-07T05:12:45Z","isPatch":false,"sender":{"key":"mackyle@gmail.com","avatar":"https://avatars.githubusercontent.com/u/813346?v=4"},"body":"About 10 days ago I sent out this message (just reproducing the \nrelevant headers here):\n\n> From: Kyle J. McKay \n> Date: February 24, 2015 09:16:05 PST\n> To: Junio C Hamano \n> Cc: Git Mailing List \n> Subject: Any chance for a Git v2.1.5 release?\n> Message-Id: \n> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes\n\nAnd I got back a reply (again just the relevant headers):\n\n> From: Junio C Hamano \n> Date: February 24, 2015 11:52:03 PST\n> To: Kyle J. McKay \n> Cc: Git Mailing List \n> Subject: Re: Any chance for a Git v2.1.5 release?\n> Message-Id: \n> Content-Type: text/plain\n\nAnd I responded and that response and the rest of the thread are \navailable on gmane [1], but the first two messages are not. I waited \n10 days just to make sure there were no bounce emails or undeliverable \nnotifications coming back and none did. I have checked the other list \narchives [2] and cannot find the first two messages there either.\n\nI have therefore concluded that the git@vger mailing list ate them for \na late breakfast snack on 2015-02-24.\n\nHas anyone else noticed any problems with their messages to the \ngit@vger list not showing up on the archives?\n\n-Kyle\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/264365\n[2] https://git.wiki.kernel.org/index.php/ \nGitCommunity#Mailing_List_Archives\n\nP.S. The full text of the two first messages is included below:\n\n---- BEGIN FIRST MESSAGE ----\nFrom: Kyle J. McKay \nDate: February 24, 2015 09:16:05 PST\nTo: Junio C Hamano \nCc: Git Mailing List \nSubject: Any chance for a Git v2.1.5 release?\nMessage-Id: \nContent-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes\n\nAs you know, I help out with repo.or.cz. Recently the admins have \nbeen discussing upgrading the version of Git we use in order to \nsupport newer features such as pack bitmaps. While we do use a \nslightly customized gitweb, we have always stuck to an official Git \nrelease for everything else.\n\nRepo.or.cz provides fetch (git, http, https, ssh), browsing (gitweb) \nand push (ssh, https). Additionally, created repositories can be \nmirrors (no push allowed) of other repositories (including svn via git- \nsvn). Email notification of ref changes (along with diffs) can also \nbe requested.\n\nWe are finding that in order to upgrade Git at this point we would \nneed to build a custom Git with cherry picked fixes for various issues \nthat have come up or they would likely be triggered by one of the \nservices repo.or.cz provides. In addition, as there are numerous \nreports of an unresolved issue with git-svn starting with v2.2.0 \nupgrading to v2.2.0 or later presents a problem since we have several \nmirrors that rely on git-svn.\n\nWhich brings us back to the subject of this email, is there any chance \nfor a v2.1.5 release?\n\nAfter reviewing a few release dates:\n\n2011-06-26T12:41:26-07:00 v1.7.6\n2012-02-05T23:51:07-08:00 v1.7.6.6\n\n2013-11-27T12:14:52-08:00 v1.8.5\n2014-02-13T13:42:01-08:00 v1.8.5.5\n\n2014-02-14T11:36:11-08:00 v1.9.0\n2014-05-30T10:15:10-07:00 v1.9.4\n\n2014-05-28T11:04:29-07:00 v2.0.0\n2014-07-30T14:20:01-07:00 v2.0.4\n\n2014-08-15T15:09:28-07:00 v2.1.0\n2014-10-29T10:48:57-07:00 v2.1.3\n\n2014-11-26T13:18:43-08:00 v2.2.0\n2015-01-12T14:06:20-08:00 v2.2.2\n\n2015-02-05T13:24:05-08:00 v2.3.0\n\n(I have omitted the dates of the 5 security releases on 2014-12-17 as \nthat seems like an extraordinary event unlikely to be repeated.)\n\nIt appears that the average support lifespan of a Git release from \ninitial release date through last released maintenance update is \napproximately 2-3 months with the 1.7.6 release being an exception at \na little over 7 months.\n\nIf a v2.1.5 release is out of the question, would it be possible to \nperiodically designate certain Git releases as \"long term support\" \nreleases? Meaning that they would receive maintenance updates (e.g. \nfixes for invalid memory accesses/crashes, regressions or security \nissues) for an extended period of time, say at least 6 months?\n\n\nHere's the analysis that led to this request:\n\n\nGoal 1: add support for symref=HEAD:refs/... capability\n\nGoal 2: add support for pack bitmaps\n\nNice to have: The CVE-2014-9390 fix, but repo.or.cz does not create \nany working trees so it's not mandatory.\n\n\nGoal 1:\n\nsymref=HEAD:refs/... requires at least Git 1.8.4.3. However, \nrepo.or.cz runs git-daemon with read-only access to the repositories \nand since Git 1.8.4.2 shallow clones require write access.\n\nThis was corrected in v2.0.0. So at least v2.0.0 would be needed for \nsymref=HEAD:refs/....\n\n\nGoal 2:\n\nPack bitmap support was added in v2.0.0, but it's probably not a good \nidea to run without 21134714 (pack-objects: turn off bitmaps when we \nsplit packs) just in case which requires at least v2.1.3.\n\n\nNice to have:\n\nIf at least v2.1.3 is required, then we might as well use v2.1.4 since \nthe primary change from v2.1.3 to v2.1.4 is the addition of the \nCVE-2014-9390 fix.\n\n\nWhat about a later release, v2.2.0 or later?\n\n\ngit-svn is reported to suffer from occasional \".git/ \nGit_svn_hash_XXXXXX: Bad file descriptor\" errors since v2.2.0 making \nthat a non-starter. No fix is currently available in the Git \nrepository.\n\nSince 660c889e (sha1_file: add for_each iterators for loose and packed \nobjects) loose objects in alternates directories may not be found when \npruning. This affects v2.2.0 and later. A fix is currently in \nmaster. This is an absolute must have for repo.or.cz as alternates \nare used to implement repository forks.\n\nSince d38379e (make update-server-info more robust), affecting v2.2.x, \nthe files used by non-smart HTTP clients could have the wrong \npermissions. This might preclude them from being updated correctly on \nrepo.or.cz. It would require research to see if repo.or.cz is \naffected. The fix for this d91175b2 (update-server-info: create info/ \n* with mode 0666) was released in v2.3.0.\n\n\nSo why not v2.1.4 then?\n\n\nThere's an XDL_FAST_HASH performance regression that affects v1.7.11 \nand later [1]. But that can be turned off in config.mak.\n\nNew repositories have an extra +x on the config file since v2.1.0 \n(fixed in v2.2.2), but we can compensate with a chmod after creating a \nnew repository.\n\nGit blame has a crashing regression since ea02ffa3 (mailmap: simplify \nmap_user() interface) that affects v1.8.2 and later. The fix is \ncurrently in master. repo.or.cz enables blame in the gitweb interface \nso that would be a serious regression.\n\nThere's an issue with ungetting EOF. That would seem unlikely to \naffect repo.or.cz, but, I wonder if any of the displays used by gitweb \ncould trigger attempts to read a .mailmap or .gitattributes blob? I \ndon't know. Would require research to be certain or just picking up \nthe fix which is currently in master.\n\nThere's a decimal_width overflow regression since dc801e7 (diff -- \nstat: use less columns for change counts) affecting v1.7.11 and later \nthat can lead to an infinite loop in some cases. Presumably either \ngitweb or the diffs sent out by the ref update email notification \nmechanism could trigger this. A fix is currently in master.\n\nThere is a regression since v1.7.1.1 where a fetch from a non-smart \nHTTP source could potentially fail to retrieve the correct objects. \nAs repo.or.cz has several mirrors set up from non-smart HTTP sources a \nfix for this (currently in master) would be nice but is probably not \nmandatory since repo.or.cz is currently running a version of Git with \nthis regression and has not received any reports of failures that \ncould be related to this.\n\nSince fbd4a703 (list-objects: mark more commits as edges in \nmark_edges_uninteresting) affecting v1.8.4.2 and later combined with \n200abe74 (list-objects: only look at cmdline trees with edge_hint) \naffecting v1.9.0 and later there is a performance regression when \npushing with lots of refs to non-shallow repos. The fix 2dacf26d \n(pack-objects: use --objects-edge-aggressive for shallow repos) was \nreleased in v2.3.0.\n\n\n-Kyle\n\n[1] http://thread.gmane.org/gmane.comp.version-control.git/261638\n---- END FIRST MESSAGE ----\n\n---- BEGIN SECOND MESSAGE ----\nFrom: Junio C Hamano \nDate: February 24, 2015 11:52:03 PST\nTo: Kyle J. McKay \nCc: Git Mailing List \nSubject: Re: Any chance for a Git v2.1.5 release?\nMessage-Id: \nContent-Type: text/plain\n\nKyle J. McKay writes:\n\n> Which brings us back to the subject of this email, is there any chance\n> for a v2.1.5 release?\n> ...\n> It appears that the average support lifespan of a Git release from\n> initial release date through last released maintenance update is\n> approximately 2-3 months with the 1.7.6 release being an exception at\n> a little over 7 months.\n\nThat matches my expectation.\n\nA typical cycle lasts for 8-12 weeks, and during that time, topics\nthat are bugfixes that have graduated to the 'master' branch are\nmerged to the 'maint' branch with some lag and then the tip of\n'maint' gets tagged as a maintenance release from time to time.\nSome important but trivial fixes are further merged to older\nmaitenance tracks like 'maint-2.2', 'maint-2.1', etc.\n\nBut these topics downmerged to older maint-* branches have to be\nvery trivial for an obvious reason: there are only 24 hours a day\nand 7 days in a week, and bugs that affect real world use cases are\nfound by using the software in real world use cases. Usually I use\nsomething a bit ahead of 'next' exactly for this reason---we would\nwant to catch bugs before topics are merged to 'master'. Although I\nsometimes have \"let's use 'maint' for my work\" day once or twice\nevery month, I cannot afford to do that for anything older than the\ntip of 'maint' myself.\n\nThe consequence of the above is this. v2.1.1 may be more stable\nthan v2.1.0 and v2.1.2 may be more stable than v2.1.1, but later\ntagged versions on older maintenance tracks are made by merging\ntopics only after \"ah, these are obvious enough\" eyeballing without\nreal use (at least by me), once newer feature release is made and\nthere is a newer maintenance track. I would not be surprised if\nv2.1.5, if it is made, has hidden interactions between the changes\nsince v2.1.4 and the older codebase to cause unforeseen bugs.\n\nWhen I say \"the tip of 'master' is meant to be more stable than any\ntagged versions\", I do mean it.\n\nHaving said all that, if I were to tag maint-2.1 branch as 2.1.5\ntoday, we would have\n\n 6aaf956 is_hfs_dotgit: loosen over-eager match of \\u{..47}\n\nthat does not exist in 2.1.4. Is that what you want?\n\n> If a v2.1.5 release is out of the question, would it be possible to\n> periodically designate certain Git releases as \"long term support\"\n> releases?\n\nI can designate ;-), but I do not think I'd be the right person to\nmaintain or long-term-support it. Are you volunteering to oversee\nthe \"LTS team\"? It would involve:\n\n - Monitor \"git log --first-parent maint-lts..master\" and find\n the tip of topic branches that need to be down-merged;\n\n - Down-merge such topics to maint-lts; this might involve\n cherry-picking instead of merge, as the bugfix topics may\n originally be done on the codebase newer than maint-lts;\n\n - Use the tip of the maint-lts branch in everyday work.\n\nThe last item is the most important of the above, because I do not\nhave time for that. I can help with the first two to some degree,\nthough.\n\nIf the lts releases need to be tagged and published by me, then lts\nteam can have me pull from the tip of maint-lts they are confident\nwith and have me sign it and push it out.\n\nIf the primary concern you have with the currently maintained\nreleases is git-svn, perhaps a better way forward for you,\nespecially if you are willing to maintain your own \"release plus\npatches\", might be to keep a patch that reverts recent git-svn\nchanges back to v2.1.whatever and deploy the up-to-date release\nand that patch on top?\n\n> Nice to have: The CVE-2014-9390 fix, but repo.or.cz does not create\n> any working trees so it's not mandatory.\n\nEven if you do not have a working tree, people who use you as the\nmeeting place and push into you and fetch from you do, so I do not\nnecessarily agree with your assessment.\n---- END SECOND MESSAGE ----\n"},{"id":"257315","messageId":"vpq4mpv4wpz.fsf@anie.imag.fr","threadId":"38738","inReplyTo":"43504C6C-5F97-480F-8543-350E04041C11@gmail.com","subject":"Re: Is the Git Mailing List dropping messages?","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2015-03-08T10:20:08Z","receivedAt":"2015-03-08T10:20:08Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Kyle J. McKay\" writes:\n\n> About 10 days ago I sent out this message (just reproducing the\n> relevant headers here):\n>\n>> From: Kyle J. McKay \n>> Date: February 24, 2015 09:16:05 PST\n>> To: Junio C Hamano \n>> Cc: Git Mailing List \n>> Subject: Any chance for a Git v2.1.5 release?\n>> Message-Id: \n>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes\n>\n> And I got back a reply (again just the relevant headers):\n>\n>> From: Junio C Hamano \n>> Date: February 24, 2015 11:52:03 PST\n>> To: Kyle J. McKay \n>> Cc: Git Mailing List \n>> Subject: Re: Any chance for a Git v2.1.5 release?\n>> Message-Id: \n>> Content-Type: text/plain\n>\n> And I responded and that response and the rest of the thread are\n> available on gmane [1], but the first two messages are not.\n\nIndeed, in my mailbox the first message of the thread is:\n\nSubject: Re: Any chance for a Git v2.1.5 release?\nReferences: \nMessage-Id: <2D3EB6D1-3029-4F60-AF29-E044E92DB036@gmail.com>\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"257364","messageId":"20150309063327.GC27128@peff.net","threadId":"38738","inReplyTo":"43504C6C-5F97-480F-8543-350E04041C11@gmail.com","subject":"Re: Is the Git Mailing List dropping messages?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2015-03-09T06:33:28Z","receivedAt":"2015-03-09T06:33:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 06, 2015 at 09:12:45PM -0800, Kyle J. McKay wrote:\n\n> And I responded and that response and the rest of the thread are available\n> on gmane [1], but the first two messages are not. I waited 10 days just to\n> make sure there were no bounce emails or undeliverable notifications coming\n> back and none did. I have checked the other list archives [2] and cannot\n> find the first two messages there either.\n> \n> I have therefore concluded that the git@vger mailing list ate them for a\n> late breakfast snack on 2015-02-24.\n\nI didn't get them either. I think it's clear that vger ate them.\n\nvger will drop anything it thinks is spam. That's often by triggering\nthe taboo list[1], though I don't see anything in the messages below\nthat would do so. Badly formatted messages can be a problem, as well\n(e.g., missing message-ids or dates, I think).\n\n-Peff\n\n[1] Try https://github.com/git/git/blob/todo/taboo.perl to check\n the taboo list locally.\n"}]}