Re: [RFC PATCH v1] telemetry design overview (part 1)

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 12, 2018, 16:04 UTC
Message-ID: <xmqq602oat49.fsf@gitster-ct.c.googlers.com>
In-Reply-To: <20180609065132.GD30224@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

> In my experience the maintenance burden is not in the "connect to a
> socket" part, but the fact that you have to sprinkle the entry points
> throughout the code (e.g., "set 'cloning' flag to 1" or "I'm entering
> the pack generation phase of the fetch"). So I'd love to see us do that
> sprinkling _once_ where everyone can benefit, whether they want better
> tracing for debugging, telemetry across their installed base, or
> whatever.

I tend to agree. Transport (or file) can stay outside the core of this "telemetry" thing---agreeing on what and when to trace, and how the trace is represented, and having an API and solid guideline, would allow us to annotate the code just once and get useful data in a consistent way.

> The mechanism to handle those calls is much easier to plug in and out,
> then. And I don't have a huge preference for compile-time versus
> run-time, or whether bits are in-tree or out-of-tree. Obviously we'd
> have some basic "write to stderr or a file" consumer in-tree.

If it makes readers fearful of big brother feel safer, I think we probably can add code that is runtime controllable that is compiled in conditionally ;-)

I do not quite buy "Big brothers who want this for their own in house use case can afford to patch" argument, by the way. If anything, having a solid tracing mechanism (to which existing GIT_TRACE support _should_ be able to serve as a starting point) would mean small budget guys do not have to do their own investing to collect useful data over their customer base (I am seeing an analog in "popcon", opt-in stats of installed package in a distro, which we can view as "telemetry data for distro installer program").