{"thread":{"id":"43798","subject":"A note from the maintainer","startedAt":"2016-08-12T19:55:57Z","lastAt":"2016-08-14T22:52:23Z","messageCount":11,"participants":["Junio C Hamano","Eric Wong","Jeff King","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"298886","messageId":"xmqq1t1twymf.fsf@gitster.mtv.corp.google.com","threadId":"43798","inReplyTo":null,"subject":"A note from the maintainer","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-08-12T19:55:36Z","receivedAt":"2016-08-12T19:55:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Welcome 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\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 <git@vger.kernel.org>.  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\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        http://public-inbox.org/git/\n        http://marc.info/?l=git\n        http://www.spinics.net/lists/git/\n\nFor those who prefer to read it over NNTP:\n\n\tnntp://news.gmane.org/gmane.comp.version-control.git\n\nis still available.  An alternative\n\n        nntp://news.public-inbox.org/inbox.comp.version-control.git\n\nwill become usable once it catches up with old messages.\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\thttp://public-inbox.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 Freenode.  Their logs are\navailable at:\n\n        http://colabti.org/irclogger/irclogger_log/git\n        http://colabti.org/irclogger/irclogger_log/git-devel\n\nThere is a volunteer-run newsletter to serve our community (\"Git Rev\nNews\" http://git.github.io/rev_news/rev_news.html).\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 <git@sfconservancy.org>.\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 expected\nto 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 http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further\nhints.\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 <git-security@googlegroups.com>.  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 at:\n\n  git://git.kernel.org/pub/scm/git/git.git/\n  https://kernel.googlesource.com/pub/scm/git/git\n  git://repo.or.cz/alt-git.git/\n  https://github.com/git/git/\n  git://git.sourceforge.jp/gitroot/git-core/git.git/\n  git://git-core.git.sourceforge.net/gitroot/git-core/git-core/\n\nA few web interfaces are found at:\n\n  http://git.kernel.org/cgit/git/git.git\n  https://kernel.googlesource.com/pub/scm/git/git\n  http://repo.or.cz/w/alt-git.git\n\nPreformatted documentation from the tip of the \"master\" branch can be\nfound in:\n\n  git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/\n  git://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 branches in git.git repository that track the source tree\nof git: \"master\", \"maint\", \"next\", and \"pu\".\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 recently we\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.9 done on June 13th, 2016. You can expect\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 applied to this branch and maintenance releases are cut\nfrom it.  Usually the fixes are merged to the \"master\" branch first,\nseveral days before merged to the \"maint\" branch, to reduce the chance\nof last-minute issues.  The maintenance releases used to be named with\nfour dotted decimal, named after the feature release they are updates\nto (e.g. \"1.8.5.1\" was the first maintenance release for \"1.8.5\"\nfeature release).  These days, maintenance releases are named by\nincrementing the last digit of three-dotted decimal name (e.g. \"2.9.3\"\nis the third maintenance release for the \"2.9\" series).\n\nNew features never go to the 'maint' branch.  This branch is also\nmerged into \"master\" to propagate the fixes forward as needed.\n\nA new development does not usually happen on \"master\". When you send a\nseries of patches, after review on the mailing list, a separate topic\nbranch is forked from the tip of \"master\" and your patches are queued\nthere, and kept out of \"master\" while people test it out. The quality of\ntopic branches are judged primarily by the mailing list discussions.\n\nTopic branches that are in good shape are merged to the \"next\" branch. In\ngeneral, the \"next\" branch always contains the tip of \"master\".  It might\nnot be quite rock-solid, but is expected to work more or less without major\nbreakage. The \"next\" branch is where new and exciting things take place. A\ntopic that is in \"next\" is expected to be polished to perfection before it\nis merged to \"master\".  Please help this process by building & using the\n\"next\" branch for your daily work, and reporting any new bugs you find to\nthe mailing list, before the breakage is merged down to the \"master\".\n\nThe \"pu\" (proposed updates) branch bundles all the remaining topic\nbranches the maintainer happens to have seen.  There is no guarantee that\nthe maintainer has enough bandwidth to pick up any and all topics that\nare remotely promising from the list traffic, so please do not read\ntoo much into a topic being on (or not on) the \"pu\" branch.  This\nbranch is mainly to remind the maintainer that the topics in them may\nturn out to be interesting when they are polished, nothing more.  The\ntopics on this branch aren't usually complete, well tested, or well\ndocumented and they often need further work.  When a topic that was\nin \"pu\" proves to be in a testable shape, it is merged to \"next\".\n\nYou can run \"git log --first-parent master..pu\" to see what topics are\ncurrently in flight.  Sometimes, an idea that looked promising turns out\nto be not so good and the topic can be dropped from \"pu\" in such a case.\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.\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 Pat Thoyts:\n\n        git://repo.or.cz/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":"298933","messageId":"20160812224255.GA16250@dcvr","threadId":"43798","inReplyTo":"xmqq1t1twymf.fsf@gitster.mtv.corp.google.com","subject":"Re: A note from the maintainer","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-12T22:42:55Z","receivedAt":"2016-08-12T22:43:01Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Junio C Hamano <gitster@pobox.com> wrote:\n> For those who prefer to read it over NNTP:\n> \n> \tnntp://news.gmane.org/gmane.comp.version-control.git\n> \n> is still available.  An alternative\n> \n>         nntp://news.public-inbox.org/inbox.comp.version-control.git\n> \n> will become usable once it catches up with old messages.\n\nMostly caught up, I injected 33 more today which were\ncross-posted (which tripped up some of my anti-spam rules) or\nsimply missed by gmane.\n\nThere may be more in some personal archives gmane doesn't\nhave...\n\nI've also added NNTP links (including gmane) to the footer in\npublic-inbox.org/git\n\n> message ID is often the most robust (if not very friendly) way to do\n> so, like this:\n> \n> \thttp://public-inbox.org/git/Pine.LNX.4.58.0504150753440.7211@ppc970.osdl.org\n\nSome of the generated links have %40 in them which is the URI\nescape for '@'.  I'll make a change to keep the '@' unescaped to\nlessen confusion.\n\nDue to the use of SQLite as a stable store for NNTP article\nnumbers; public-inbox can also do partial matching (up to 100\nresults, currently) to help correct legitimate mistakes; but I\nwouldn't rely on it too much:\n\n\tpublic-inbox.org/git/Pine.LNX.4.58.0504150753440\n"},{"id":"298949","messageId":"20160813081012.p46i4jcvkkfqch7m@sigill.intra.peff.net","threadId":"43798","inReplyTo":"20160812224255.GA16250@dcvr","subject":"Re: A note from the maintainer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-13T08:10:12Z","receivedAt":"2016-08-13T08:10:30Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Aug 12, 2016 at 10:42:55PM +0000, Eric Wong wrote:\n\n> Junio C Hamano <gitster@pobox.com> wrote:\n> > For those who prefer to read it over NNTP:\n> > \n> > \tnntp://news.gmane.org/gmane.comp.version-control.git\n> > \n> > is still available.  An alternative\n> > \n> >         nntp://news.public-inbox.org/inbox.comp.version-control.git\n> > \n> > will become usable once it catches up with old messages.\n> \n> Mostly caught up, I injected 33 more today which were\n> cross-posted (which tripped up some of my anti-spam rules) or\n> simply missed by gmane.\n> \n> There may be more in some personal archives gmane doesn't\n> have...\n\nIs there an easy way to get _just_ the list of message-ids you are\nstoring (I know I can download the whole archive, but it's big)?\n\nThen I can cross-reference with my archive. I doubt I'll have anything\nsignificant that you don't. My archive of the early days was pulled from\ngmane, though I have been collecting steadily via mailing list delivery\nsince 2007 or so.\n\n-Peff\n"},{"id":"298955","messageId":"20160813090432.GA25565@starla","threadId":"43798","inReplyTo":"20160813081012.p46i4jcvkkfqch7m@sigill.intra.peff.net","subject":"Re: A note from the maintainer","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-13T09:04:32Z","receivedAt":"2016-08-13T09:04:37Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jeff King <peff@peff.net> wrote:\n> On Fri, Aug 12, 2016 at 10:42:55PM +0000, Eric Wong wrote:\n> > Junio C Hamano <gitster@pobox.com> wrote:\n> > > is still available.  An alternative\n> > > \n> > >         nntp://news.public-inbox.org/inbox.comp.version-control.git\n> > > \n> > > will become usable once it catches up with old messages.\n> > \n> > Mostly caught up, I injected 33 more today which were\n> > cross-posted (which tripped up some of my anti-spam rules) or\n> > simply missed by gmane.\n> > \n> > There may be more in some personal archives gmane doesn't\n> > have...\n> \n> Is there an easy way to get _just_ the list of message-ids you are\n> storing (I know I can download the whole archive, but it's big)?\n\nXHDR (or HDR) over NNTP should do it (that's how I checked\nagainst gmane):\n--------8<-----\nuse Net::NNTP;\nmy $nntp = Net::NNTP->new($ENV{NNTPSERVER} || 'news.public-inbox.org');\nmy ($num, $first, $last) = $nntp->group('inbox.comp.version-control.git');\nmy $batch = 10000;\nmy $i;\nfor ($i = $first; $i < $last; $i += $batch) {\n\tmy $j = $i + $batch - 1;\n\t$j = $last if $j > $last;\n\tmy $num2mid = $nntp->xhdr('Message-ID', \"$i-$j\");\n\tfor my $n ($i..$j) {\n\t\tdefined(my $mid = $num2mid->{$n}) or next;\n\t\tprint \"$mid\\n\";\n\t}\n}\n\n# and I forgot to optimize XHDR/HDR further in public-inbox-nntpd.\n# Oh well, it seems to work, at least.\n\n> Then I can cross-reference with my archive. I doubt I'll have anything\n> significant that you don't. My archive of the early days was pulled from\n> gmane, though I have been collecting steadily via mailing list delivery\n> since 2007 or so.\n\nWhat's odd is there's some messages with two Message-ID fields\nfrom gmane from the old days, too.  I'll dig a bit another time.\n"},{"id":"298963","messageId":"20160813111449.vkoo3fmlfd65loh5@sigill.intra.peff.net","threadId":"43798","inReplyTo":"20160813090432.GA25565@starla","subject":"Re: A note from the maintainer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-13T11:14:49Z","receivedAt":"2016-08-13T11:14:56Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Aug 13, 2016 at 09:04:32AM +0000, Eric Wong wrote:\n\n> > Is there an easy way to get _just_ the list of message-ids you are\n> > storing (I know I can download the whole archive, but it's big)?\n> \n> XHDR (or HDR) over NNTP should do it (that's how I checked\n> against gmane):\n> --------8<-----\n> use Net::NNTP;\n> my $nntp = Net::NNTP->new($ENV{NNTPSERVER} || 'news.public-inbox.org');\n> my ($num, $first, $last) = $nntp->group('inbox.comp.version-control.git');\n> my $batch = 10000;\n> my $i;\n> for ($i = $first; $i < $last; $i += $batch) {\n> \tmy $j = $i + $batch - 1;\n> \t$j = $last if $j > $last;\n> \tmy $num2mid = $nntp->xhdr('Message-ID', \"$i-$j\");\n> \tfor my $n ($i..$j) {\n> \t\tdefined(my $mid = $num2mid->{$n}) or next;\n> \t\tprint \"$mid\\n\";\n> \t}\n> }\n\nThanks, that's perfect.\n\nI collected the message-ids from my archive. Interestingly, I had a\ndozen or so that did not have message-ids at all. I think most of them\nare from patches that put the \"From \" line in the body, like this one:\n\n  http://public-inbox.org/git/20070311033833.GB10781@spearce.org/\n\nand then they got corrupted on a round-trip through one of the bad mbox\nformats (probably downloading from gmane, I'd guess; the export there\nuses mbox, and I use maildir myself, so it probably got split badly\nyears ago). Anyway, public-inbox seems to get this case right, which is\ngood.\n\nI had several hundred message ids that you didn't. About half of them\nwere spam or other junk. I weeded them out manually (mostly by picking\nthrough the subjects, so possibly there's some error). The end result is\n279 messages that I think are legitimate that you don't have.\n\nI'll send them to you off-list, as the mbox is about 300K, which the\nlist will reject.\n\n-Peff\n"},{"id":"299256","messageId":"20160814012706.GA18784@starla","threadId":"43798","inReplyTo":"20160813111449.vkoo3fmlfd65loh5@sigill.intra.peff.net","subject":"Re: A note from the maintainer","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-14T01:27:06Z","receivedAt":"2016-08-14T08:37:02Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Jeff King <peff@peff.net> wrote:\n> I collected the message-ids from my archive. Interestingly, I had a\n> dozen or so that did not have message-ids at all. I think most of them\n> are from patches that put the \"From \" line in the body, like this one:\n> \n>   http://public-inbox.org/git/20070311033833.GB10781@spearce.org/\n> \n> and then they got corrupted on a round-trip through one of the bad mbox\n> formats (probably downloading from gmane, I'd guess; the export there\n> uses mbox, and I use maildir myself, so it probably got split badly\n> years ago). Anyway, public-inbox seems to get this case right, which is\n> good.\n\nYes, I was somewhat careful to check for proper mboxes from gmane;\nI just missed entire ranges :x\n\nWhat's also interesting about the thread you highlighed is the\nextra '<>' when you started that thread; and I have a bug where\nI strip off an extra '>' which needs to be fixed...\n\nI wonder if I should make \"editorial\" changes to fixup user bugs,\nbut then there's also bunch of messages which are replies to <y>\nbecause git-send-email had usability problems back in the day...\n\n> I had several hundred message ids that you didn't. About half of them\n> were spam or other junk. I weeded them out manually (mostly by picking\n> through the subjects, so possibly there's some error). The end result is\n> 279 messages that I think are legitimate that you don't have.\n> \n> I'll send them to you off-list, as the mbox is about 300K, which the\n> list will reject.\n\nThanks, should all be imported.\n\nThe one which started the thread belonging to\n<loom.20100716T103549-783@post.gmane.org> was really iffy,\nbut I kept it; as well as an \"unsubscribe\" one; I guess those\npeople are shamed for life :)\n\n\n  git cat-file blob HEAD:b7/5bb577d76487bc9aebf0656d4e03eff22049f4\n\nis totally legit, but doesn't seem to show up properly,\nso there's another bug I need to fix.  For the moment, the\nfollowing also works:\n\n\tpublic-inbox.org/git/b75bb577d76487bc9aebf0656d4e03eff22049f4/\n(but I guess it was reposted as <26299.4828321554$1213013668@news.gmane.org>\n"},{"id":"299262","messageId":"20160814021234.GA1017@starla","threadId":"43798","inReplyTo":"20160814012706.GA18784@starla","subject":"Re: A note from the maintainer","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-14T02:12:34Z","receivedAt":"2016-08-14T09:21:23Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Eric Wong <e@80x24.org> wrote:\n> Thanks, should all be imported.\n\nOops, missed one which was missing X-Mailing-List (causing\nit to not get imported) and had \"X-No-Archive: yes\" set;\nwhich meant I couldn't get it from gmane this year.\n\nHmm... XNAY defeats the point of public-inbox (and probably the\npoint of public-to-all mailing lists); so I don't think it's\nworth honoring.\n"},{"id":"299273","messageId":"20160814121920.r7uxpepcz6spjcy4@sigill.intra.peff.net","threadId":"43798","inReplyTo":"20160814012706.GA18784@starla","subject":"Re: A note from the maintainer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-14T12:19:20Z","receivedAt":"2016-08-14T12:19:33Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 14, 2016 at 01:27:06AM +0000, Eric Wong wrote:\n\n> What's also interesting about the thread you highlighed is the\n> extra '<>' when you started that thread; and I have a bug where\n> I strip off an extra '>' which needs to be fixed...\n\nOh, that's interesting. It's not in the message that started the thread;\nthe bug is in the in-reply-to headers of the patches themselves. I don't\nremember what I was using to send patches back then. It might have been\nsend-email, and I suspect I did:\n\n  git send-email --in-reply-to='<whatever>'\n\nafter cutting-and-pasting '<whatever>' from the cover letter.\n\n> I wonder if I should make \"editorial\" changes to fixup user bugs,\n> but then there's also bunch of messages which are replies to <y>\n> because git-send-email had usability problems back in the day...\n\nI wouldn't go too far in editorial changes. I made a few when skimming\nthe messages I just sent for spam, and dropped some empty messages, or\n\"unsubscribe me\" ones. But it's not worth the human effort to go back\nand scrub list archives from 10 years ago.\n\nFixing up an extra \"<>\" is easily done once in your parsing scripts,\nthough, and I'd be surprised if I'm the only one to have made that\nmistake.\n\n> The one which started the thread belonging to\n> <loom.20100716T103549-783@post.gmane.org> was really iffy,\n\nI think I exercised editorial control over similar \"your software is now\nlisted in our archive!\" messages in what I sent. But yeah, there's going\nto be some spam and some cruft in the archive. It's just a fact of life.\nThe solution is good searching and organizing tools to find the signal\nyou're looking for, not to make sure the noise hits zero.\n\n>   git cat-file blob HEAD:b7/5bb577d76487bc9aebf0656d4e03eff22049f4\n> \n> is totally legit, but doesn't seem to show up properly,\n\nHeh, yeah, I saw that one (and I think it broke some of my initial\nscripting, which foolishly assumed nobody had message-ids with spaces in\nthem).\n\n-Peff\n"},{"id":"299274","messageId":"20160814122351.oblpop2qu4wjrhdx@sigill.intra.peff.net","threadId":"43798","inReplyTo":"20160814021234.GA1017@starla","subject":"Re: A note from the maintainer","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2016-08-14T12:23:51Z","receivedAt":"2016-08-14T12:23:57Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Aug 14, 2016 at 02:12:34AM +0000, Eric Wong wrote:\n\n> Eric Wong <e@80x24.org> wrote:\n> > Thanks, should all be imported.\n> \n> Oops, missed one which was missing X-Mailing-List (causing\n> it to not get imported) and had \"X-No-Archive: yes\" set;\n> which meant I couldn't get it from gmane this year.\n> \n> Hmm... XNAY defeats the point of public-inbox (and probably the\n> point of public-to-all mailing lists); so I don't think it's\n> worth honoring.\n\nI didn't even think to look for that header. It looks like it's\nbasically all one guy. I would argue that it should not be honored for\nthe git dev list, if only because those emails are a record of the\nprovenance of patches. The Signed-off-by is a certification that the\npatch is OK to submit, but it's presumably worth more with an audit\ntrail including the email headers.\n\n(Also, I have always found it a little silly to post publicly with a\n\"please don't anybody record this!\" header).\n\n-Peff\n"},{"id":"299278","messageId":"A8D4E6C8B72B472BB7B580804F9FAB85@PhilipOakley","threadId":"43798","inReplyTo":"20160814012706.GA18784@starla","subject":"Re: A note from the maintainer","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2016-08-14T15:00:54Z","receivedAt":"2016-08-14T15:01:01Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Eric Wong\" <e@80x24.org>\n>\n> Yes, I was somewhat careful to check for proper mboxes from gmane;\n> I just missed entire ranges :x\n>\n\nThere were a number of messages that were listed by gmane as being in the \nvarious Git for Windows lists such as msysgit, especially when the messages \nwent to both lists (as the issue had common cause) that failed to get onto \nthe regualr gmane list.\n\nAre these something that has been included?\n\nPhilip\n\nA quick search on a possible message gave \nhttps://public-inbox.org/git/55BF6808.1000500@web.de/ which has no parent, \nbut that parent actually only went to the msysgit list, so no real surprise \nthere, but I do remember some other cases that were on list - I just can't \nfind them at the moment :-(.\n\n\n\n\n"},{"id":"299300","messageId":"20160814225219.GA12202@dcvr","threadId":"43798","inReplyTo":"A8D4E6C8B72B472BB7B580804F9FAB85@PhilipOakley","subject":"Re: A note from the maintainer","fromName":"Eric Wong","fromEmail":"e@80x24.org","sentAt":"2016-08-14T22:52:19Z","receivedAt":"2016-08-14T22:52:23Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"Philip Oakley <philipoakley@iee.org> wrote:\n> From: \"Eric Wong\" <e@80x24.org>\n> >\n> >Yes, I was somewhat careful to check for proper mboxes from gmane;\n> >I just missed entire ranges :x\n> >\n> \n> There were a number of messages that were listed by gmane as being in the\n> various Git for Windows lists such as msysgit, especially when the messages\n> went to both lists (as the issue had common cause) that failed to get onto\n> the regualr gmane list.\n> \n> Are these something that has been included?\n\nIf they were on both lists, yes, gmane seems to miss some of\nthose messages, unfortunately.\n\n> Philip\n> \n> A quick search on a possible message gave\n> https://public-inbox.org/git/55BF6808.1000500@web.de/ which has no parent,\n> but that parent actually only went to the msysgit list, so no real surprise\n> there, but I do remember some other cases that were on list - I just can't\n> find them at the moment :-(.\n\nIf a message was only posted exclusively on other lists, it\nshould stay there and it's archives.  public-inbox provides a\nway to lookup external messages by Message-ID for this reason.\n\nIs there a way to lookup messages by Message-ID from the msysgit\narchives?  I could add it to the existing list of alternate\nMessage-ID lookup services:\n\n  https://public-inbox.org/meta/20160814054731.26194-1-e@80x24.org/\n\nGoogleGroups doesn't seem usable without JavaScript at all,\nunfortunately :<\n\nI don't think the msysgit archives would be too large and I\nwouldn't mind hosting them myself.  But, users on GoogleGroups\nmay not be used to our conventions and not appreciate having\ntheir unobfuscated addresses exposed or reply-to-all...\n\nI will probably add an option to support centralized lists to\npublic-inbox sometime, though.  I don't like centralization,\nbut completely inaccessible archives are worse.\n"}]}