git@vger.kernel.org mailing list mirror (one of many)
 help / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Duy Nguyen <pclouds@gmail.com>,
	Ævar Arnfjörð Bjarmason <avarab@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>,
	Jeff Hostetler <jeffhost@microsoft.com>
Subject: Re: [RFC PATCH v1] telemetry design overview (part 1)
Date: Tue, 12 Jun 2018 09:04:38 -0700
Message-ID: <xmqq602oat49.fsf@gitster-ct.c.googlers.com> (raw)
In-Reply-To: <20180609065132.GD30224@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

> 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").


  parent reply index

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-07 14:53 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
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 [this message]
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 publically 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=xmqq602oat49.fsf@gitster-ct.c.googlers.com \
    --to=gitster@pobox.com \
    --cc=avarab@gmail.com \
    --cc=git@jeffhostetler.com \
    --cc=git@vger.kernel.org \
    --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

git@vger.kernel.org mailing list mirror (one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/
       or Tor2web: https://www.tor2web.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox