{"thread":{"id":"50282","subject":"Contributor Summit Topics and Logistics","startedAt":"2019-01-22T07:50:31Z","lastAt":"2019-04-23T03:45:35Z","messageCount":19,"participants":["Jeff King","Christian Couder","Stefan Beller","Derrick Stolee","Elijah Newren","Ævar Arnfjörð Bjarmason","Philip Oakley","Jeff Hostetler","SZEDER Gábor","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"367289","messageId":"20190122075027.GA29441@sigill.intra.peff.net","threadId":"50282","inReplyTo":null,"subject":"Contributor Summit Topics and Logistics","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-22T07:50:27Z","receivedAt":"2019-01-22T07:50:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The Git Merge Contributor Summit is a little over a week away. If you're\ninterested in coming but haven't signed up, please do! We have a few\nspaces available still. Details are in the previous announcement:\n\n http://public-inbox.org/git/20181206094805.GA1398@sigill.intra.peff.net/\n\nThere's no set agenda; we'll decide what to discuss that day. But if\nanybody would like to mention topics they are interested in (whether you\nwant to present on them, or just have an open discussion), please do so\nhere. A little advance notice can help people prepare more for the\ndiscussions.\n\nEven if you're not coming, please feel free to suggest topics (but bonus\npoints if you convince somebody who _is_ coming to lead the session).\n\nIf you're not coming, you can probably stop reading this message now.\nThe rest is all logistics.\n\nWe have the room available from 9am-5pm. Breakfast will be served from\n9am-10am in the main area (i.e., mingling with workshop attendees and\nother such ruffians). So I'd suggest to show up around 9am to get\nregistered and mingle, and then we can start the Very Serious Business\nat 10am.\n\nLunch will be provided at noon, and some snacks in the afternoon.\nThere's no organized dinner. However, there will be a social/drinks\nevent for the broader conference at 7pm; I'll provide more details that\nday.\n\nFor people who want to try to join remotely, I don't think we're going\nto have a particularly fancy AV setup. But there should at least be a\nbig screen (which we typically do not really use for presenting), and I\nhope we can provide some connectivity. I'll be visiting the venue the\nday before (Jan 30th) in the late afternoon (Brussels time) and I'll try\nto do a test run. If anybody wants to volunteer to be the guinea pig on\nthe other end of the line, I'd welcome it.\n\nThe physical setup this year will actually be 4 round tables, instead of\none giant table. I'm hoping this will facilitate breaking off into\nsub-groups and having more intimate conversations, and maybe avoid the\n\"it's hard to hear people at the other end of the table\" issues. Or\nmaybe it will just make it worse as we shout to each other from all four\ntables. I can't wait to see!\n\nIf you have any other questions or ideas, please share them here (or\nemail me off-list if appropriate). I look forward to seeing people\nthere!\n\n-Peff\n"},{"id":"367290","messageId":"20190122082647.GA31608@sigill.intra.peff.net","threadId":"50282","inReplyTo":"20190122075027.GA29441@sigill.intra.peff.net","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-22T08:26:48Z","receivedAt":"2019-01-22T08:26:51Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 22, 2019 at 02:50:27AM -0500, Jeff King wrote:\n\n> There's no set agenda; we'll decide what to discuss that day. But if\n> anybody would like to mention topics they are interested in (whether you\n> want to present on them, or just have an open discussion), please do so\n> here. A little advance notice can help people prepare more for the\n> discussions.\n\nOne topic worth discussing (here or there): the GSoC org deadline is Feb\n6th. Last year's org admins were Christian and Stefan (cc'd). Are you\nboth interested and able to continue?\n\n-Peff\n"},{"id":"367292","messageId":"CAP8UFD3Kt3dreMnfAdLiP2yc47kBLoVYCk-2yDw67OkujVY=Ew@mail.gmail.com","threadId":"50282","inReplyTo":"20190122082647.GA31608@sigill.intra.peff.net","subject":"GSoC 2019 (was: Contributor Summit Topics and Logistics)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-01-22T09:17:59Z","receivedAt":"2019-01-22T09:18:13Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Tue, Jan 22, 2019 at 9:26 AM Jeff King wrote:\n>\n> On Tue, Jan 22, 2019 at 02:50:27AM -0500, Jeff King wrote:\n>\n> > There's no set agenda; we'll decide what to discuss that day. But if\n> > anybody would like to mention topics they are interested in (whether you\n> > want to present on them, or just have an open discussion), please do so\n> > here. A little advance notice can help people prepare more for the\n> > discussions.\n>\n> One topic worth discussing (here or there): the GSoC org deadline is Feb\n> 6th. Last year's org admins were Christian and Stefan (cc'd). Are you\n> both interested and able to continue?\n\nYeah, I am interested and able to both be org admin and mentor. Thanks\nfor talking about this.\n\nI think that as usual we will have to prepare a few pages about:\n\n- our application (like https://git.github.io/SoC-2018-Org-Application/)\n- microprojects idea for interested students (like\nhttps://git.github.io/SoC-2018-Microprojects/)\n- project ideas (like https://git.github.io/SoC-2018-Ideas/)\n\nSuggestions for microprojects or project ideas are welcome! Volunteers\nfor mentoring or org admin are welcome too!\n"},{"id":"367333","messageId":"CAGZ79kZs4azxZiVDi4hOOfr=+z12_DXhPYbM==h3EWAFxqtx4g@mail.gmail.com","threadId":"50282","inReplyTo":"20190122082647.GA31608@sigill.intra.peff.net","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2019-01-22T18:21:56Z","receivedAt":"2019-01-22T18:22:11Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Tue, Jan 22, 2019 at 12:26 AM Jeff King wrote:\n>\n> On Tue, Jan 22, 2019 at 02:50:27AM -0500, Jeff King wrote:\n>\n> > There's no set agenda; we'll decide what to discuss that day. But if\n> > anybody would like to mention topics they are interested in (whether you\n> > want to present on them, or just have an open discussion), please do so\n> > here. A little advance notice can help people prepare more for the\n> > discussions.\n>\n> One topic worth discussing (here or there): the GSoC org deadline is Feb\n> 6th. Last year's org admins were Christian and Stefan (cc'd). Are you\n> both interested and able to continue?\n\nI am treading lightly this year; if no one else is around I could be an\nadmin (definitely not a mentor), but I'd prefer not to.\n"},{"id":"367334","messageId":"4dbbdd75-e71b-d6e4-123d-dddc7a9d8a67@gmail.com","threadId":"50282","inReplyTo":"20190122075027.GA29441@sigill.intra.peff.net","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-01-22T18:23:38Z","receivedAt":"2019-01-22T18:23:44Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"On 1/22/2019 2:50 AM, Jeff King wrote:\n> For people who want to try to join remotely, I don't think we're going\n> to have a particularly fancy AV setup. But there should at least be a\n> big screen (which we typically do not really use for presenting), and I\n> hope we can provide some connectivity. I'll be visiting the venue the\n> day before (Jan 30th) in the late afternoon (Brussels time) and I'll try\n> to do a test run. If anybody wants to volunteer to be the guinea pig on\n> the other end of the line, I'd welcome it.\n\nI would like to join remotely, so I volunteer to do a test run. I'll \nneed to wake up early, so let's set an exact time privately.\n\n\nTopics I would like to hear about:\n\n- commit-graph status report (I can lead, if I'm able to join)\n\n- multi-pack-index status report (same)\n\n- reftable\n\n- partial clone\n\n- test coverage report, usefulness or improvements\n\n\nThanks,\n\n-Stolee\n\n"},{"id":"367354","messageId":"CABPp-BE9vTw8vsn=c=wNoTyU6Sg_n4YGEXnGGcFDHRt9Uo5mOg@mail.gmail.com","threadId":"50282","inReplyTo":"20190122075027.GA29441@sigill.intra.peff.net","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-01-22T20:30:17Z","receivedAt":"2019-01-22T20:30:32Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Mon, Jan 21, 2019 at 11:52 PM Jeff King wrote:\n>\n> The Git Merge Contributor Summit is a little over a week away. If you're\n> interested in coming but haven't signed up, please do! We have a few\n> spaces available still. Details are in the previous announcement:\n>\n> http://public-inbox.org/git/20181206094805.GA1398@sigill.intra.peff.net/\n>\n> There's no set agenda; we'll decide what to discuss that day. But if\n> anybody would like to mention topics they are interested in (whether you\n> want to present on them, or just have an open discussion), please do so\n> here. A little advance notice can help people prepare more for the\n> discussions.\n\n* git repo-filter[1] or whatever it ends up being named (filter-branch\nalternative): is it wanted in git.git?\n\n* merge-recursive rewrite -- steps others want to see me take in that process?\n\n* Making --merge option of rebase be the default[2]: what steps need\nto be taken?\n\n* I'll second Derrick's request for partial clone, perhaps also\nbriefly discuss related capabilities like sparse checkouts and partial\nindexes too?\n\n\n\n[1] https://public-inbox.org/git/20181111062312.16342-1-newren@gmail.com/\n[2] https://public-inbox.org/git/xmqqh8jeh1id.fsf@gitster-ct.c.googlers.com/\n"},{"id":"367358","messageId":"20190122205332.GA11904@sigill.intra.peff.net","threadId":"50282","inReplyTo":"CAGZ79kZs4azxZiVDi4hOOfr=+z12_DXhPYbM==h3EWAFxqtx4g@mail.gmail.com","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-22T20:53:32Z","receivedAt":"2019-01-22T20:53:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 22, 2019 at 10:21:56AM -0800, Stefan Beller wrote:\n\n> > > There's no set agenda; we'll decide what to discuss that day. But if\n> > > anybody would like to mention topics they are interested in (whether you\n> > > want to present on them, or just have an open discussion), please do so\n> > > here. A little advance notice can help people prepare more for the\n> > > discussions.\n> >\n> > One topic worth discussing (here or there): the GSoC org deadline is Feb\n> > 6th. Last year's org admins were Christian and Stefan (cc'd). Are you\n> > both interested and able to continue?\n> \n> I am treading lightly this year; if no one else is around I could be an\n> admin (definitely not a mentor), but I'd prefer not to.\n\nI can be an org admin, as well. If Christian is willing, then I think\nyou don't need to do it this year.\n\n-Peff\n"},{"id":"367530","messageId":"87bm464elm.fsf@evledraar.gmail.com","threadId":"50282","inReplyTo":"4dbbdd75-e71b-d6e4-123d-dddc7a9d8a67@gmail.com","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-01-24T08:57:57Z","receivedAt":"2019-01-24T08:58:03Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Jan 22 2019, Derrick Stolee wrote:\n\n> On 1/22/2019 2:50 AM, Jeff King wrote:\n>> For people who want to try to join remotely, I don't think we're going\n>> to have a particularly fancy AV setup. But there should at least be a\n>> big screen (which we typically do not really use for presenting), and I\n>> hope we can provide some connectivity. I'll be visiting the venue the\n>> day before (Jan 30th) in the late afternoon (Brussels time) and I'll try\n>> to do a test run. If anybody wants to volunteer to be the guinea pig on\n>> the other end of the line, I'd welcome it.\n>\n> I would like to join remotely, so I volunteer to do a test run. I'll\n> need to wake up early, so let's set an exact time privately.\n>\n>\n> Topics I would like to hear about:\n>\n> - commit-graph status report (I can lead, if I'm able to join)\n\nWhile we're at it it would be useful to discuss what attendes think\nabout making core.commitGraph=true && gc.writeCommitGraph=true the\ndefault.\n"},{"id":"368028","messageId":"6d0dc2a2-120c-0d42-1910-14ffed7adaf1@gmail.com","threadId":"50282","inReplyTo":"87bm464elm.fsf@evledraar.gmail.com","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Derrick Stolee","fromEmail":"stolee@gmail.com","sentAt":"2019-01-29T18:22:37Z","receivedAt":"2019-01-29T18:22:41Z","isPatch":false,"sender":{"key":"stolee@gmail.com","avatar":"https://avatars.githubusercontent.com/u/570044?v=4"},"body":"I was hoping to attend the contributors' summit remotely, but now my leave is\nstarting before then. This email contains a summary of what I would have\nadded to the discussion.\n\nThanks,\n-Stolee\n\n\nCommit-Graph Status Report\n==========================\n\nI'm really happy with the progress in this area, especially with the number of\nother contributors working on the feature! Thanks Ævar, Jonathan, Josh, Stefan,\nand Szeder in particular.\n\nHere are some directions to take the feature in the near future:\n\nFile Format v2\n--------------\n\nThe new format version [1] specifically fixes some shortcomings in v1:\n\n* Uses the 4-byte format id for the hash algorithm.\n* Creates a separate version byte for the reachability index.\n* Enforces that the unused byte is zero until we use it for incremental writes.\n\nHopefully, this is the last time we need to update the file header.\n\n[1] https://public-inbox.org/git/pull.112.git.gitgitgadget@gmail.com/\n [PATCH 0/6] Create commit-graph file format v2\n\nReachability Index\n------------------\n\nAs discussed on-list [2], we want to replace generation numbers with a different\n(negative-cut) reachability index. I used the term \"corrected commit date\". The\ndefinition is:\n\n* If a commit has no parents, then its corrected commit date is its commit date.\n\n* If a commit has parents, then its corrected commit date is the maximum of:\n - its commit date\n - one more than the maximum corrected commit date of its parents\n\nThe benefits of this definition were discussed already, but to summarize:\n\n* This definition will work _at least as well_ as the commit date heuristic,\n with the added bonus of being absolutely sure our results are right. We can\n update algorithms like paint_down_to_common() to use this reachability index\n without performance problems in some cases.\n\n* If someone creates a terrible commit with a date that is far in the future,\n this definition is no worse than existing generation numbers (because we\n enforce that the corrected commit date is strictly larger than the parents'\n corrected commit date).\n\nTo implement this index, we can re-use the 30 bits per commit in the\ncommit-graph file that are used for generation numbers, but use them instead\nfor the difference between the corrected commit date and the actual commit\ndate. File format v2 gives us a version value that can be incremented to signal\nthe change in meaning.\n\nSome work is required to adjust the existing generation-number-aware algorithms\nto care about an \"arbitrary\" reachability index. It could be as easy as a\nhelper function that returns a function pointer to the proper compare function.\n\nIf someone wants to move forward on this topic while I'm gone, please\nvolunteer. Otherwise, this will be among my first items to work on when I\nreturn from leave.\n\n[2] https://public-inbox.org/git/6367e30a-1b3a-4fe9-611b-d931f51effef@gmail.com/\n [RFC] Generation Number v2\n\nIncremental Writes\n------------------\n\nSimilar to the split index, an incremental commit-graph file can be implemented\nto reduce the write time when adding commits to an existing (large)\ncommit-graph. In this case, the .git/objects/info/commit-graph file would\nbe small, and have a pointer to a base file, say \"cgraph-.cgraph\", that\ncontains the majority of the commits.\n\nThe important thing to keep in mind here is that we use integers to refer to\na commit's parents. This integer would need to refer to the order of commits\nwhen you concatenate the orderd lists from each file. When doing this, we\ncan point into the base file as well as the tip file. Since the base\ncommit-graph file would be closed under reachability, it only needs to care\nabout commits in its file.\n\nIt is also possible to have multiple base files, and we can use the unused\nbyte in the commit-graph file format v2 to store the number of base files.\nWe can then store a list of file names in a new chunk, presenting the ordered\nlist of base files. We still want to keep this list short, but there may be\nbenefits to a variable number. I expect the first version would limit the\nconstruction to one base file for simplicity's sake.\n\nWhen this is implemented, we can use it to write the commit-graph at fetch\ntime. A config setting, say 'fetch.writeCommitGraph', could enable this write.\nSince most writes would add a small number of commits compared to the large\nbase file, this would be a more reasonable cost to add to a fetch. Since we\nverify the pack upon download, the commits it contained will already be in\nthe memory cache and we won't need to re-parse those commits.\n\nVolunteers welcome.\n\nBloom Filters\n-------------\n\nUsing bloom filters to speed up file history has been discussed and prototyped\non-list (see [12] and the thread before it). Thanks for lots of contributions\nin this area! A lot of people have shown an interest in this feature, and it\nis particularly helpful with server-side queries.\n\nAny implementation here should check that it is helping 'git blame' as much as\nit can [13]. It's entirely possible that the performance problem mentioned\nthere is more about the size of the file and not finding the commits that\nchanged the file, but it's worth digging in here.\n\nA few people have mentioned that they are interested in pursuing this\nimplementation, so it would be good to declare intentions during the summit.\n\n[12] https://public-inbox.org/git/61559c5b-546e-d61b-d2e1-68de692f5972@gmail.com/\n\n[13] https://public-inbox.org/git/CABXAcUzoNJ6s3=2xZfWYQUZ_AUefwP=5UVUgMnafKHHtufzbSA@mail.gmail.com/\n\nEnabled by Default?\n-------------------\n\nI proposed turning on the feature by default [3], but that had some\nresistance [4] and I never followed up to that remark. (It involved the\nhope that we could consolidate commit walks during a gc/repack. I'm unsure\nthis is a goal worth pursuing.) Since there has been more interest recently [5]\nI think it would be good to discuss what concerns we may have in turning this\non by default. Specifically, make 'core.commitGraph' and 'gc.writeCommitGraph'\ndefault to 'true'. Users could still opt-out.\n\n[3] https://public-inbox.org/git/pull.50.git.gitgitgadget@gmail.com/\n[4] https://public-inbox.org/git/xmqqlg6vvrur.fsf@gitster-ct.c.googlers.com/\n[5] https://public-inbox.org/git/87bm464elm.fsf@evledraar.gmail.com/\n\n\nMulti-Pack-Index Status Report\n==============================\n\nThe multi-pack-index feature shipped with Git 2.20! We've been using this\nfeature (or, a similar implementation as it changed a lot with review) in\nVFS for Git for a year now. It's been critical to solving the many-packs\nproblem we have with our prefetch packs model. Our next version ships with\nGit 2.20 and the upstream implementation.\n\nWe are now able to start tackling our space problem with these many packs.\nOur solution includes the 'expire' and 'repack' subcommands [6]. We will run\nthese in the background [7] to slowly reduce the space we are using. Since\nGit references the multi-pack-index, we are able to delete packs that have\nno referenced objects from the multi-pack-index without interrupting user\ncommands (I don't think the same holds for 'git repack'). This \"highly\navailable\" model makes me think that this could be useful to other scenarios.\n\nWe are looking for interest from other users or groups in this feature. We\nwant this feature to be adopted, and that means the future of the feature \nshould depend on more scenarios than our specific case.\n\nHere are some ideas to make this more useful for others:\n\n1. Incremental writes. See the commit-graph section for details. This would\n allow writing the multi-pack-index on fetch, helping users who have set\n gc.auto=0 keep performance high even though they have packs piling up.\n\n2. Stable object order and bitmaps. This is discussed in the design\n document [8]. This is more useful for server environments.\n\n[6] https://public-inbox.org/git/pull.92.git.gitgitgadget@gmail.com/\n [PATCH 0/5] Create 'expire' and 'repack' verbs for git-multi-pack-index\n\n[7] https://github.com/Microsoft/VFSForGit/blob/9cad154293456a41bef593a75e1ad2cb840c8524/GVFS/GVFS.Common/Maintenance/PackfileMaintenanceStep.cs#L141-L158\n The use of 'expire' and 'repack' in VFS for Git\n\n[8] https://github.com/git/git/blob/master/Documentation/technical/multi-pack-index.txt#L77-L84\n multi-pack-index and stable object order\n\n\nTest Coverage Report\n====================\n\nMy intentions creating the test coverage report were to avoid bugs by double-\nchecking that we are testing all logic that was both (1) non-trivial, and\n(2) new. The report does tend to be noisy with a lot of trivial blocks (error\ncases) or code that was not covered before but was updated with a mechanical\nrefactoring. I'm hoping to attack these issues by using a new approach when\ngenerating the reports.\n\nI've created a GitHub repo [9] that contains new logic for generating the test\ncoverage report. In particular, it will now generate a text report that will\nbe sent to the list, but also an HTML report that will be posted online (see\n[10] for an example).\n\nIn addition, the repo has an 'ignored' directory. This directory will be filled\nwith files that mirror their corresponding files in the Git repo, but contain\nline numbers and contents for lines that have been deemed \"unimportant\". For\ninstance, I didn't want to just ignore all lines that say simply \"return;\" but\nwe can check that line 302 of builtin/checkout.c says \"return;\" and ignore that\nline in the report [11].\n\nI'll try to review the test report and add ignored lines before generating the\nnext report. I'll also accept PRs that add ignored lines (with justification).\n\nI think this will help the usefulness significantly, especially as topics merge\ndown into 'next' and 'master'. If we track the ignored lines throughout a cycle,\nthen the report for 'maint' versus 'master' near release time may actually be\nreasonable to read.\n\nAny other feedback on the reports is greatly appreciated!\n\n[9] https://github.com/derrickstolee/git-test-coverage\n\n[10] https://derrickstolee.github.io/git-test-coverage/reports/2019-01-29.htm\n\n[11] https://github.com/derrickstolee/git-test-coverage/blob/master/ignored/builtin/checkout.c\n"},{"id":"368191","messageId":"87va253lun.fsf@evledraar.gmail.com","threadId":"50282","inReplyTo":"20190122075027.GA29441@sigill.intra.peff.net","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2019-01-30T20:57:04Z","receivedAt":"2019-01-30T20:57:11Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"\nOn Tue, Jan 22 2019, Jeff King wrote:\n\n> There's no set agenda; we'll decide what to discuss that day. But if\n> anybody would like to mention topics they are interested in (whether you\n> want to present on them, or just have an open discussion), please do so\n> here. A little advance notice can help people prepare more for the\n> discussions.\n\nThis is definitely a \"little\" advance seeing as it's tomorrow morning.\n\n> Even if you're not coming, please feel free to suggest topics (but bonus\n> points if you convince somebody who _is_ coming to lead the session).\n\nThings I'd be interested in hearing / talking about about that haven't\nyet been mentioned.\n\nThese are in descending order of how interesting I think these will be\nto a general audience, to the point where maybe only I care about the\nbottom of this list...\n\n* \"Big repos\". We had discussions about this in years past. It's a very\n spawly and vague topic. Do we mean big history, big blobs, big (in\n size/depth/width) checkouts etc?\n\n But regardless, many of us deal with this in one way or another, and\n it would be good to have a top-level overview of how the various\n solutions to this that are being integrated into git.git are doing /\n what people see on the horizon for scalabiltiy.\n\n* \"Structured remote logging\". We had an RFC spec for turning our trace\n format into something more structural with a way to send it to a\n remote server. There were both implementation & privacy concernse,\n last time at least a couple of users of git reported having in-house\n patches for this (not ready for upstream). Where are we on this now?\n\n* \"commit graph by default\". I had this on my list, but Derrick Stolee\n sent out a much better summary:\n https://public-inbox.org/git/6d0dc2a2-120c-0d42-1910-14ffed7adaf1@gmail.com/\n\n* I've been using (but haven't yet re-rolled) my \"relative SHA-1\n abbreviation\" series\n (https://public-inbox.org/git/20180608224136.20220-1-avarab@gmail.com/)\n\n I'm interested in seeing if anyone else is interested in this, and\n particularly what the overlap (if any) is between this & midx.\n\n* \"Making strict fsck checks on clone the default\". I worked a bit on\n this in this last year in between a couple of security issues that\n needed fsck checks. Has caveats etc., but would give users some more\n protections.\n\n* \"The CI I set up for git on the GCC Compile Farm\". Can be folded into\n a general \"state of git.git CI\" topic:\n https://gitlab.com/git-vcs/git-ci/pipelines\n\n* If people care about making the TAP mode in our test suite mandatory\n (i.e. require \"prove\" or a tool like it). See\n https://public-inbox.org/git/87zhrj2n2l.fsf@evledraar.gmail.com/\n"},{"id":"368202","messageId":"2015d9ea-0570-b035-dcbb-ee1865381cf1@iee.org","threadId":"50282","inReplyTo":"87va253lun.fsf@evledraar.gmail.com","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":"2019-01-30T22:51:24Z","receivedAt":"2019-01-30T23:04:40Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"On 30/01/2019 20:57, Ævar Arnfjörð Bjarmason wrote:\n> On Tue, Jan 22 2019, Jeff King wrote:\n>\n>> There's no set agenda; we'll decide what to discuss that day. But if\n>> anybody would like to mention topics they are interested in (whether you\n>> want to present on them, or just have an open discussion), please do so\n>> here. A little advance notice can help people prepare more for the\n>> discussions.\n> This is definitely a \"little\" advance seeing as it's tomorrow morning.\n>\n>> Even if you're not coming, please feel free to suggest topics (but bonus\n>> points if you convince somebody who _is_ coming to lead the session).\n> Things I'd be interested in hearing / talking about about that haven't\n> yet been mentioned.\n>\n> These are in descending order of how interesting I think these will be\n> to a general audience, to the point where maybe only I care about the\n> bottom of this list...\n>\n> * \"Big repos\". We had discussions about this in years past. It's a very\n> spawly and vague topic. Do we mean big history, big blobs, big (in\n> size/depth/width) checkouts etc?\n>\n> But regardless, many of us deal with this in one way or another, and\n> it would be good to have a top-level overview of how the various\n> solutions to this that are being integrated into git.git are doing /\n> what people see on the horizon for scalabiltiy.\n\n\nI'd also like a bit of discussion about ensuring that the partial clone \n& filtering aspects of 'big repos' (if partial is needed /used then it's \nbig ...) still retain the full 'distributed' nature and capability of git.\n\n\nAlso in some environments the filtering may want to be applied at the \nserver end (based on it's knowledge of the specific user). Ultimately it \nshould also pull in some of the sub-module aspects as super projects are \njust big repos in disguise.\n\n>\n> * \"Structured remote logging\". We had an RFC spec for turning our trace\n> format into something more structural with a way to send it to a\n> remote server. There were both implementation & privacy concernse,\n> last time at least a couple of users of git reported having in-house\n> patches for this (not ready for upstream). Where are we on this now?\n>\n> * \"commit graph by default\". I had this on my list, but Derrick Stolee\n> sent out a much better summary:\n> https://public-inbox.org/git/6d0dc2a2-120c-0d42-1910-14ffed7adaf1@gmail.com/\n>\n> * I've been using (but haven't yet re-rolled) my \"relative SHA-1\n> abbreviation\" series\n> (https://public-inbox.org/git/20180608224136.20220-1-avarab@gmail.com/)\n>\n> I'm interested in seeing if anyone else is interested in this, and\n> particularly what the overlap (if any) is between this & midx.\n>\n> * \"Making strict fsck checks on clone the default\". I worked a bit on\n> this in this last year in between a couple of security issues that\n> needed fsck checks. Has caveats etc., but would give users some more\n> protections.\n>\n> * \"The CI I set up for git on the GCC Compile Farm\". Can be folded into\n> a general \"state of git.git CI\" topic:\n> https://gitlab.com/git-vcs/git-ci/pipelines\n>\n> * If people care about making the TAP mode in our test suite mandatory\n> (i.e. require \"prove\" or a tool like it). See\n> https://public-inbox.org/git/87zhrj2n2l.fsf@evledraar.gmail.com/\n\n\nI also had some questions regarding tree walk issues for follower and \nfriendly fork repos that have lots of deadheads within their tree, such \nas previous release versions in Git for Windows. It should be easier to \nfilter those deadheads (or at least suggest the best way of creating \nsuch sentinels).\n\n--\n\nPhilip\n\n\n"},{"id":"368203","messageId":"e0173444-c5c4-61d0-5a3d-e37cbfd44bad@jeffhostetler.com","threadId":"50282","inReplyTo":"87va253lun.fsf@evledraar.gmail.com","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Jeff Hostetler","fromEmail":"git@jeffhostetler.com","sentAt":"2019-01-30T22:26:23Z","receivedAt":"2019-01-30T23:05:13Z","isPatch":false,"sender":{"key":"git@jeffhostetler.com","avatar":null},"body":"\n\nOn 1/30/2019 3:57 PM, Ævar Arnfjörð Bjarmason wrote:\n> \n> On Tue, Jan 22 2019, Jeff King wrote:\n> \n...\n> * \"Structured remote logging\". We had an RFC spec for turning our trace\n> format into something more structural with a way to send it to a\n> remote server. There were both implementation & privacy concernse,\n> last time at least a couple of users of git reported having in-house\n> patches for this (not ready for upstream). Where are we on this now?\n\nI won't be attending GitMerge this year, but I can talk about\nthis work here.\n\nMy earlier \"structured logging\" and/or \"telemetry\" proposals\nhave been replaced by my Trace2 patch series now in \"pu\".\n\nThe Trace2 feature is designed to report trace and performance\ndata from within the git process to a local log file, unix\ndomain socket, or Windows named pipe. Functions in the Trace2\nAPI generate structured data and can write either structured\n(JSON) or non-structured formats to disk. (It should not be\nhard to add a binary structured format too, but that is beyond\nthe scope of the current patch series.)\n\nThe JSON stream is suitable for post-processing by a local\nprocess. This can be a daemon listening to the stream or a\ncron job processing the trace data after the fact.\n\nI consider it to be the job of the post-processor (after\naggregating, filtering or whatever) to decide what to do with\nthe data. This lets the the user and/or sysadmin control how\nand when data is collected. The post-processor is free to hook\ninto something like syslog or ETW or write to a custom DB.\n\nPost-processing tools are not included in the patch series.\n\n\nInternally within Microsoft, we have a local Windows Service\nlistening on a named pipe and collecting events from all\ngit processes for our GVFS users in the Windows OS repo.\nIt computes a summary record for each git command, for example\ncombining the argv from the \"start\" event with the elapsed\ntime from the \"exit\" event into a single record. The service\nthen sends the aggregate records to a centralized database.\n\nThis lets us run various database queries to try to understand\npain points that our OS developers are experiencing (and that\nmay not show up on my machine) and help us prioritize future perf\nand scaling work.\n\nBut again, this service is but one possible post-processor\nand is for internal-use-only.\n\nThe Trace2 feature itself does not have any remote capability.\nIt just writes data locally.\n\nJeff\n\n\n"},{"id":"368204","messageId":"20190130230702.GA25423@sigill.intra.peff.net","threadId":"50282","inReplyTo":"20190122075027.GA29441@sigill.intra.peff.net","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-01-30T23:07:03Z","receivedAt":"2019-01-30T23:07:09Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 22, 2019 at 02:50:27AM -0500, Jeff King wrote:\n\n> If you're not coming, you can probably stop reading this message now.\n> The rest is all logistics.\n\nHere are a few additional last-minute logistics:\n\n> For people who want to try to join remotely, I don't think we're going\n> to have a particularly fancy AV setup. But there should at least be a\n> big screen (which we typically do not really use for presenting), and I\n> hope we can provide some connectivity. I'll be visiting the venue the\n> day before (Jan 30th) in the late afternoon (Brussels time) and I'll try\n> to do a test run. If anybody wants to volunteer to be the guinea pig on\n> the other end of the line, I'd welcome it.\n\nThe remote connection will be done via Zoom, using this URL which will\nbecome active shortly before 10:00am (Brussels time):\n\n https://github.zoom.us/j/186903655\n\nYou may need to download an app or other software; solutions are\navailable for most platforms, and the zoom site should guide you.\n\nNote that this is _not_ configured as a one-way webinar. It's a real\nvideo-conference where joiners can participate in the discussion. So\nspectators from the community are OK, but please leave your camera/mic\noff if you're not actively participating.\n\n> The physical setup this year will actually be 4 round tables, instead of\n> one giant table. I'm hoping this will facilitate breaking off into\n> sub-groups and having more intimate conversations, and maybe avoid the\n> \"it's hard to hear people at the other end of the table\" issues. Or\n> maybe it will just make it worse as we shout to each other from all four\n> tables. I can't wait to see!\n\nThere will be outlets for charging laptops, but probably only about half\nas many as there are people. So plan accordingly.\n\n> There's no organized dinner. However, there will be a social/drinks\n> event for the broader conference at 7pm; I'll provide more details\n> that day.\n\nThis is indeed happening, and is open to all Git Merge attendees.\nDetails should have been emailed out to the email address you registered\nwith. Note that they're asking people to RSVP through a web link. Please\ndo so if you're planning on coming!\n\nSee everybody tomorrow at 9:00am.\n\n-Peff\n"},{"id":"368205","messageId":"CAP8UFD1ka47UvU4CXRc5cMK=mpH0THtQkjG2-wOt2hhqLU4CsA@mail.gmail.com","threadId":"50282","inReplyTo":"2015d9ea-0570-b035-dcbb-ee1865381cf1@iee.org","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-01-30T23:13:01Z","receivedAt":"2019-01-30T23:13:17Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jan 31, 2019 at 12:05 AM Philip Oakley wrote:\n>\n> On 30/01/2019 20:57, Ævar Arnfjörð Bjarmason wrote:\n> >\n> > * \"Big repos\". We had discussions about this in years past. It's a very\n> > spawly and vague topic. Do we mean big history, big blobs, big (in\n> > size/depth/width) checkouts etc?\n> >\n> > But regardless, many of us deal with this in one way or another, and\n> > it would be good to have a top-level overview of how the various\n> > solutions to this that are being integrated into git.git are doing /\n> > what people see on the horizon for scalabiltiy.\n\nI am also very interested in that topic ;-)\n\n> I'd also like a bit of discussion about ensuring that the partial clone\n> & filtering aspects of 'big repos' (if partial is needed /used then it's\n> big ...) still retain the full 'distributed' nature and capability of git.\n\nAnd in this too, especially regarding my work on many promisor/partial\nclone remotes (previously ODBs).\n"},{"id":"368211","messageId":"20190131020233.GH13764@szeder.dev","threadId":"50282","inReplyTo":"CAP8UFD3Kt3dreMnfAdLiP2yc47kBLoVYCk-2yDw67OkujVY=Ew@mail.gmail.com","subject":"Re: GSoC 2019 (was: Contributor Summit Topics and Logistics)","fromName":"SZEDER Gábor","fromEmail":"szeder.dev@gmail.com","sentAt":"2019-01-31T02:02:33Z","receivedAt":"2019-01-31T02:02:39Z","isPatch":false,"sender":{"key":"szeder.dev@gmail.com","avatar":"https://avatars.githubusercontent.com/u/116324?v=4"},"body":"On Tue, Jan 22, 2019 at 10:17:59AM +0100, Christian Couder wrote:\n> - microprojects idea for interested students (like\n> https://git.github.io/SoC-2018-Microprojects/)\n\n> Suggestions for microprojects or project ideas are welcome! Volunteers\n> for mentoring or org admin are welcome too!\n\nI think we should remove most (all?) CI-related microprojects.\n\n - The first three are about adding static analizers. Now, while\n adding a new build job to run a static analyzer is easy enough,\n it's also next to useless or even downright harmful in itself.\n Static analyzers are inherently prone to false positives, and\n dealing with those is definitely beyond the scope of a\n microproject. And adding a static analysis build job that always\n fails because of undealt with false positives, and thus makes the\n whole build failed will just make life harder for those who take\n the effort to look at CI results.\n\n Last year we had submissions for these micrprojcets, but in the\n end they were not picked up because of this.\n\n - One project suggest installing CVS, Subversion and Apache in the\n CI environmens to increase test coverage. Well, Subversion and\n Apache are already installed, and have been for a long time\n (though $GIT_TEST_SVNSERVE is not enabled (don't know why) and one\n test script is skipped because \"svn-info test (SVN version: 1.8.8\n not supported)\". That leaves only CVS, which is perhaps too small\n a microproject (perhaps even with old standards; our microprojects\n grew considerably over the years).\n\n - Finally, the last one is about building a webpage that analyses\n Travis CI test results and identifies flaky tests, and then goes\n on to suggest that \"look at the randomly failing tests and try to\n figure out why they fail\". I've got my fair share in fixing flaky\n tests, and IMO doing so is definitely beyond the scope of a\n microproject.\n\nOk, after suggesting the removal of five microproject ideas, here is a\nsuggestion for a new one:\n\n Find a test script that verifies the presence/absence of\n files/directories with 'test -(e|f|d|...)' and replace them with the\n appropriate 'test_path_is_file', 'test_path_is_dir', etc. helper\n functions.\n\nThe good thing about this is that there are plenty of those test\nscripts :)\n\n"},{"id":"368214","messageId":"CAP8UFD0kxvpjdMRcuprPonunCdN5ONTB=OYHaHvnbTb+s0rGzA@mail.gmail.com","threadId":"50282","inReplyTo":"20190131020233.GH13764@szeder.dev","subject":"Re: GSoC 2019 (was: Contributor Summit Topics and Logistics)","fromName":"Christian Couder","fromEmail":"christian.couder@gmail.com","sentAt":"2019-01-31T06:11:05Z","receivedAt":"2019-01-31T06:11:20Z","isPatch":false,"sender":{"key":"christian.couder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/208954?v=4"},"body":"On Thu, Jan 31, 2019 at 3:02 AM SZEDER Gábor wrote:\n>\n> I think we should remove most (all?) CI-related microprojects.\n\nYeah, I agree that they don't make sense anymore.\n\n> Ok, after suggesting the removal of five microproject ideas, here is a\n> suggestion for a new one:\n>\n> Find a test script that verifies the presence/absence of\n> files/directories with 'test -(e|f|d|...)' and replace them with the\n> appropriate 'test_path_is_file', 'test_path_is_dir', etc. helper\n> functions.\n>\n> The good thing about this is that there are plenty of those test\n> scripts :)\n\nThank you for this suggestion, I will add it.\n"},{"id":"368406","messageId":"86va22qsj1.fsf@gmail.com","threadId":"50282","inReplyTo":"20190130230702.GA25423@sigill.intra.peff.net","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2019-02-02T12:33:22Z","receivedAt":"2019-02-02T12:35:58Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Jeff King writes:\n\n> On Tue, Jan 22, 2019 at 02:50:27AM -0500, Jeff King wrote:\n>\n>> If you're not coming, you can probably stop reading this message now.\n>> The rest is all logistics.\n>\n> Here are a few additional last-minute logistics:\n>\n>> For people who want to try to join remotely, I don't think we're going\n>> to have a particularly fancy AV setup. But there should at least be a\n>> big screen (which we typically do not really use for presenting), and I\n>> hope we can provide some connectivity. I'll be visiting the venue the\n>> day before (Jan 30th) in the late afternoon (Brussels time) and I'll try\n>> to do a test run. If anybody wants to volunteer to be the guinea pig on\n>> the other end of the line, I'd welcome it.\n>\n> The remote connection will be done via Zoom, using this URL which will\n> become active shortly before 10:00am (Brussels time):\n>\n> https://github.zoom.us/j/186903655\n>\n> You may need to download an app or other software; solutions are\n> available for most platforms, and the zoom site should guide you.\n\nThank you very much for setting this remote connection up. It did make\nit possible for me to watch the Git Contributor Summit 2019 (and take\nnotes for Git Rev News). I have had Zoom installed already, so it was\nnot a problem. (As I have seen, Szeder Gábor was also spectacting ;-)\n\nThe audio was not always clear, which depended on where the person\nspeaking was positioned; I understand that it is a very difficult\nproblem to get good acoustic in such unstructured setup.\n\n> Note that this is _not_ configured as a one-way webinar. It's a real\n> video-conference where joiners can participate in the discussion. So\n> spectators from the community are OK, but please leave your camera/mic\n> off if you're not actively participating.\n\nAs far as I know it went untested (but then nobody announced that he or\nshe wants to actively participate remotely).\n\nI didn't stay for the 15-17 breakout session (talking in individual\ngroups); I wonder how well the remote connection setup would work with\nmultiple discussions in parallel.\n\n\nI have noticed a little 'recording' indicator; would recorded session\n(video or audio only) be made available at some point in time? Did\nanyone take minutes, or take notes (for example of the Summit agenda\ncreated at the start of the meeting -- when the audio was muted)? I\nwould be very interested in your impressions.\n\n> See everybody tomorrow at 9:00am.\n\nThe event actually started at 10:00am CET.\n\n\nThanks again,\n--\nJakub Narębski\n"},{"id":"368478","messageId":"CABPp-BGfSRy-NT+f39gSumD9haYZPAnpNPY-VnanioCbdYFoEQ@mail.gmail.com","threadId":"50282","inReplyTo":"86va22qsj1.fsf@gmail.com","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2019-02-04T19:30:09Z","receivedAt":"2019-02-04T19:30:31Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi Jakub,\n\nOn Sat, Feb 2, 2019 at 4:39 AM Jakub Narebski wrote:\n> I have noticed a little 'recording' indicator; would recorded session\n> (video or audio only) be made available at some point in time? Did\n> anyone take minutes, or take notes (for example of the Summit agenda\n> created at the start of the meeting -- when the audio was muted)? I\n> would be very interested in your impressions.\n\nI took some notes. I'm not sure how useful they'll be given that they\nwere meant just for my own memory (my company said I either had to\ngive a talk at the conference or come back and give a talk to my\ncoworkers about the conference in order for them to pay for it, so I'm\ndoing the latter). But, I'll provide them here in case they're useful\nto anyone.\n\nDiscussion points:\n * Fetch response CDN offloading (Jonathan Tan)\n * allows resumable cloning\n * does load balancing\n * gets the static part of history (e.g. until a week ago) from CDN, and\n last bits from \"main\" server\n * questions about whether to do multiple bits offloaded (e.g. almost\n full clone, only stuff from last month, etc.); can server keep track of\n manifest and direct client to necessary subset of pack on a CDN?\n * A review of \"Big\"\n * references, history, wide-checkout, deep-checkout, lots to gc, etc.\n * newer stuff: partial clones, worktrees, commit-graph\n * plan to do a breakout session later\n * NewHash\n * sha1 -> sha256\n * have sha256 repo locally talking to a server using sha1?\n * as of yesterday, binary that can create either sha1 or sha256 repos\n * will be using fixed length listing of shas in packfile; if given sha1\n is fourth in list, then the corresponding sha256 will be fourth\n * next: interoperation; fetch & push coming up next\n * done a fair amount of work so moving to a new hash in the future with\n a different length should be much less work\n * no automatic translation of commit messages, but maintenance of\n dual-mapping of hashes\n * (Comments on sha1dc & its performance)\n * Submodules is the biggest issue right now\n * Poll: prove vs. jumbled output\n * some people didn't set up prove; some attempts to avoid perl on windows\n * nearly everyone using prove; could switch to it as the default\n * Poll: where should Git Merge be next year?\n * will bring up on list, but Canada is at least an option\n * North America is more likely to get Junio to come\n * I tried to push for North America...\n * Using mailmap by default in git log?\n * People change names for lots of reasons (including\ntransliteration differences)\n * Keep an option to not use mailmap\n * People generally positive on the idea\n \n * fetch response sideband-all\n * sidebands for progress messages and errors\n * sideband currently limited to when sending packfile\n * proposal: expand sideband for whole response, not just packfile.\n * particularly useful given ideas to do CDN\n * also needed for keep-alive messages\n * this will be a negotiated new capability (can't do it backward-compatibly)\n * protocol v2 for push\n * ref advertisement the main issue\n * would like to be able to modify the commit message (?!?)\n * rebase-on-push\n * reformat-on-push\n * discussion of how to split messages up into sub-commands\n * a way to retry pushes without re-pushing everything (e.g. someone else\n updated the branch, you then re-merged or rebased locally and want to\n push again, meaning the server already has _most_ the objects but just\n needs a few new ones)\n * partial clones\n * doing work to have multiple remotes (also ties in to CDN usage)\n * still very tied to having a server around to request additional objects\n * we need to have a way to keep upload-pack open and do multiple requests\n * has some ability to filter trees, but we need them for now for index\n * Matthew Devore doing some work in this area right now, but it appears\n to be based on depth rather than width?\n * connection with sparse checkout is kind of hacky right now\n * there are reachability enforcement issues in V2, which becomes even more\n of an issue with partial clones (now need to worry about blobs not just\n commits)\n * in a partial clone world, server can't gc\n * sidenote: dumb http support\n * no major hosting provider supports it\n * some people like it due to resumability (e.g. Joey Hess & git annex)\n * cgit provides dumb http support natively\n * questions I had in area: getting list of initial files of interest...\n gluing together with sparse checkout\n partial indexes\n \n * breakouts: merge, GSoc, structured logging, windows big files; I\nwas in \"merge\"\n * merge-recursive rewrite\n * questions and basic explanation of how the algorithm works\n * want incremental updates on merge-recursive rewrite\n * make merge-recursive code part of libgit.a ?\n * people are very happy about idea to not touch the working tree\n * make rebase --merge the default\n * use performance tests to see how well it compares (p3400-rebase.sh)\n * may later also reimplement the am-specific flags on top of interactive\n * make use of best merge bases in more places (e.g. git diff A...B uses a\n suboptimal one)\n * rebase --rebase-merges:\n * doing a five-way merge rewriting xdiff to handle five instead of three\n file versions\n * M merges A & B\n * M' should like like a merge of A' and B', but really involved in a\n five way merge of A', A, M, B, B' -- and that is necessary in order\n to get evil merge represented\n * overview of \"Big\"\n * git-sizer (funny: git-lab asks users to run it and return results; github\n runs it for user and shows them the results)\n * large blobs, partial clones\n * partial or hierarchical indexes\n * CI\n * Dscho has a lot of machinery built up around Azure Pipelines\n * PRs to github.com:gitgitgadget/git will automatically be built on\n Windows, MacOS X, and linux\n * Interest in getting emails for failures that their topic branch\n caused (note: get topic author from tip commit author if not Junio)\n * This may be able to move to github.com:git/git after Dscho's patches\n merge down\n\nStuff that had been mentioned but we didn't get to:\nstate-of-the-union, commit-graph, evolve (we had the developer of the\nfeature in mercurial present, but not the folks who had worked on the\nfeature in git), git filter-repo, maybe a few others I'm forgetting.\n"},{"id":"374295","messageId":"20190423034532.GA7753@sigill.intra.peff.net","threadId":"50282","inReplyTo":"86va22qsj1.fsf@gmail.com","subject":"Re: Contributor Summit Topics and Logistics","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-04-23T03:45:32Z","receivedAt":"2019-04-23T03:45:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Feb 02, 2019 at 01:33:22PM +0100, Jakub Narebski wrote:\n\n> I have noticed a little 'recording' indicator; would recorded session\n> (video or audio only) be made available at some point in time? Did\n> anyone take minutes, or take notes (for example of the Summit agenda\n> created at the start of the meeting -- when the audio was muted)? I\n> would be very interested in your impressions.\n\nI did record this. The resulting file is quite large, and full of\nincoherent bits and blank spots (where we took a break and turned off\nthe mics but forgot to pause the recording).\n\nI had planned to try to cut it down (at least roughly removing the\nuseless spots), but here it is April and I haven't managed to do so. If\nanybody wants to volunteer to take a crack at it, let me know.\n\nThe video file is a few gigabytes. TBH, I've wondered if just\ndistributing the audio would be just as useful, since the camera is\nmostly a static shot of people who aren't currently talking. ;)\n\n-Peff\n"}]}