Re: Contributor Summit Topics and Logistics

From: Philip Oakley <philipoakley@iee.org>
Date: Jan 30, 2019, 22:51 UTC
Message-ID: <2015d9ea-0570-b035-dcbb-ee1865381cf1@iee.org>
In-Reply-To: <87va253lun.fsf@evledraar.gmail.com>

On 30/01/2019 20:57, Ævar Arnfjörð Bjarmason wrote:

Show 26 quoted lines

> 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.

I'd also like a bit of discussion about ensuring that the partial clone & filtering aspects of 'big repos' (if partial is needed /used then it's big ...) still retain the full 'distributed' nature and capability of git.

Also in some environments the filtering may want to be applied at the server end (based on it's knowledge of the specific user). Ultimately it should also pull in some of the sub-module aspects as super projects are just big repos in disguise.

Show 30 quoted lines

>
> * "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@gmail.com/
>
> * 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@gmail.com/)
>
>    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@evledraar.gmail.com/

I also had some questions regarding tree walk issues for follower and friendly fork repos that have lots of deadheads within their tree, such as previous release versions in Git for Windows. It should be easier to filter those deadheads (or at least suggest the best way of creating such sentinels).

--

Philip