jh/trace2-sid-fix, was Re: What's cooking in git.git (Apr 2019, #02; Wed, 10)

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Junio,

On Wed, 10 Apr 2019, Junio C Hamano wrote:

> * jh/trace2-sid-fix (2019-04-01) 7 commits
>  - trace2: make SIDs more unique
>  - trace2: clarify UTC datetime formatting
>  - trace2: report peak memory usage of the process
>  - trace2: use system config for default trace2 settings
>  - trace2: find exec-dir before trace2 initialization
>  - trace2: add absolute elapsed time to start event
>  - trace2: refactor setting process starting time
>
>  Polishing of the new trace2 facility continues.  The system-level
>  configuration can specify site-wide trace2 settings (which would be
>  loved by big-brother types ;-).

While this is all fun and joy to perpetuate the stereotypes, I think that
more people would potentially be interested in using this in their
development teams, if only they knew what the actual purpose of trace2 is
(which this comment does not describe well).

As you probably use this description for the release notes, maybe it would
be a good idea to replace the Orwell reference by something like this:

	This allows trace2 to be enabled in a site-wide configuration. The
	intended audience for this feature are development teams which
	want to analyze and identify performance bottlenecks and other
	problems typical in their common workflows.

If you still need to be convinced that this kind of setting can help
tremendously with improving Git *itself* to become faster, watch the talk
by John Briggs at GitMerge 2019:
https://www.youtube.com/watch?v=vat97a8C0o0

I cannot stress how crucial it is for our in-house use to have this kind
of detailed logging to steer our development efforts.

And obviously you are totally allowed to continue to make these jokes
about surveillance, at least as long as you admit that you know that
nobody wants to enable this outside their own development teams.

It would just be nice to see it ackowledged from time to time that these
analyses that we perform ("we" meaning the team in which I am embedded,
and other teams, e.g. within Google) have a direct benefit to the Git
project, as we no longer have to guess or surmise where our time is best
spent improving Git's performance, but we can focus our attention wisely
based on scientifically-sound statistics.

Ciao,
Dscho

>  Getting closer but still being discussed.
>  cf. <20190403000032.GA190454@google.com>