►
From YouTube: 2022-02-22 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).
A
A
B
B
B
What
what
brings
you
to
hotel,
ruby
yeah?
I
just
wanted
to
check
it
out,
get
in
the
loop
a
little
bit.
I
am
the
manager
on
tim
and
robert's
team
at
shopify,
so
helping
oversee
some
of
that
probably
the
least
ruby
knowledgeable.
B
But
I
have
some
experience
with
you
know
the
observability
side-
and
you
know
just
general
software
and
here
just
to
learn
and
check
out.
What's
going
on
cool.
C
Welcome
yeah,
I
think
I
think
robert
or
eric
somebody
mentioned
that
you
might
be
dropping
in
last
week,
but
yeah
yeah.
Your
team
in
shopify,
has
done
some
awesome
work
on
this
project
so
for
sure.
C
Yeah,
this
is
a
little
bit
of
a
skeleton
crew
compared
to
usual,
but
this
is
about
the
time
we
usually
get
started
so
usually
I'll,
just
kind
of,
like
recap:
the
spec
sig.
It's
kind
of
the
the
the
place
where
the
specification
gets
created.
People
talk
about
the
issues
there,
so
just
kind
of
go
over
that
to
make
sure
that
we're
aware
of
things
that
are
happening
there
and
then
kind
of
move
on
to
our
repo.
C
C
So
yeah,
the
first
thing
we
discussed
were
the
default
propagators,
and
this
is
kind
of
when
you
just
have
an
api
installed.
No
sdk
like
a
lot
of
default
propagators,
and
I
believe
the
correct
answer
is
that
they
should
be
no
op
propagators,
and
I
think
there
was
an
issue
to
clarify
this
more
or
less.
C
C
There
was
a
question
this
is
from
the
java
ecosystem,
so
it
doesn't
really
matter
too
much
to
us,
but
there
is
the
there's
a
micrometer,
it's
a
metrics
library
for
for
java,
and
I
guess
it's
like
critically
important
and
the
question
which
is
really
like.
Should
this
go
in
the
core
repo
or
should
this
go
in
the
contrib
repo.
C
And
I
think
yeah,
the
the
key
takeaway
was
who's
going
to
maintain
it.
If
it's
the
it's
the,
if
it's
the
java
sig
that's
going
to
kind
of
fix
bugs
in
it
go
ahead
and
put
it
in
core.
If
it's
the
micrometer
folks
put
it
in
contrib.
C
We've
talked
about
this
one,
quite
a
bit:
the
change
of
name
from
instrumentation
library
to
instrumentation
scope,
so
the
pr
merged
to
actually
make
that
change
last
week.
This
is
the
pr
to
update
the
protos
to
make
the
same
change
and
the
whole
reasoning
behind
this
was
to
have
like
a
generic
name.
C
I
guess
to
refer
to
the
thing:
that's
generating
your
telemetry,
and
this
is
kind
of
coming
about
with
with
the
logging
seg,
they
were
considering,
adding
like
a
logger
name
field
for
a
little
while,
but
this
by
making
that
name
sufficiently
generic.
It
kind
of
resolved
that
so
we
didn't
have
to
add
this
additional
field.
C
C
This
is
this
pr
is
to
clarify
that
instrument.
Name
conflict
only
happens
within
a
meter
and,
as
far
as
I
can
tell
like,
the
only
change
in
this
pr
is
that
the
verbiage
was
changed
like
sdk
must
not
to
sdk.
It
should
not
allow
views
the
specified
name
to
be
declared
with
instrument
selectors
that
select
more
than
one
instrument
in
the
same
meter.
C
C
And
then
this
one
is
basically
pointing
out
that,
as
the
spec
is
currently
set
up,
that
there
ends
up
being
this
bi-directional
relationship
between
a
meter
provider
and
a
metric
reader
and.
C
I'm
not
totally
sure
what
the
issue
is
with
this,
but
people
seem
to
agree.
This
is
not
like
a
great
design
and
I
think
yeah
people
are
are
interested
in
trying
to
make
this
unidirection
unidirectional
or
kind
of
improve
the
modeling
to
some
degree.
Here.
C
The
rest
of
these
are
just
like
briefly
mentioned,
although
this
one
people
seem
to
be
most
interested
in,
it's
the
preferred
aggregation,
temporality
and.
D
C
C
Yeah,
that's
the
one
that
I
followed
too.
Sometimes,
like
they've,
been
rotating
the
meeting
links,
and
sometimes
you
will
just
like
copy
a
meeting
link
to
your
calendar
rather
than
using
like
the
the
community
calendar
and
that's
where
things
start
to
go
wrong.
C
Let's
see,
let's
see
if
I
can
explain
this
in
in
any
reasonable
way,
so
I
think
the
two
key
points
is
that
there
are.
C
There
is
delta
and
cumulative
aggregation
temporality,
and
the
idea
is
that,
with
all
these
instruments,
you'll
have
like
cumulative
metric
instruments
and
they,
if
it's
like
a
counter,
when
the
program
starts,
you
your
counter
will
be
at
zero
and
you'll.
Just
kind
of
increment
and
you'll.
Just
continue
to
increment.
As
time
goes
on.
You
just
keep
sending
up
that.
C
So
that's
kind
of
one
one
view
of
the
world
and
it's
a
popular
way
to
to
aggregate
metrics
like
it
has
this
good
quality
that
you
know,
sometimes,
when
you're
sending
metric
data
up
or
when
you're
exporting
metric
data.
Those
exports
fail,
like
cumulatives,
are
very
like
tolerant
to
failures
of
exports,
because.
C
You
always
kind
of
have
had
the
full,
the
full
number.
So
if
you
did
miss
an
export,
you
would
just
kind
of
get
like
a
slightly
weird
number,
if
you're
trying
to
subtract
over
that
interval,
but
you
wouldn't
have
like
complete
data
loss,
the
other
way
to
kind
of
view.
These
things
are
deltas,
where
you
always
just
kind
of
send
the
change
from
the
last
value,
and
you
kind
of
send
these
every
time
period,
and
these
are
less
like
less
resilient
to
to
to
failed
exports.
C
However,
it
seems
that
for
some
instruments
like
it's
like,
you
want
to
be
able
to
kind
of
choose
a
preferred
aggregation
temporarily
temporality
delta
or
cumulative,
but
there
are
a
couple
instruments
that
these
don't
really
work
super
well
with.
C
So
it
seems
like
if
you
have
secret
instruments
generally
defined
data
points
having
aggregation
temporality
of
some
histogram.
A
Hey
matt,
can
I
just
hit
you
for
a
quick
second
yeah
go
over?
Where
did
you
guys
get
this
link
from
where
our
rooms
were
split?
We
had
eric
and
amir
and
rob
kidd
and
one
of
our
new
guys,
sam
in
a
separate
room,
so
we
had
the
the
sig
split
in
two
places.
The
reason
I
found
out
is
because
tim
shot
me
a
message.
C
Excellent
yeah,
I
I
just
kind
of
said
that
I
bet
you.
This
meeting
is
happening
in
this
in
two
places
covering
the
exact
same
stuff.
C
We
got
the
link
from
the
public
calendar
so
yeah,
I
guess
heads
up.
The
links
are
changing
for
the
meetings.
C
I
think
that
a
lot
of
cigs
have
actually
had
trouble
with
like
their
meetings,
even
starting
like
the
javascript
zig
has
not
been
able
to
actually
get
into
the
official
meeting,
so
we've
been
using
like
dynatrace
links,
or
I
think
we
we
got
a
nice
expecto
link
once
from
amir,
but
if
you've
copied
something
from
the
public
calendar
to
your
calendar
like
delete
it
and
then
recopy,
okay
and
I
think
we're
gonna
have
the
same
problem,
though,
where
it's
like
kind
of
like
shared
meetings
so
like.
C
A
C
A
C
E
Being
down
yes,
be
on
the
slacking
down
and
we'll
move
on.
C
C
I
did
not
notice,
I
was
not
in
that
tab,
but
for
future
purposes.
That's
a
good,
a
good
thing
to
look
at.
C
I
was
trying
to
kind
of
maybe
explain
what's
going
on
here.
I
don't
know
how
much
it
actually
matters
so
I'll.
Try
not
to
get
this
too
much
into
the
weeds,
but
it's
this
clarifying
specific
specification
for
preferred
aggregation,
temporality
and
maybe,
if
I
skip
down
to
the
well
yeah,
I
think
I
was
basically
describing
that
there
is
cumulative
aggregation,
temporality
and
delta
aggregation
temporality
in
cumulative.
You
always
kind
of
send
up
whole
values,
you
don't
reset
them
between
exports
delta.
A
C
C
Yeah,
I
feel,
like
I've
kind
of
there
have
been
some
conversations
about
this,
and
I've
tried
to
follow
them,
but
I'm
I'm
not
this
far
along
in,
like
the
I
guess,
the
details
or
implementations
of
these
metrics
sdks
to
totally
understand
what
why
this
must
be,
but
it
seems
like
there
is
a
reason.
G
A
A
It's
like
you're
accumulating
values,
and
then
someone
requests
them
and
you
just
dump
it
all
out,
and
you
start
with
a
clean
slate
again,
but
now,
if
you're
going
to
potentially
intermingle
cumulative
values
that
have
to
persist
across
these
kind
of
dumps,
if
you
will,
then
it's
it's
a
little
bit
less
simple
and
less
appealing
than
the
the
excitement.
A
I
had
around
doing
that
as
like
the
first
tracer
bullet
of
like
getting
this
piped
through,
because
now
it's
like
I
mean
I
can
still
do
that,
but
it
still
adds
a
bit
of
confusion
because
it's
like
you
would
think
that
if
you
had
a
value
that
needed
to
behave
cumulatively
but
you're
using
a
delta
temporality
in
your
at
your
application
level,
that
you
would
do
the
accumulation
wherever
it
is
you're
sending
it
right
like
that,
would
start
to
become
the
responsibility
of
your
data
store.
Your
back
end.
A
Whatever
so,
it's
like
it's
pushing
this
mixed
responsibility
down
onto
the
app
which
there's
probably
a
good
reason
for
it
again,
like
I
think,
I'm
in
the
same
position
as
you.
I
haven't
discovered
that
reason,
so
it
just
sounds
like
a
little
bit.
It
seems
a
little
off
at
a
naive
impression
of
it.
It's
like.
Why
would
you
want
to
already
take
a
complicated
thing
and
overcomplicate
it
more.
C
It
has
to
be
something
to
do
with
the
fact
that
yeah,
I
assume,
has
to
do
with
something
something
to
do
with
the
monotonic
versus
the
non-monotonic
nature.
Of
these
two
things.
A
C
C
There's
there's
at
least
this
issue,
people
seemed
interested
in
and
again
I
didn't.
I
think,
I'm
not
enough
in
the
weeds
to
understand
what
the
issue
with
the
core
issue
here
is,
but
ultimately,
what
this
person
is
pointing
out
is
that
there
ends
up
being
the
way
the
spec
is
currently
written.
C
There
ends
up
being
this
bi-directional
relationship
between
meter
provider
and
metric
reader,
and
I
think
he
was
pointing
out
that,
like
this
was
not
not
a
great
design
and
I
think
other
people
tend
to
be
in
in
agreement
with
this,
and
this
is
labeled
as
like
a
blocking
issue.
So
I'm
not
sure
if
you
have
a
little
more
contacts,
I
understand
well,
that's
not
so
great
or
have
opinions
on
it
in
general,.
A
I
don't
know
if
I
have
like,
like
dan
coming
from
perspective
as
someone
who's
like
working
through
understanding
this-
I
don't
know
if
I'm
in
the
best
position
to
provide
like
for
or
against
judgment,
but
I
have
been
working
against
that
right
now,
where
it's
like.
When
you're
registering
a
metric
reader,
you
need
to
have
some
place
to
store
these.
These
values
right
like
whether
using
the
delta
or
cumulative
value,
but
it's
not
something
that
necessarily
belongs
to
the
metric
reader.
A
So
it
does
feel
a
little
bit
awkward
like
compared
to
again
when
we're
doing
like
the
tracing
api
and
working
with
it,
there's
very
a
clear,
a
clear
flow
of
data
through
the
system
right,
you
register
your
tracer
provider
or
your
tracer.
It
emits
spans.
A
It
goes
through
all
of
your
span,
processors,
if
you
have
many
and
it
flows
down
through
to
your
your
exporter,
whereas
in
this
is
you
have
this
kind
of
like
I
like
this
medium,
I
think
of
like
the
spider-man,
pointing
at
spider-man,
because,
like
it's
just
pointing
at
each
other,
right
like
it
has
to
go
through
those
two
directions
and
it
it
has
been
a
bit
awkward
to
implement.
A
But
again,
like
I'm,
not
a
position
where
I'm
gonna
be
overly
critical
of
this,
because,
like
at
some
point,
you
need
this
shared
place
to
store
all
this
information
and
they
have
to
be
aware
of
each
other
unless
you
want
to
train
change
the
structure
where
the
metric
reader
owns
this
in-memory
state
and
you
push
it
further
down.
I
don't
know
when
I
first
read
it
like:
that's,
actually
how
I
understood
it
and
you
wouldn't
have
the
same
bi-directionality
of
it.
It
would
be
closer
to
the
tracing
spec.
C
Cool
yeah,
it
looks
like
this
was
opened,
you
know
in
the
fall,
and
there
was
a
little
bit
of
discussion
on
it
and
I
think
the
reason
why
this
is
coming
back
up
is
they
want
to
move
move
the
metrics
sdk
spec
to
mixed.
So
I
think
that's
some
newer
level
of
maturity,
but
josh
surath
mentioned
this
issue
and
wanted
to
have
some
kind
of
resolution
to
this
before
moving
it
yeah
before
changing
the
status
of
the
metric
spec.
C
C
C
Yeah,
let
me
just
see
if
there
was
anything
else
that
should
probably
be
summarized
that's
the
only
other
thing
that
I
would
summarize
is.
This
has
happened.
We
talked
about
this.
We've
talked
about
this
at
length
about
why
instrumentation
libraries
move
to
instrumentation
scope,
but
this
is
actually
the
proto
changes
that
make
this
change.
It's
worth,
noting
that
this
breaks.
C
This
this
is
fine
for
protobuf,
but
it
does
break
otlp
json
for
for
any
vendor.
C
F
Are
you
in
this
vote
rob
no?
No,
it's
fool's
errand
to
try
and
chase
this
json
spec.
So
we
have
punt
it
on
like
we.
You
can
do
grpc,
protobuf
or
protobuf
over
http,
but
not
as
json.
C
C
F
Enough
about
our
pain
we
did
we
did
in
when
we
were
split
brain
meeting.
We
did
make
a
very
lightweight
issue
for
this,
so
there's
a
new
issue
on
our
issue
backlog.
To
do
this,
update
to
the
sdk.
A
F
A
For
just
like
on
that,
one
for
the
the
ruby
side
of
things
like
I
do
have
that
on
my
or
like
the
shop
of
my
internal
to-do
list
or
like
my
own
to-do
list,
I
need
to
push
it
up
to
like
the
team.
So,
like
I
figure
myself
or
someone
from
our
team
will
probably
own
the
update
for
that
on
hotel
ruby.
At
least
I
had
something
about
we,
when
you
did
the
first
talk
over
the
metrics
api.
I
just
dropped
it
in
the
chat
there.
A
There
is
a
nice
change
to
the
stable
metrics
api.
It
we
just
tested
it
a
little
bit
at
length
there
like
the
behavior
of
having
an
error.
If
you
try
to
create
an
instrument
with
the
same
name,
that's
no
longer
the
case.
So,
even
though
the
api
is
not
stable
and
will
require
some
changes,
they're
small
changes
and
I
think
they're
in
the
right
direction,
there's
a
bunch
of
like
asterixes
and
catches
around
this,
where
you
can
break
your
data
stream.
A
If
you
like,
create
the
same
instrument
under
the
same
meter
with
the
same
name,
because
now
you
are
potentially
emitting
different
data
under
the
same
name
and
like
that
might
be
bad
blah,
blah
blah,
but
at
least
it's
not
the
exploding
behavior
that
we
or
I
expressed
concern
around.
So
I
didn't
notice.
I,
like
I
didn't
catch
that
issue
until
after
it
was
merged,
but
it's
nice
to
see
it.
C
Cool
yes,
thanks
for
bringing
that
up,
this
was
this
was
something
that
at
least
brought
up
in
some
of
these
spec
sig
recaps,
but
it
is
a
long
one
so
having
that
buried
in
there,
it's
a
pleasant
surprise,
I
guess
hopefully,
other
pleasant
surprises
have
made
their
way
in,
because
there's
quite
a
few
things
that
this
was
addressing.
A
Yeah
yeah,
just
that
one
bit
like
I
haven't
reread
that
whole
thing
I
need
to.
I
think
you
did
go
over
it,
but
I
was
admittedly
distracted,
probably
when
it
happened,
because
I
completely
missed
this
vr,
but
that
section
yes,
is
very
welcomed.
In
my
mind:
it's
it's.
I
don't
know.
I
think
it
just
makes
the
adoption
of
it
for
like
us,
like
trump
fights
consumers
potential.
Consumers
of
this
would
be
a
lot
happier
to
have
something
that
doesn't
blow
up
someone's
app
potentially
at
runtime.
C
Yeah,
I
think
I
think
this
was
smoothing
out
like
a
handful
of
rough
edges,
that
people
were
running
into
it
in
the
go
sdk
implementation.
So
some
of
the
things
this
one
we've
already
kind
of
gotten
to
some
of
the
things
might
do
things
a
little
bit
further
off
in
the
future
that
we
would
have
run
into
had.
We
already
been
there,
but
hopefully,
hopefully
this
will
just
kind
of
make
our
our
path
a
little
bit
more
direct
to
getting
a
solid
sdk
implemented.
A
Matt,
I
believe
in
the
past
you
were,
I
don't
know.
If
you
still
are,
do
you
spend
a
bit
of
time
in
open
telemetry,
js
land.
C
I
do
I
was,
I
was
asking
from
there
for
a
while,
but
I
have
recently
started
going
there
again.
I
know
amir
is,
is
is
also
there
a
lot.
He
is
a
maintainer,
so.
A
So
what
what
is
the
states
of
metrics
in
open
telemetry.js?
I
was
the
reason
I
asked
is.
I
was
kind
of
comparing
notes
between
different
language
implementations
and
I
looked
at
python
go
and
js
and
js
is
the
only
one
that
looked
like
the
spec,
which
was
a
little
bit
tricky
because
I'm
trying
to
drive
out
a
bit
of
inspiration
python.
Just
I
don't
know
if
it's
like
made
up
or
abandoned
and
go
is
I
just
I
either
don't
know
how
to
read?
A
Go
or
I
missed
the
part
of
the
spec
that
says
that
there
is
a
collector
as
part
of
it.
So,
like
it's
very
inconsistent,
it
seems,
but
just
seems
similar.
So
I'm
wondering
is
the
js
stuff
somewhat
up
to
date
with
the
spec,
or
is
it
just
that
it
lucked
out
that
way?.
G
I
have
to
be
honest
that
I
mostly
focus
on
tracing
I'm
not
that
up
to
them
with
the
metrics
work.
It's
just
too
much
to
handle.
I
put
all
my
energy
into
pricing,
but
I
know
that
there
are
many
prs
and
a
lot
of
activity
and
we
talk
about
it,
a
lot
in
the
sig
meetings,
so
it
looks
like
people
bring
us
like
issues
and
concerns
and
discuss
them.
There's
a
lot
of
activity
around
it.
A
G
C
China
so
yeah,
like
I
can
say
two
things
about
this-
definitely
go
in
python
and
java,
I
think,
were
kind
of
like
the
original,
or
they
were
the
first
cities
to
kind
of
pick
up
this
like
newer
revision
of
the
spec,
so
I
feel
like
they.
C
They
have
been
iterating
on
on
the
newer
version
of
the
spec,
but
I
believe
this
has
driven
more
changes
in
the
spec.
So
I
feel
like
my
feeling,
is
that
maybe
some
of
these
are
a
little
bit
behind,
because
I've
actually
kind
of
released
some
things
that
people
are
using.
That
are
that
there
have
been
some
revisions
on
top
of.
I
do
feel
like
javascript
has
been
trailing
a
little
bit
and
has
been
and,
as
a
result
might
be
a
little
bit
more
current.
I
know
the
most.
C
The
most
recent
thing
has
been
the
multi-callback
registration
and
I
think
javascript
was
definitely.
This
is
like
a
newer
change
to
spec
that
which
is
recently
merged,
and
I
know
they
were
calling
for
some
languages
to
prototype
this,
and
I
think
javascript
java
and
go
had
some
prototypes.
But
my
guess
is
there
is
like
probably
a
branch
somewhere
for
go
that
has
some
of
the
more
current
stuff,
but
rather
than
like
make
tons
of
conjecture
about
the
state
of
all
these
things.
C
I
will
ask
around
because
I
I
believe
some
folks
at
lightstep
are
pretty
involved
in
the
go
sdk
and
just
kind
of
figure
out
like
where
all
the
current
stuff
is
for
go
and
then
see
see
what
that
comparison
is
with
javascript.
And
if
I
get
some
reasonable
information
as
to
like,
where
which
sdks
are
the
best
to
look
at
for
inspiration,
I'll
kind
of
pass
it
along,
so
that
we're
kind
of
you
know
looking
at
the
right
stuff.
A
Yeah
I'd
appreciate
that,
because
I
I
want
to
make
sure
that
I'm
interpreting
the
spec
correctly
and
obviously
there
is
intention
for
there
to
be
consistency
between
implementations
and
like
so
yeah
I
seeing
the
variety
was
a
little
bit
confusing,
but
again
js
looked
the
most
familiar
to
what
I
was
reading.
So
at
least
I
have
one
place
to
kind
of
lean
into
right
now,
yeah.
A
So
I'm
reading
the
spec
and
I'm
trying
to
piece
it
together
and
then
reading
go,
and
you
know
just
language
differences
and
even
in
the
spec
there's
like
a
very
pointed
line
about
like
don't
use
the
term
aggregator
if
you
like,
unless
you
absolutely
have
to
use
the
term
aggregation.
It's
like,
of
course,
go
has
like
aggregator,
because
they're
trying
to
reserve
the
use
of
that
language
for
some
future
work,
or
something
like
that
and
yeah
just
but
not
even
speaking,
to
like
the
general
structure,
but
even
just
the
language
being
used.
E
I
can
ping
anthony
mirabella
from
aws.
I
know
he's
more
or
less
the
most
active
guy
on
the
go
repo
he's
pretty
friendly.
I
can
see
I
can
ask
him
for,
like
a
you,
know,
tl
eli,
five
of
where
they're
at
with
the
with
the
metric
stuff
it's
pretty
and
if
he
doesn't
respond,
then,
whatever.
A
The
other,
the
other
part
of
it
too,
that
I
should
share,
is
like
for
us
at
shopify,
like
our
main
three
languages.
A
We
have
other
ones
but,
like
the
main
three
is
like
ruby,
javascript
and
go
so
we
do
care,
like
obviously
we're
putting
most
effort
into
ruby,
but
we
do
care
about
the
state
of
those
things,
because
if
we
start
adopting,
one
we'll
likely
want
to
stop
like
start
adopting
it
in
others
as
well
right.
C
So
we
are
nearing
the
last
15
minutes.
Was
there
anything
from
the
other
meeting
from
the
parallel
meeting
that
we
should
cover
that
we
didn't
cover
here
or
I
know
we
have
oh
yeah.
F
We
talked
about
the
I
imagine
you
all
talked
about
it
too.
The
default
propagation
disparity
between
spec
and
the
environment
variables
declared
default,
so
I
think
we're
just
awaiting
somebody
to
make
decisions
about
is
this
is
the
spec
right
and
and
sdk
should
no
op
propagation,
so
you
have
to
opt
into
propagating
and
if
so,
we
just
change
our
default
to
a
blank
string,
I
think,
would
be.
F
The
change
seems
like
it's
a
backwards
breaking
change,
because
then
everybody
who's
currently
depending
on
the
default
propagation
behavior,
would
need
to
set
their
environment
variable
to
get
the
current
propagation.
But.
C
F
So
this
is
the
issue
I
think
opened.
Well,
you
were
at
the
meeting.
I
don't
need
to
read
it
to
you.
Do
you
want
to
tell
us
what
what
the
discussion
was.
C
So
I
believe
the
discussion,
if
I'm
recanting
it
correctly,
is
that
basically,
if
you're
just
running
with
an
api,
you
will
end
up
with
with
no
out
propagators
registered,
but
most
languages
were
saying
like
this
hotel,
propagator's
environment
variable
only
really
comes
into
play
with
an
sdk,
oh
so
then
you
would
pick
up
that
default
and
you
would
end
up
registering
trace
contacts
and
baggage
if
you
have
an
sdk
installed,
so
it
seemed
like
this
was
generally
how
how
all
languages
were
working.
F
C
Yeah
so
I
think
maybe
the
clarification
was
going
to
be
to
kind
of
spell
out
that
this
is
the
way
things
will
work
so
api,
only
you'll
get
no
ops
sdk
by
default.
You'll
get
trace
contacts
and
baggage,
but
I
guess
we'll
keep
an
eye
on
this
one
to
see
what
what
actually
comes
out
of
it.
F
Cool,
that's
that's
more
promising
than
the
conclusion
we
drew
from
the
notes
which
were
just
links
to
the
issue
in
the
pr
so
problem,
probably
nothing.
C
F
F
Quick
version,
I
don't,
I
don't
know
that
the
rails
instrumentation
should
do
auto
config,
where
it
does
the
sdk
configure
and
use
all
for
you
if
it.
If
we
do
opt
to
go
that
route
before
we
merge
it.
I'd
like
to
maybe
explore
some
like
day
two
plus
operations.
When
you
decide
that
this,
isn't
you
don't
want
the
default
behavior?
How
do
you
turn
it
off
and
overwrite
it?
I
have
some
spitball
ideas
about
it.
F
If
you
can
turn
it
off
and
coat,
I
don't
know.
I
have
spitball
ideas
about
it.
A
I
think
the
one
that
is
sticking
with
me
right
now.
The
approach
to
that
is
what
eric
suggested.
I
like
that
the
most
is
it
does
get
included
in
the
rails
instrumentation,
but
it
doesn't
get
required
as
part
of
the
instrumentation.
You
have
to
explicitly
require
the
like
auto
config
in
your
gem
file,
so
it
becomes
very
much
often
behavior,
but
it
is
very
close
to
the
like
no
code.
It's
like
you
you're,
only
really
adding
anything
to
your
gem
file
and
through
just
adding
stuff
to
your
gem
file.
F
F
I
yes,
I
also
I'm
curious
about
how
much
pain
and
for
how
many
people,
the
no
code
desire,
stems
from.
F
F
It
is
a
ruby
and
rail
and
particularly
rails
convention,
to
configure
through
initializers
one
of
the
thing
that
honey
honeycomb
with
its
instrumentation
libraries.
Sorry,
I
have
to
keep
an
eye
on
the
cat,
because
what
it
really
wants
to
knock
stuff
over
it's
currently
a
face
in
the
mug
honeycomb's
instrumentation
library,
for
ruby
opted
to
have
a
generator.
That
would
generate
a
default
initializer
for
you
and
that
would
have
a
sensible
default.
So
you
go,
you
require
the
gem
you
do,
a
rails
generate
honeycomb
or
whatever
we
can
do
rails
generate.
F
Whatever
it's
been
a
long
time
since
I've
written
or
even
run
a
generator
because
legacy
code,
I
don't
make
new
apps,
but
you
have
a
generator
generate
the
initializer.
The
initializer
could
be
the
easy
path,
and
now
you
have
the
scaffolding
for
going
and
tweaking
settings
in
there,
as
opposed
to
like
learning
that
there
are
these
magical
environment
variables
that
you
have
to
set.
But
it's
a
balance
between
like
how
many
people
want
this,
no
code,
behavior
versus
being
cool
with
the
conventions
that
are
in
the
ruby
and
rails
world.
F
Like
is
this.
Is
this
a
desire
from
a
say
java,
where
you
add
the
java
agent
to
your
command
line
and
your
app
is
lit
up,
which
I
would
understand
as
a
convention
in
java,
but.
E
Yeah,
it's
I
mean
I
defer
to.
I
am
no
longer
a
vendor
of
tracing
services,
so
I
kind
of
defer
to
you
and
and
matt
and
amir,
and
you
know
I
wouldn't.
F
Even
I
don't,
I
don't
know
that
it's
a
vendor
issue
so
much
as
we're
writing
libraries
that
that
there.
E
Was
sorry
to
interrupt,
though
you're
right?
It's
it's
just
general
library
issue.
There
was
certainly
a
interest
from
maybe
some
combinations
of
sales
and
marketing,
maybe
some
product
folks,
but
also
customers
at
the
time
when
I
was
involved
in
this,
where
you'd
meet
some
customers
who
were
maybe
coming
from
this
disadmin
or
devops
world
and
all
they
kind
of
had
autonomy
over
was
like
maybe
a
gem
file,
or
maybe
some
nvars.
E
They
didn't
really
have
the
permissions
to
go,
do
app
code
changes
or
like
they
didn't
even
know
ruby
and
like
anything
involving
like
actual
ruby,
like
scared
them,
they
were
just
someone
who
like
got
hired
and
there
was
like
a
legacy
git
lab
instance
and
they're
like
oh.
No.
What
do
I
do
with
this?
So
that's
sort
of
where
the
motivation
for
just
like
I
just
want
to
touch.
E
F
But
then
I
which
I
totally
get
that's
a
pain
point
for
some
people
who
are
going
to
be
using
apps
that
are
instrumented
with
this
library.
So
it's
I
would
I'm
curious
about
having
a
conversation
around
the
considerations
of
what
do
like
day,
zero
I've
added
this
library
to
my
app
and
it's
lit
up
everything
and
day
two.
E
E
I
don't
know
I
don't
have
a
hell
to
down
if
people
greeted
some
consensus
like
fine
not
to
like
fight
people,
if
they
wanted
to
fall-
and
I
would
just
say
like
it
would
just
be
nice
to
have
in
our
repo
so
like,
let's
it
would
be
nice
like
get
something
out
the
door
so
like
people
from
other
aws
stop
like
bugging
us
for
like
to
get
it
added
and-
and
you
know
we
can
just
and
then
we
can
iterate
and
improve
it
if
we
find
so
like
it's.
F
E
F
E
Okay,
let's
I
think
it's
all
valuable
discussion
definitely
feel
free
to
drop
a
comment
on
the
issue
and
I
think.
E
C
This
thing
working
will
be
so,
like
I
don't
know
from
a
veteran
perspective,
it's
really
nice
if
you
could,
just
like
add
a
gem
to
your
jump
file
and
then
everything
just
magically
works
and
every
additional
step
that
you
add
is
one
additional
thing
that
somebody's
going
to
miss
and
it's
just
going
to
end
up
becoming
some
kind
of
back
and
forth
somewhere.
Unless
we
can,
I
feel
like
this
could
be
mitigated
to
some
degree
by
having
some
pretty
comprehensive
guides
that
are
easily
available,
but
yeah.
C
F
And
I
appreciate
that
also
from
vendorland,
but
if
it's
hard
to
turn
off
the
default
behavior
when
they
realize
I've
turned
everything
on,
and
oh
my
god,
please
stop.
How
do
I
stop
this
flood
of
information
if,
if
the
next
step
is
highly
finicky,
things
that
they
have
to
do
to
turn
things
off,
which
is
get
these
environment
variables
exactly
right,
it's
it's
it.
We
run
the
risk
of
deferring
the
complexity
to
after
they've
done
the
easy.
Now
they
don't
understand
how
to
do
the
intermediate
to
hard.
E
I
have
a
heart
stop
at
one.
I
had
a
personal
call
I
got
take.
I
had
there's
one
pr
on
a
slight
change:
star
rails
instrumentation,
that's
interesting!
I
guess
I'm
maintainer
of
instrumentation
stuff,
so
I
replied
basically
wants
to
honor
the
rails.
Filter,
parameter,
filter,
filtered
path
like
option,
which
makes
sense
to
me
generally
a
couple
choices
that
are
opinionated,
which
is
like
one:
it's
not
an
option.
E
It's
just
like
in
there,
which
I
think
is
makes
sense
to
me,
but
again,
kind
of
open
to
other
people's
opinions
and
two
it
slightly
modifies
the
http
target
value
which-
and
I
left
a
comment
just
on
my
code.
E
Trying
to
avoid
calling
set
of
tribute
is
expensive,
but
it
modifies
the
http
target
attribute
which,
according
to
the
spec,
must
be
present
at
span
creation
time
in
order
for
the
sampler
to
use
it,
and
I
wasn't
sure
whether
that
meant
that
there
it
so
it
would
create
a
delta
between
the
thing
that
exists
when
the
sampler
makes
its
choice
and
the
actual
value
you
would
receive
later,
and
I
wasn't
sure
if
that
was
in
violation
of
the
spec.
It's
also
an
experimental
spec
and
was
just
you
know
if
people
have
thoughts,
but.
A
I
think
we
could
we
could
maybe
circle
back
to
this
one
next
week
if
it
hasn't
been
resolved
over
the
pr.
I
agree
with
you.
I
know
you've
got
a
hard
stop
at
one
so,
like
I
don't
want
to
keep
you
the
delta
sampling
like
that
that
change.