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

From: Johannes Sixt <j6t@kdbg.org>
Date: Jun 9, 2018, 07:04 UTC
Message-ID: <208bcf92-cc23-d63d-3dfc-441e960e1e02@kdbg.org>
In-Reply-To: <20180609065132.GD30224@sigill.intra.peff.net>

Am 09.06.2018 um 08:51 schrieb Jeff King:

> I actually think this could be useful for normal users, too. We have
> GIT_TRACE for dumping debug output, and we sometimes ask users to turn
> it on to help diagnose a problem (not to mention that we use it
> ourselves).

The BIG difference is in "we ask the users". Asking for a trace is a one-shot thing; this telemetry thing is obviously intended for long-term survaillance.

> AFAICT this telemetry data is the same thing, but for performance. When
> somebody says "why does this command take so long", wouldn't it be nice
> for us to be able to tell them to flip a switch that will collect data
> on which operations are taking a long time?

Why do we need long-term survaillance to answer this question and why can it not be made a mode of GIT_TRACE?

-- Hannes