git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	"Duy Nguyen" <pclouds@gmail.com>, "Johannes Sixt" <j6t@kdbg.org>,
	"Thomas Braun" <thomas.braun@virtuell-zuhause.de>,
	"Jeff Hostetler" <git@jeffhostetler.com>,
	"Git Mailing List" <git@vger.kernel.org>,
	"Junio C Hamano" <gitster@pobox.com>,
	"Jeff Hostetler" <jeffhost@microsoft.com>
Subject: Re: [RFC PATCH v1] telemetry design overview (part 1)
Date: Sat, 9 Jun 2018 22:05:49 +0200 (DST)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.1806092200490.77@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <20180609065635.GE30224@sigill.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 1893 bytes --]

Hi Peff,


On Sat, 9 Jun 2018, Jeff King wrote:

> On Sat, Jun 09, 2018 at 08:31:58AM +0200, Ævar Arnfjörð Bjarmason wrote:
> 
> > 1) I really don't see the basis for this argument that they'd need to
> >    patch it out, they're not patching out e.g. GIT_TRACE now, which has
> >    all the same sort of concerns, it's just a format that's more of a
> >    hassle to parse than this proposed format.
> >
> > 2) I think you and Johannes are just seeing the "telemetry" part of
> >    this, but if you look past that all this *really* is is "GIT_TRACE
> >    facility that doesn't suck to parse".
> 
> So that actually takes me to another question, which is: instead of
> introducing a new "telemetry" feature, could we make GIT_TRACE suck less
> to parse?

That's a different question, and even a different concern.

Please understand that this feature is needed for our own in-house use, to
be able to help our users pro-actively. We really want to be able to
contact a user when they struggle with the performance of any given Git
command, before they have to think of reaching out for assistance.

We discussed this plan at the contributor summit at GitMerge, and IIRC at
least Autodesk and DropBox were interested (but of course, the changes of
both Lars' and Alex' roles might make them less interested now), hence
JeffHost wanted to contribute this, for the benefit of the larger Git
community.

> E.g., could we have a flag or environment variable to have the existing
> traces output JSON? I guess right now they're inherently free-form via
> trace_printf, so it would involve adding some structured interface
> calls. Which is more or less what I guess JeffH's proposed feature to
> look like.

I think that is a much larger project than what JeffHost proposed, and
would unfortunately put too much of a brake on his project.

Ciao,
Dscho

  reply	other threads:[~2018-06-09 20:06 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 14:53 [RFC PATCH v1] telemetry design overview (part 1) git
2018-06-07 14:53 ` [RFC PATCH v1] telemetry: design documenation git
2018-06-08 11:06   ` Ævar Arnfjörð Bjarmason
2018-06-07 21:10 ` [RFC PATCH v1] telemetry design overview (part 1) Johannes Sixt
2018-06-08  9:07   ` Jeff King
2018-06-08 16:00     ` Thomas Braun
2018-06-08 22:01       ` Johannes Sixt
2018-06-08 22:20         ` Ævar Arnfjörð Bjarmason
2018-06-09  5:03           ` Duy Nguyen
2018-06-09  6:31             ` Ævar Arnfjörð Bjarmason
2018-06-09  6:56               ` Jeff King
2018-06-09 20:05                 ` Johannes Schindelin [this message]
2018-06-11  5:56                   ` Jeff King
2018-06-09  7:31               ` Duy Nguyen
2018-06-09  6:51             ` Jeff King
2018-06-09  7:04               ` Johannes Sixt
2018-06-09  7:31                 ` Jeff King
2018-06-12 16:04               ` Junio C Hamano
2018-06-09  6:56           ` Johannes Sixt
2018-06-09 20:43             ` Johannes Schindelin
2018-06-09 22:44               ` Johannes Sixt
2018-06-11  6:08                 ` Jeff King
2018-06-10  0:00             ` brian m. carlson
2018-06-11  6:14               ` Jeff King
2018-06-11  8:30                 ` Jeff King
2018-06-08  9:40   ` Ævar Arnfjörð Bjarmason
2018-06-08 15:46     ` Duy Nguyen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.1806092200490.77@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=jeffhost@microsoft.com \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=thomas.braun@virtuell-zuhause.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).