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@xxxxxxxxxx>
