►
From YouTube: 2021-09-14 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
How
are
you
pretty
good?
I
was
supposed
to
go
on
like
a
bike
ride
this
morning
at
like
5
a.m,
but
I
slept
through
it,
so
I
guess
not
too
good,
but
we'll
be
there.
B
Is
interesting,
yeah
I
remember
my
first
company
when
I
started
it
was
like
here's
a
laptop
and,
like
you
know,
that's
it.
A
Yeah
yeah
my
startup,
I
worked
at,
I
guess
a
couple
companies
ago.
My
first
job
was
literally
like
they're,
like
you
get
a
standing
desk,
but
you
literally
have
to
build
the
desk,
and
that
was
my
first
day
and
it
was
like
a
real.
It
was
like
this.
Isn't
software
engineering
like
this
is
like
you
better
figure
out,
I
hope,
you're
an
engineer
because,
like
here's
a
desk,
so
that
was
like
it
was
like
a
hammer
so
yeah
I've
had
I've
had
a
variety
of
startup
experiences.
B
B
A
A
C
A
True,
it
is
I
I
work
at
shopify
now.
So
all
your
vendor
questions,
please
refer
them
to
rob
or
you
matt
yeah,
and
it's
a
publicly
recorded
meeting
so
I'll
just
say:
I'm
sad
to
leave
but
happy
to
change
it.
No,
it
was
yeah.
So
anyway,
I
have
no
idea
what
they're
doing
in
regards
to
open
telemetry
whether
someone
one
of
my
former
co-workers
will
be
joining
in
my
instead
there's
some
folks.
A
I
can
refer
people
to
if
they
have
data
dog,
specific
questions
who
are
more
involved
on
like
the
metric
side
but
agent,
the
collector
there
there
there's
some
data
dog
contributors
to
the
collector.
So
if
people
have
dated
questions,
I'm
happy
to
put
you
in
touch.
I
didn't
burn
too
many
bridges
when
I
left
and
yeah
excited
to,
hopefully
we'll
see
what
my
boss
lets
me
do,
but
hopefully
be
able
to
ship
more
open,
telemetry
ruby
code,
which
will
be
fun
so
should
be
more
active
here.
A
If
you
ever
want
to
set
like
six
figures
worth
of
equity
on
fire,
what
you
should
do
is
leave
datadog
before
you're
fully
vested
and
go
to
shopify.
Now
yeah
yeah
I'll,
see
what
my
boss
is
a
real
he's,
a
tough
cookie
to
read
but
I'll
see
what
he
has
to
be
doing,
I'm
doing
like
a
bunch
of
onboarding
stuff
right
now,
so
I
haven't
even
met
like
this
is
actually
my
first
meeting
with
my
team
awkwardly
enough.
A
E
Dump
work
on
them
and
when
it
was
in
person,
it
was
a
little
bit
different
because
you'd
like
snag
someone
when
they
had
free
time
for
lunch
or
something
like
that,
so
they
can
meet
their
team
and
see
their
desk
and,
like
all
that
stuff,
but
online
onboarding
seems
to
be
just
like.
You
started
the
company
and
then
you
start
your
job.
A
few
weeks
later,.
A
Yeah
it's
interesting.
I've
already
been
like
is
amazon
people
I
don't
know,
but
I
yeah
I.
I
guess
this
is
a
unusual
circumstance,
but
totally
you
know
we
know
each
other
already.
So
it's
anyway,
let's
not
have
my
weird
personal
stuff,
distract
from
the
progress
of
open,
telemetry,
ruby.
D
Congrats
to
you
and
congrats
to
shopify,
I'm
sure
this
will
will
lead
to
much
great
stuff
in
the
future.
D
Yeah
I
was
out
last
week,
so
I
don't
know
what
happened
if
there's
anything
super
relevant
that
I
should
talk
about
in
the
beginning.
Let
me
know:
if
not,
we
can
do
the
usual
and
run
through
the
spec
sig.
D
Yeah,
so
there
was
a
update
about
the
metric
sig.
The
metrics
sdk
spec
is
almost
ready
for
experimental
release.
So
you
know
it
seems,
like
progress
is
happening
over
there.
Things
are
starting
to
gradually
firm
up
so
any
interest
in.
D
E
D
At
least
for
now,
that's
how
the
how
things
would
be
structured
because,
like
the
the
metrics
api,
is
technically
not
stable,
so
it's
like
a
stable
api
cannot
reference
like
an
unstable
api.
I
think
is
part
of
like
the
versioning
strategy,
so.
E
So
once
it
it
did
become
stable,
so
understanding
that,
like
initially
as
we
worked
on
it
would
be
version
in
such
a
way
that,
like
it,
is
clear
that
we,
you
know,
we
like
append
experimental
for
the
end
of
the
version
number
or
something
like
that,
but
eventually
it's
going
to
become
stable
and
hit
a
1.0.
Is
there
a
point
where
okay,
francis
just
answered
one
signal,
stable,
gets
merged
into
the
api
gene?
So
then
people
wouldn't
have
separate
gems.
E
D
Okay,
yeah,
I
think
we
would
you
probably
have
some
options
for
how
that
would
work.
You
might
be
able
to
make
the
api
depend
on
the
the
api
and
the
sdk
depend
on
those
individual
metric
gems,
but
yeah,
I
think
that's.
That's
kind
of
just
part
of
the
magic
trick
is
that
for
the
unstable
things
we
need
to
develop
them
separately
and
then
kind
of
integrate
them
when
they
are
stable,
yeah.
E
Yeah,
I
think
that
becomes
interesting
when
you
think
about
how
that
looks
like
for
auto
instrumentation
and
whether
or
not
auto
instrumentation
includes
metrics,
which
I
imagine
some
of
them
will
right
like
yeah,
I
think
that's
like
maybe
a
later
discussion
once
we
actually
get
to
implementing
it.
D
D
As
far
as
I
know,
the
one
thing
that
was
kind
of
outstanding
on
this
was
there
were
some
questions
about
whether
or
not
this
should
be
like
optional,
optionally,
configurable.
A
But
do
you
mean
sampling
in
general
or
this.
A
A
Yeah,
I
think
the
guy
who
wrote
one
of
the
co-founders
of
oklahoma,
I'm
blanking
on
his
name,
one
of
the
the
uber
guy
yeah
yeah
yuri,
was
saying
I
think
there
I
thought
they
were
all
in
agreement,
that
it
would
kind
of
sampling
in
general
would
be
optional
because
the
opinion
was
sampling,
wasn't
necessarily
a
core
part
of
it.
Tracing
distributed
tracing.
D
A
D
So
there
was,
I
think
we
talked
about
this
a
couple
weeks
ago.
There's
an
issue
to
capture
http,
request
response
headers
as
attributes.
D
For
price
data,
so
I
think
possibly
I
don't
know
I
guess
it's
up
to
debate,
but
you
you
could
flatten
these
things
out.
So
you
just
had
http
request,
headers
dot,
key
name
and
add
them
like
so.
D
And
then
I
guess
there's
an
issue
to
make
gzip
the
default
compression.
This
got
debated
fairly
heavily
for
some
reason.
As
far
as
I
know,
the
collector
supports
gzip
without
a
problem,
and
I
think
that
was
a
lot
of
the
discussion
was
that
you
could,
if
suddenly
clients
defaulted
to
gzip
on,
you
might
break
some
server
somewhere.
That
didn't
know
this,
because
it
has
not
been
formally
specced
or
not
specked
in
the
right
way,
so,
but
basically
go
and
js
support
this.
I
think
we
support
this.
D
And
I
think
generally,
the
consensus
was
like
they
would
like
to
update
the
spec
to
make
this
a
little
bit
more
clear
and
that
if,
in
the
default
case,
you
are
probably
sending
data
to
a
remote
server,
it
should
probably
be
gzipped
out
of
the
box.
So
if
you're
like
a
web
browser
for
example-
but
I
think
there
is
there's
more
want
to
come
on
this-
are
we
gzip
on
by
default?
Or
do
you
have
to
turn
it
on?
No.
C
No,
the
spec
says
gzip
is
off
by
default,
so
you
have
to
turn
it
on,
but
you
know
there's
the
eternal
debate
about
which
compression
algorithm
to
use
and
cpu
overhead
and
all
this
sort
of
stuff.
So.
D
And
then
I
think
the
next
one
that
took
a
long
time
is
there's
an
otep
for
resource
schema
migration
tools
for
the
sdk.
So
there's
there
are
now
these
schema
urls
and
I
think
basically.
D
For
addressing
semantic
convention
changes-
and
it
sounds
to
me
like
at
least
it's
coming
from
like
the
google
side
of
things-
and
they
have
a
number
of
of
resource
detectors,
I
think
they're
maintaining
a
lot
of
like
various
gcp
resource
detectors.
Maybe
for
other
languages.
I
don't
know
if
they're,
I
think
we're
maintaining
the
ruby
one.
D
But
maybe
this
is
not
not
true
across
the
board
and
they
are
keeping
them
outside
of
open
telemetry,
because
the
semantic
conventions
aren't
stable
and
I
think
they're
kind
of
looking
for
a
way
to
be
able
to
make
sure
that
the
resource
detectors
are
naming
the
resources
in
accordance
with
the
schema
that
they're
supposed
to
be
adhering
to.
D
I
don't
know
like
I'll
admit.
This
is
the
first
time
I've
kind
of
seen
the
schema
interface,
I
guess
with
an
actual
application.
I
was
kind
of
under
the
impression
that
maybe
this
is
more
of
a
back-end
concern
that
the
that
sdks
would
just
send
data,
as
as
it
was
collected
with
a
schema
that
was
used
in
the
back
end
could
figure
out
if
it
wanted
to.
D
D
Is
here
for
or
to
at
least
preserve
data
and
rules
that
are
set
up
on
attributes
that
ultimately
end
up
getting
renamed
so.
D
D
And
yeah,
so
a
few
things
we're
a
little
weird
about.
This
is
only
talking
about
resources,
it's
not
talking
about
spans,
but
there
it
is
proposing
a
set
of
sdk
features,
a
mechanism
to
migrate
a
resource
up
or
down.
D
D
A
A
Yeah,
it
feels
it
feels
weird
to
be
doing
it
client-side,
but
okay.
D
A
Yeah,
it's
a
little
weird.
I
mean,
I
think
the
other
thing,
that's
all
confusing
me
is
like
the
pipeline
of
whatever.
If
you
have
like
a
collector
in
your
pipeline
at
all
or
not,
I
think
like
what,
if
there's
a
resource
processor
within
your
collector,
should
you
be
do
those
keys
get
migrated
or
it?
A
It
feels
like
there's
some
edge
cases
and
then
additionally,
just
like
besides,
like
oh,
maybe
we
shouldn't
be
doing
a
bunch
of
extra
processing
and
like
a
lambda
that
work
instrument
like
yeah,
it
seems
like
maybe
the
collect
how
this
impacts.
The
collector
is
unclear
to
me
or
what
they'll
like
yeah,
just
like
what
in
practice
whether
this
would
be
effective
because
in
it
feels
like
people
would
build
rules
around.
A
D
Yeah,
I
definitely
as
this
was
introduced
like
I
think
this
definitely
solves
a
specific
use
case
that
google
is
having
where
I
think
they
are
having
to
kind
of
keep
the
the
resource,
detectors
and
exporters
outside
of
the
open,
telemetry
repos
they're,
keeping
the
model
contribute
they're
kind
of
keeping
them
locally
or
in
their
private
in
their
in
their
company
repos,
and
they
would
like
a
way
to
just
be
able
to
have
one
version
of
these
things
that
you
know
adapts
to
changes
in
schema.
D
D
There
was
there's,
allegedly
a
prototyping
go,
so
maybe
if
the
link
is
ever
inserted
here,
we
can
take
take
a
look
at
that
and
see
what
what
people
have
in
mind.
D
And
that
generally
was
the
specs
egg.
Nobody
came
from
the
instrumentation
thing,
but
I
know
we
have
robert
has
been
going
to
that.
So
maybe
I
can
hand
this
off
to
to
you
to
tell
us
about
the
instrumentation
thing.
E
E
I'd
say
pretty
much
took
up
the
entire
last
meeting
I'll
put
the
link
here
for
everyone
to
see
they
can
read
through
on
their
own
I'll
kind
of
try
to
do
my
best.
To
summarize
what
I
took
away
from
understanding,
it
there's
actual
examples
that
help
illustrate
this
a
little
bit
better
here.
E
So
I
don't
think
I
think
we've
already
solved
some
of
it
in
our
implementation,
but
they're
talking
about
where
you
have
multiple
like
server
spans,
so
it
would
be,
if,
like
we
had
our
racks
band
and
then
maybe
a
rails
controller
span
and
so
on
and
so
forth,
and
if
you
have
like
a
span
for
each
middleware
and
so
they're
saying
that
this
becomes
really
noisy,
because
different,
auto
instrumentation
may
effectively
duplicate
the
same
information
at
a
slightly
different
layer,
and
the
motivation
is
just
to
like
reduce
the
noise
and
just
kind
of
bring
it
down
a
bit.
E
That
would
look
to
see
if
say
in
this,
existing
span
already
exists
like
is
there
already
an
existing
issue,
client
span
and
if
there
is
don't
produce
one?
So
thinking
of
like
say,
you
have
some
sort
of
api
client
gem
that
uses
the
net
http
library
if
it
instruments
this
client
span,
then
that
http
library
should
not
produce
its
own
spans
and
that's
like
the
really
high
level
look
at
it.
There
was
a
little
bit
of
concern.
E
I
think
like
it
wasn't
really
over,
you
could
just
tell
there
was
a
little
bit
hesitation
around
like
introducing
all
these
checks,
because
the
cost
associated
with
it,
but
that
was,
I
think,
getting
a
little
bit
into
the
implementation
details
and
I
think
that
kind
of
wasn't
really
deep
dive.
It
was
more
just
like
presenting
this
idea
and
kind
of
going
through
if
it
makes
sense
one
of
the
use
cases-
and
I
think
this
is
coming
from
someone
who
works
on
azure
and
they're-
talking
about
well
their
instrumentation-
that
they
do.
E
They
have
a
much
richer
client
span,
so
the
ones
that
come
below
it
end
up
just
being
kind
of
additional
noise
or
replicated
information
it
just
it
spikes,
the
the
trace
volume
or
the
span
volume
without
actually
adding
any
value.
But
I
don't.
I
don't
know
if
that
I
don't
know
if
it
makes
sense
like
how
I
feel
about
it,
because
there's
the
two
sides
of
it.
E
E
E
E
D
I
was
going
to
ask:
is
this
all
right
so
in
this
example,
they're
just
kind
of
you
know
trying
to
take
the
outer
server
span.
I
know
like
our
approach
in
ruby
has
been
to
kind
of
store
that
span
and
just
keep
like
enriching
and
decorating
it
with
more
and
more
stuff.
Is
I
see,
there's
an
exist,
so
you
can
see
if
the
key
exists.
E
The
discussion
was
more
about,
like
you
would
just
you'd
suppress
it
like
you,
wouldn't
do
it,
you
wouldn't
be
augmenting
it
or
enriching.
I
tried
to
find
a
gap
in
the
conversation
to
get
into,
but
it
was
pretty
heavy
conversational
way
through.
I
didn't
have
like
a
good
interjection
point,
but
that's
what
I
wanted
to
see
is
like,
where
does
enriching
existing
spans
like
how
does
that
fit
into
all
this?
Because
that's
the
approach
we've
taken
and
I
think
it
makes
a
lot
of
sense.
D
D
I
don't
know
I
feel
like
this
is
way
more
nuanced
than
this
document
makes
it
out
to
be
it's.
My
two.
E
Cents,
I
think
this
all
exists
in
the
java
repo
again.
I
think
all
this
stuff
already
exists
in
java,
and
this
seems
to
be,
I
think,
something
that's
trying
to
retroactively.
Take
their
implementation
and
it's
backing
out.
D
Yeah
I
find
that
you
often
have
to
kind
of
fight
these
fights
back
on
on
these
things
because
of
the
fact
that
they
are
trying
to
like
retroactively
spec
a
thing,
so
they
introduce
it
as
though
they're
having
a
conversation
about
a
new
idea,
that's
actually
like.
No,
we
want
to
do
this
and
as
soon
as
you
start
like
suggesting
something
else,
it
doesn't
always
go
over
super
well,
but
I
like
what
we're
doing
in
ruby.
To
be
honest,
so
I
feel
like
it's
good,
that
we
have
a
representative
at
this
meeting.
E
Yeah,
I
think
I
think,
what's
really
required
there
is
that,
like
we
actually
flush
out
like
just
like
kind
of
fill
out,
our
implementation
of
maybe
say
like
having
http
helpers
and
a
few
different
like
instrumentation
support
things
and
then
actually
do
what
they're
doing
and
just
document
the
approach
we've
taken
and
that
we
can
put
it
side
by
side
with
it
because
during
the
first
two
meetings,
I
kind
of
I
think
I
already
showed
this.
E
Everyone
here
is
that
I
really
pushed
to
say
that,
like
the
concern
is
that
like
we
don't
have
to
write
java
and
ruby
right,
and
that
was
like
my
biggest
concern-
is
like
a
specific
language
approach-
might
make
sense
for
that
language.
But
it
may
look
quite
a
bit
different
in,
like
you
know,
a
statically
typed
compiled
language
versus
like
an
interpreted
language
like
ruby.
So
I
think,
but
I
do
think
for
us
to
be
properly
heard.
C
They
show
an
example
here
of
enrichments,
where
they
suggest
that
you,
so
it's
that
enrichment
example.
Sorry,
you
just
scrolled
past
it,
but
the
enrichment
example
shows
where
you'd
ask
for
the
current
http
server
span
or
server
context,
I
guess
or
from
context
yeah,
so
you'd
ask
for
the
current
http
server
span
and
then
you
could
augment
it.
C
So
I
mean
this
is
not
an
unreasonable
on
the
flip
side,
I
think
there's
a
distinction
between
how
you
want
to
instrument
http
clients
and
how
you
want
to
instrument
http
servers,
and
you
know
many
services
are
both
or
contain
both,
and
my
philosophy
has
always
been
to
try
to
measure
as
close
to
the
wire
as
possible.
C
So
your
http
span,
http
server
span
measures
from
you
know
as
close
as
possible
to
when
the
request
is
made
and
when
the
response
is
received,
the
and
and
likewise
in
the
client
side,
the
problem,
the
the
problem
is
that
these,
like
middleware
here,
tends
to
be
inverted
right.
So
you
start
a
service
ban
and
then
you're
going
to
enrich
it.
As
you
start
processing
middleware
on
the
flip
side
for
clients,
you
generally
want
to
accumulate
information
to
enrich
the
ultimate
client
expand.
C
C
It
also
like
in
my
reading
of
this.
You,
you
kind
of
set
this
the
suppression
model
globally.
C
Is
that
true?
Or
am
I.
A
C
C
So
you
can
suppress
by
client,
so
you
can
say
only
one
client
or
allowed,
or
you
do
client,
oh
okay,
so
they're
even
going
further
and
saying
that
you
can
say
there's
only
one
kind,
so
you're
only
going
to
get
an
http
client
span
or
a
db
client
span
in
the
case
of
elasticsearch,
for
example,
or
you
say,
suppressed
by
kind
and
convention.
C
So
you'll
only
get
one
http
client
spam,
but
you
might
get
an
http,
so
you
might
get
a
db
client
spam
or
you
turn
suppression
off.
But
again
this
is
this
is
a
global
setting
for
the
sdk,
whereas
it
feels
like
you
might
want
to
do
suppression
based
on
kind,
so
you
say
I
want
to
do.
F
Would
it
would
it
also
work
like
these
are
configurable
options
on,
say,
elasticsearch
instrumentation
like
it's
in
this
it
feels
like
this
is
also
the
choices
you
would
want
to
make
are
more
specific
than
api
sdk
level
global
settings
like
I
would
want
to
say
my
elastic
search
instrumentation.
I
would
like
only
the
db
level.
Not
your
underlying
http
client
calls.
F
A
Do
we
even
do
we
have
confidence
that
we
would
be
able
to
look
back
and
know
if
there
was
a
like
whether
span
key
http
client
dot
exists,
like
I
don't
know
if
the
process
forks
or
there's
some
indeterminately
long
amount
of
time
that
passes
like,
but
do
we
really
have
a
a
way
to
like
kind
of
look
up
the
trade
that
the
tree
of
the
trace
and
say
like.
C
You
can
look
up
the
context.
I
mean
you're
you're,
not
looking
globally
you're,
just
looking
at
the
current
process
or
in
the
current
thread
or
fiber
or
whatever
you
want
to
call
it
right.
So
you're,
just
looking
up
your
current
context
and
looking
up
the
tree
to
see,
do
I
have
something
in
my
tree.
That
is,
you
know
an
http
client
span.
C
I
I
mean
that's
one
way
of
doing
it.
The
other
way
is
that
you're
actually
making.
Well
it's
going
to
say
the
other
way
is
you're
actually
maintaining
context
per
type,
but
it
gets
even
more
problematic
because
there's
this
requirement
that
an
hd
given
given
the
mode
suppress
or
like
nested
by
kind,
suppress
nested
by
kind.
Sorry,
you,
when
you
ask,
does
an
http
client
span
exist.
It
actually
has
to
look
for
any
client
span,
whether
that's
a
db
client
span
or
yeah
anything
at
all
right,
so
it
just
returns.
C
You
know,
here's
a
client
span
and
you
should
enrich
it
potentially
so
like
tracking
it
by
kind
is
complex
as
well.
So
you
really
have
to
do
this
linear,
search
every
time
right
or
you're
doing
some
kind
of
caching,
or
I
don't
know
like
it,
it's
going
to
be
somewhat
messy
and
inefficient
yeah.
C
A
Know
if
the
benefits
are
like
yeah,
I
don't
know,
I
do
think
that
oh
well,
I
do
think
I
just
got
something.
There's
a
big
misunderstanding
and
like
this
instrumentation
was
written
with
like
very
little
like
from
like
an
audit
perspective
of
like
hey.
How
many
spans
is
my
instrumentation
emitting
like
how
noisy
is
my
instrumentation?
A
I
don't
think
there
was
any
real
like
conscious
thought
around
that
and
it's
just
kind
of
been
like
karger
colted
down
from
whatever
originally
new
relic
did
in
2016
or
whatever
so
like.
I
do
think
that
is
something
that's
good
to
address
in
instrumentation.
I
don't
know
if
this
addresses
that,
though-
or
I
mean
this-
is
a
different
slightly
different
but
similar,
but
that's
the
thing
that's
more
concerning
to
me
is
like
some
of
this
stuff
is
just
like
incredibly
noisy
and
it's
unclear
like
especially
from
yeah.
A
Just
like
you
don't
have
a
ton
of
control
over,
like
let's
say
you
charge
for
spam,
which
is
a
very
reasonable
price
and
model,
probably
the
best
price
model.
Like
you
know,
there's
there
hasn't
been
like
a
careful
auditing
of
like
how
many
spans
are
being
emitted
and
there
it
hasn't
really
been
a
way
to
like
control
that
so,
like
I
guess,
processors
I
don't
know
yeah.
I
don't
know
if
I
gotta
read
this
more.
This
is
chunky.
C
Yeah
I
mean
samplers
are
the
other
place.
You
could
have
that
kind
of
control
yeah
to
avoid
creating
things
you
know
creating
spans
if
you've
got
an
existing
client
spam
whatever
but
yeah.
It's
it's
messy,
partly
because
you
have
to
do
this
look
up
through
the
tree
because
you
may,
like
you're,
gonna,
have
to
skip
over
internal
spans,
for
example.
C
So
the
other
problem
I
had
when
I
was
reading
this
is
it
imposes
requirements
on
instrumentation.
It
says
to
it
doesn't
just
say
like
sdk
implementers
must
do
this.
It
says:
instrumentation
authors
must
do
this
and
the
instrumentation
authors
are
going
to
be.
C
You
know,
hopefully,
one
day
rails,
authors
or
you
know
redis.
You
know
elasticsearch
client,
library,
authors
whatever
right
so
there's
gonna,
be
these
people
writing
first
party
instrumentation.
C
Are
they
going
to
read
a
spec
that
closely
where
the
spec
says
you
must
do
x
if
you're
instrumenting,
your
your
library
versus
you,
know
providing
helpers,
saying
if
you
want
to
be
a
good
citizen,
maybe
you
can
support
suppression
in
this
way
or
you
know
what
we
talked
about
previously,
providing
an
api
that
supports.
C
That
makes
it
easier
to
adhere
to
semantic
conventions
for
http
spans
as
an
example
rather
than
forcing
people.
You
know
saying
you
must
do
this.
G
D
As
we
talk
about
this-
and
I
think
generally,
this
thought
was
stirred
up
by
eric
kind
of
asking.
D
Do
we
actually
have
this
data
around
somewhere?
And
I
think
I
don't
know
any
time
you
get
these
interactions
where
you're
looking
back
up
the
tree,
I
think
stuff
gets
sketchy
and
in,
like
the
you
know,
in
the
straightforward
kind
of
synchronous
case
where
every
child
ends
before
its
parent,
like
everything
is
going
to
work
out
fine,
but
I
I
think
there
are
exotic
scenarios
where
this
doesn't
work
out
super
well
and
like
I'm,
just
kind
of
imagining
some
fictitious
http
client
that
just
kicks
off
a
batch
of
http
requests.
D
D
A
Yeah,
I
think
what
rob
is
mentioning
remind
this:
if
only
we
had
a
trace
level.
F
Yeah,
I
could
just
say
it
this.
This
smells
like
trace-aware
tail
sampling
of
discrete
spans
within
a
larger
choice,
and
if
I
understand
the
problem
domain,
that's
generally
not
something
you
want
happening
in
the
client.
D
But
yeah,
that's
kind
of
what
I
was
thinking
is
that
this
is
more
of
a
because
of
that
fact
that
you
can't
always
know
the
state
of
a
span
further
up
in
the
trace.
I
guess
in
process.
It
seems
like
you
kind
of
got
to
do
this
after
the
export
has
happened,
and
then
you
can
collapse
things
as
as
you
wish,
but.
F
If
wishes
were
fishes,
we'd
have
a
tail
sampling
processor
in
the
collector
that
could
apply
some
rules
like
this
and
go
okay.
I
have
a
trace
that
has
these
things
in
it,
so
this
set
of
sub
spans
within
the
trace
match
my
rules,
so
I'm
going
to
cut
these
things
out
or
but
working
for
a
vendor
that
wrote
one
of
those
that
isn't
part
of
the
collector.
But
it's
a
standalone
thing.
That's
hard.
F
We
we
have
a
twinkle
in
our
eye
to
try
to
once
the
sampling
otep
is
is
understood
and
we
sort
of
all
agree
how
sampling
is
going
to
work
and
how
we're
going
to
talk
about
it.
We
we're
like
pondering
whether
that's
a
processor
that
we
could
add
to
the
collector,
but
doing
it
well
involves
the
collector
becoming
much
more
complicated
of
a
clustering.
You
have
to
run
a
cluster
of
them
and
there's
all
sorts
of
state
stuff
that
you
have
to
manage
across.
A
A
E
I
think
if
we
put
together
some
notes,
I
can
definitely
bring
it
up
tonight,
because
the
next
one
is
tonight
and
also
anyone
else
is
interested
in
like
participating
in
these
that
are
welcome
to
join,
I'm
obviously
going
to
keep
going
and
doing
my
best
to
bring
back
information
so,
but
if
anyone
feels
like
really
really
strongly
about
something,
it's
I
think
it's
usually
best.
If,
like
the
person
who
has
the
strong
feelings,
present
them
right.
Otherwise,
you
get
that
kind
of
like
messenger
problem
or
don't
treat
the
messenger.
E
E
I
think
it
would
make
a
lot
more
sense
to
you,
because
it's
just
that
you
you
put
friction
in
the
the
least
desirable
paths
that,
like
the
instrument
just
take,
you
make
it
easy
for
them
to
do
the
right
thing,
but,
like
francis
pointed
out,
if
you
put
like,
must-
and
you
try
to
push
that
on
a
first
party
instrumentation
out
there,
like
they
probably
won't
even
look
at
it,
there's
a
good
chance.
They
won't
even
look
at
it
right,
like
they're,
maintaining
their
project.
They
think
this
is
a
good
idea.
E
They're
interested
they'll
put
in
their
best
effort,
but
they're
not
necessarily
going
to
come
through
multiple
pages
of
specification
to
make
sure
that
it's
exactly
you
know
as
defined
right,
but
if
there's
something
that
they
can
just
pull
in
a
package
that
they
can
use.
That
says,
like
hey,
if
you're
doing
this
use
this,
then
they
don't
really
have
to
look
at
it
right.
E
E
Didn't
even
one
else
have
any
like
thoughts
I
want
to
share
on
this.
I
I
think
this
like
covers
a
lot
like
the
high
level
points
of
it,
like
obviously
dig
through
the
dock,
and
this
thing
is
a
few
hours
later.
I
think
it's
been
like
six
hours
from
now
so
do
join
if
you're
interested
changing
topics
a
little
bit
here.
Did
anyone
end
up
reaching
out
to
carlos
about
having
them
come
over
the
repo
again?
Oh.
E
Once
once
we
have
him
look
over,
I
think,
then,
like
ending
the
outcome
of
that
we're
good
for
a
proper
1.0,
which
is
really
exciting.
We
can
all
have
like
little
party
hats
on
on
the
next
day,
good
that
that
we
release
it
on.
E
C
C
Maybe
incompatible
with
what
we've
done
right
now,
so
we'd
be
breaking
compatibility,
I'm
not
sure
in
what
way.
Yet
so.
C
It'd
be
good
if
folks,
who
are
familiar
with
the
concurrent
ruby
gem,
could
have
a
read
through
this
and.
A
Yeah
not
familiar
with
it,
but
I'll
make
sure
that
somebody
looks
at
it
previously
maintained
instrumentation
for
concurrent
ruby,
despite
having
never
used
it
outside
of
like
a
personal
project
in
which
I
just
was
lazy
and
but
yeah.
I
I
think
do
our
I
mean
in
general,
our
instrumentations
don't
have
do
we
have
like
minimum
versions,
I'm
trying
to
think
if
we
like
document
it-
and
I
guess
we
have
it
in
the
in
the
patcher
but
yeah.
C
We
have
the
compatibility
thing
compatibility
check,
so
we
do
that,
but
I'm
not
sure
if
that's
what
he
means
or
like
I,
I
don't
know
if
this
is
an
issue
about
incompatibility
between
different
concurrent,
ruby
versions
or
a
change
in
the
way
our
instrumentation
is
working.
C
A
Right:
okay,
I'm
happy
to
review
this.
If
you
want
to
assign
it
to
me,
this
feels
like
pretty
you
know,
stepping
putting
my
toe
back
in
the
water.
Besides
my
one
other
thing,
I'm
assigned
which
actually
have
pr
coming
for
soon
but
yeah,
I
don't
offhand.
I
have
no
idea
the
current
ruby
history
or
context
of
the
gems.
D
I
feel
like
this
illustrates
the
concern
that
I
have
about
looking
up.
The
tree,
though,
like
if
you
just
look
at
this
example,
people
trace
her
in
span
parents,
man
and
then,
if
you
delete
that
future.value
line
at
the
end
of
the
block,
it's
like
that
parents
fan
can
be
done
and
long
gone
before
the
future
even
executes
and
it
could
be
exported.
D
D
C
F
E
D
C
Perhaps
I
don't
know
so,
interestingly,
right
now,
where,
if
they
just
blindly
set
attributes
to
augment
the
span,
that's
finished
they're
going
to
be
spamming,
the
logs
with
warnings,
so
that
could
also
be
interesting.
C
And
if
you're
using
multiple
threads
for
executing
the
promises,
then
there's
a
there's,
probably
a
race
condition
in
there
as
well,
because
you
can
check
to
see
if
it
exists,
you
could
even
check
to
see
if
it's
writable,
but
then,
when
you
go
to
write
it,
it
doesn't
work.
F
C
A
To
be
clear,
like
I
do
think,
there's
tremendous
value
if
you
can
get
guarantees
around
a
trace
containing
exactly
one
client.
You
know
like
http
client,
exactly
one,
then
it's
like
you
can
do
some
really
nifty
automated
analysis
and,
and
you
know
whatever
all
that
magic.
You
know
it.
It
lets
you,
you
know,
have
some
higher
guarantees,
but
it's
obviously
easier
yeah,
like
you,
said,
easier
fishes
for
wishes.
So,
but
I
do
I
mean
I
think
it's
valuable
to
have
somewhere
or
to
be.
You
know,
thinking
about
yeah.
E
Yeah,
that's
a
that's
a
good
point
like
I
did
like
the
or
sorry
I
didn't
like
the
kind
of
acceptance
of
having
potentially
multiple
clients,
fans
nested.
I
understand
why
we
kind
of
got
to
that
point,
but
having
that
tidy
one
server,
one
clients
fan
and
then
the
parody
there
is
seems
like
a
really
useful
thing
to
give
up.
E
Just
based
off
your
point
there,
like
being
able
to
do
the
analysis
on
it
and
like
it
just
it
seems
like
it's
sad
to
get
rid
of
that,
but
I
don't
know
if
the
proposed
solution
is
the
right
one.
I
I
really
do
like
the
approach
we
have
been
taking
of
like
at
some
level.
You
say
I
know
that
there's
going
to
be
a
client's
band
somewhere
down
the
line
and
I'd
like
to
give
it
this
information.
A
F
Certainly
passing
decisions
downwards
is
better
than
trying
to
go
upwards
because
a
decision
has
been
made
right
and
then
children
are
made
or
not
made,
based
on
some
decision.
That
has
maybe.
A
It
lives
on
the
scent
like
almost
within
near
a
sampler
or
something
I
don't
know
I
don't
know
or
within
a
sampling
decision.
I'm
sorry
is
that
what
okay
we're
over
time
but
good
nice
to
see
you
all
bye.