On Tue, Jan 22 2019, Jeff King wrote: > There's no set agenda; we'll decide what to discuss that day. But if > anybody would like to mention topics they are interested in (whether you > want to present on them, or just have an open discussion), please do so > here. A little advance notice can help people prepare more for the > discussions. This is definitely a "little" advance seeing as it's tomorrow morning. > Even if you're not coming, please feel free to suggest topics (but bonus > points if you convince somebody who _is_ coming to lead the session). Things I'd be interested in hearing / talking about about that haven't yet been mentioned. These are in descending order of how interesting I think these will be to a general audience, to the point where maybe only I care about the bottom of this list... * "Big repos". We had discussions about this in years past. It's a very spawly and vague topic. Do we mean big history, big blobs, big (in size/depth/width) checkouts etc? But regardless, many of us deal with this in one way or another, and it would be good to have a top-level overview of how the various solutions to this that are being integrated into git.git are doing / what people see on the horizon for scalabiltiy. * "Structured remote logging". We had an RFC spec for turning our trace format into something more structural with a way to send it to a remote server. There were both implementation & privacy concernse, last time at least a couple of users of git reported having in-house patches for this (not ready for upstream). Where are we on this now? * "commit graph by default". I had this on my list, but Derrick Stolee sent out a much better summary: https://public-inbox.org/git/6d0dc2a2-120c-0d42-1910-14ffed7adaf1@xxxxxxxxx/ * I've been using (but haven't yet re-rolled) my "relative SHA-1 abbreviation" series (https://public-inbox.org/git/20180608224136.20220-1-avarab@xxxxxxxxx/) I'm interested in seeing if anyone else is interested in this, and particularly what the overlap (if any) is between this & midx. * "Making strict fsck checks on clone the default". I worked a bit on this in this last year in between a couple of security issues that needed fsck checks. Has caveats etc., but would give users some more protections. * "The CI I set up for git on the GCC Compile Farm". Can be folded into a general "state of git.git CI" topic: https://gitlab.com/git-vcs/git-ci/pipelines * If people care about making the TAP mode in our test suite mandatory (i.e. require "prove" or a tool like it). See https://public-inbox.org/git/87zhrj2n2l.fsf@xxxxxxxxxxxxxxxxxxx/
