►
From YouTube: 2020-10-06 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
Hi
eric,
how
are
you
hey,
hey
doing?
Well,
how
are
you
doing
doing
great,
so
I
think
that
we
haven't
met
at
any
of
the
previous
six.
So
just
let
me
introduce
myself,
I'm
shamik.
I
work
for
collective
sense.
We're
like
one
of
those
vendors
that
support
open,
telemetry
and
me,
and
my
friend
matt,
have
a
couple
of
questions
on
on
open,
telemetry,
ruby,
client
libraries.
So
we
thought
that
we'll
join
this
meeting
and
see
yeah.
B
You
are
you,
are
you
polish
showback
yeah,
I'm
polish
cool.
I
work
with
a
colleague
of
mine
is
also
named
sean
mack.
B
B
My
family
is
from
bialystok
actually
originally,
but
I'm
american
awesome,
but
anyway
yeah.
We
we're
happy
to
help
nice
to
meet
you
and
nice
to
meet
you
matt,
as
well
with
one
tee,
matt
ware
has
joined
and
some
of
the
other
folks,
I'm
just
an
approver
on
the
project.
A
couple
but
yeah
starts
a
few
minutes
late,
I'm
over
at
a
vendor
as
well.
I'm
a
data
dog
so
can
try
to
assist
generally
the
way
the
meeting
works.
Is
we
sort
of
go
through.
B
C
C
Yeah
so
I
kind
of
stepped
in
midway
through
these
introductions.
I'm
matt,
I'm
a
maintainer
on
the
project,
have
been
here
a
little
while.
A
Pleased
to
meet
you
yeah,
so
in
case
you
you,
because
I
started
like
conversation
earlier
with
eric
I'm
shemek
and
I
work
with
matt
for
a
collective
sense,
where
we're
supporting
open
telemetry
collection
and
we've
seen
great
progress
on
open,
telemetry
ruby
sites.
So
we
have
a
couple
of
things,
quick
questions
that
maybe
we'll
discuss
towards
the
end
of
this
conversion
of
this
segmenting.
C
Oh
great
yeah
there
there
is
a
document
we
can
put
together
and
an
agenda.
C
There
hi.
C
Cool
yeah,
so
it's
like
five
after
I
think
we
should
get
started
in
and
around
here,
so
I'll,
try
to
recap
the
spec
thing
pretty
quickly,
and
then
we
can
move
on
talk
about
things
from
from
our
repo
and
and
yeah
other
issues.
Questions
that
you
all
have.
B
Oh
one
quick
note:
I
did
make
a
pr
in
the
collector
if
anyone
is
interested
in
taking
a
look
at
the
exporter
code
and
is
totally
bored
with
their
lives
more
than
merrier.
I
think
some
of
the
collector
folks
are
reviewing
it
as
well,
but
your
input
is
appreciated
and
welcome.
E
Sure
I
can
take
a
look.
I
actually
just
wrote
an
exporter
for
bigquery
yesterday,
so.
C
C
C
This
morning's
specs
egg
was
largely
centered
around
the
baggage
specification.
Basically.
C
We
have
a
baggage
implementation.
I
think
a
lot
of
languages
do,
but
these
were
kind
of
done
a
while
ago-
and
I
don't
know
if
anybody
actually
wrote
anything
down
about
how
these
should
actually
work,
and
there
is
kind
of
some
differences
between
what
is
in
the
w3c
baggage
spec
and
what
is
supported
by
open
telemetry,
namely.
C
Baggage
is
a
set
of
key
value
pairs.
Well
for
each
one
of
those
keys,
you
can
have
another
set
of
key
value,
pairs
called
properties,
and
we
don't
really
support
these
in
open
telemetry
right
now,
but
there
is
a
chance
that
we
would
support
them
in
the
future
like
if
you
go
back
in
time.
Far
enough,
like
baggage
baggage,
has
a
history,
it
was
at
one
time
called
correlation
context.
C
That
was
its
previous
name,
but
its
previous
previous
name
was
distributed
context
way
back
in
the
beginning
of
open
telemetry,
and
it
had
this
notion
of
metadata
for
each
one
of
these
properties,
and
the
metadata
was
mainly
around
like
how
many
hops
should
a
thing
propagate,
and
did
you
just
want
to
propagate
zero
hops,
which
means
this
this?
These
values
should
only
live
in
process.
Do
you
want
to
propagate
one
hop
and
just
be
to
the
next
request
or
like
infinite
number
of
hops,
but
but
yeah
that
was
all
removed?
C
I
think
it
was.
C
Yeah,
the
question
came
up:
why
was
it
removed
and
nobody
had
a
good
reason
for
that,
but
it
seemed
like
there
is
maybe
some
interest
in
having
that
reintroducing
that
someday.
So
so
the
properties
aren't
useless,
but
we're
not
using
them
now.
So
I
think
they
were
just
going
to
try
to
clear
up
the
spec
around
this
and
I
think
the
general
approach
is
because
baggage
is
kind
of
this
w3c
standard.
It's
like
you
should
whether
or
not
you're
going
to
use
the
metadata
or
properties
in
process.
C
You
should
make
sure
to
propagate
the
ones
that
you
received,
so
you
don't
break
downstream
requests.
So
I
think
that's
that's
the
outcome
of
what
was
a
fairly
long
conversation,
but
I
guess
this
next
one
was
maybe
the
longer
conversation,
and
that
is
that
the
baggage
spec
is
very
odd.
It
requires
a
separate
interaction
with
the
context
for
every
key
value
pair.
C
I
think
the
ruby
implementation
added
two
things
to
it
that
make
this
less
awkward,
but
kind
of
the
debate
is
whether
you
basically
the
the
issue
is
that
your
baggage,
whatever
it
is
in
your
context,
needs
to
be
immutable
so
that,
if
you
are,
if
you
get
a
reference
to
the
baggage-
and
you
start
changing
it,
you
don't
want
it
to
affect
like
the
currently
active
context,
without
some
sort
of
explicit,
I
am
adding
this
value
to
the
baggage,
and
I
now
want
this
to
be
the
active
context.
C
It's
just
kind
of
that
level
of
explicit,
explicit
interaction.
So
that's
kind
of
the
way.
It
is
the
reason
why
it
is
the
way
it
is
so.
For
this
reason
we
have
a
baggage
manager
that
you
can
set
a
value.
You
can
retrieve
a
value
but
to
facilitate
the
the
the
scenario
where
you
want
to
like
add
multiple
values
at
once
or
maybe
add
multiple
values
delete
a
value,
etc.
C
We
do
kind
of
have
this
builder
that
allows
you
to
basically
make
any
number
of
changes
to
your
baggage
and
then
update
the
return,
an
updated
context
with
that
updated
baggage.
So
I
feel
like
that
was
the
thing
that
we
had,
that
maybe
others
didn't
and
for
me
that
smoothed
over
this
weirdness
a
little
bit.
C
So,
ultimately,
I
think
this
guy
john
watson
is
working
through
the
java
implementation
and.
C
Yeah,
I'm
I'm
a
little
unsure
of
what
will
become
of
this.
It
seemed
like
there
was.
Definitely
I
think
this
was
raised
because
they
wanted
baggage
to
be
a
lot
more
like
span.
I
guess
where
you
kind
of
have
this
baggage
object,
that
you
can
interact
with
and.
B
E
C
C
It
seemed
fine
to
me
but
yeah
like
if
anybody
does
use
the
baggage
api
and
comes
up
with
the
opinion
that
this
is
weird
I
would
say
like
the
first
thing
is,
it
is
a
little
weird
because
the
idea
is,
you
need
to
kind
of
make
your
changes
to
your
baggage,
and
then
you
need
to
stick
that
baggage
into
a
context,
and
then
you
need
to
do
something
with
the
context.
I
think
that
is
always
kind
of
the
the
the
flow
for
for
baggage.
C
So
I
think
I
honestly
think
whatever
solution
we
come
up
with
will
be
like
a
little
bit
a
little
bit
like
that,
it's
kind
of
like
I
make
my
changes.
I
commit
my
changes
and
then
I
use
them
somewhere
kind
of
thing,
and
this
is
not
you
know.
This
is
a
workflow
for
some
things,
but
it's
maybe
one
that
people
aren't
used
to
for
for
something
like
this.
C
The
next
topic
was
there's
a
question
around
the
behavior
of
span
dot
end
and
the
question
was:
this
is
recording
flag
on
spans
and
it's
meant
to
be
like
this
performance.
Optimization
where
you
can
check,
is
recording
and,
if,
like
this
recording,
is
false
and
you
can
skip
a
bunch
of
expensive,
potentially
expensive
code.
C
So
this
proposal
was
saying
that
his
recording
should
be
turned
changed
to
false
on
spam.
And
what
did
people
think
about
it?
C
And
I
think
generally,
the
sentiment
was
thumbs
down
just
because
not
that
it's
you
know
not
logically
a
good
thing
to
do,
but
it
kind
of
it
has
an
impact
on
the
performance
optimization
because
of
the
fact
that
this
is
this
is
something
that
will
have
to
be
under
the
protection
of
a
mutex
if
changeable.
C
So
there
would
be
some
more
overhead
in
in
the
synchronization.
C
Right
now,
ruby
we've
been
very
trace
focused,
so
we
probably
haven't
run
up
against
this
this
problem,
but
I
suspect,
when
we
do
run
up
against
it,
we
will
be
confused
and
angered,
but
basically
for
spans.
We
have
attributes-
and
you
know
these
are
key
value
pairs
where
the
keys
are
strings
and
the
values
are
strings,
bools
hints
or
numbers
insert
floating
point
or
arrays
of
those,
and
that's
that's
how
that
works
in
metrics.
They
have
kind
of
the
same
idea.
C
C
E
But
yeah
they
tend
to
be
numeric,
but
the
way
you
slice
and
dice
intends
to
be
by
some
kind
of
string,
value,
string,
key
and
value,
and
I
think
a
lot
of
the
metric
data
formats.
Don't
really
have
a
representation
for
label
values
other
than
strings.
E
They
just
tend
to
assume
that
you're
using
strings
the
like
notionally.
You
could
just
serialize
all
these
things
to
strings,
but
in
practice
I
think
some
of
these
formats
also
have
limitations
on
the
characters
that
are
allowed
in
those
values.
So
you
can't
have
spaces,
probably
can't
have
commas,
and
that
kind
of
thing.
So
what
do
you
do
for
map
values
or
array
values?
E
C
Yeah,
I
think
that
makes
sense
in
general,
I
think
in
in
the
discussion,
people
were
saying
that
it
shouldn't
matter
so
much
at
the
api
level.
What
these
are
that
a
lot
of
this
can
be
handled
in
in
the
export
pipeline,
but
yeah.
E
Some
of
the
handling
in
the
export
pipeline
is
probably
just
drop.
The
label,
which
is
going
to
be
a
shitty
experience
or
you're
just
going
to
log
all
these
errors,
saying
that
you
know
array
valued
things
are
not
supported.
Map
value
things
are
not
supported,
so
the
experience
is
going
to
be
kind
of
crappy.
If
you're
trying
to
say
you
know
the
api
will
support
all
these
things
and
pretend
that
it's
all
like
a
unified
entity,
but
the
exporters
starts
viewing
errors
or
just
silently
dropping
data.
C
Yeah
so,
based
on
this,
you
know
it
sounds
like
it
is
the
way
it
is
kind
of
for
a
reason
and
possibly
a
good
one,
and
that
in
reality,
things
are
just
different
between
metrics
and
spans
so
like
even
if
you
unify
the
api,
there's
still
going
to
be
this
difference
that
happens
later
on,
and
you
will
learn
about
it
when
your
data
gets
dropped
because
one
of
your
attributes
was
kind
of
incompatible
in
some
way.
C
C
C
B
C
C
C
C
There's
kind
of
this
issue
about
how
how
we
should
have
these
interactions
with
the
context
around
like
around
getting
the
current
span
of
the
context
around
setting
a
span
in
a
context
and
yeah.
I
went
over
this
kind
of
at
depth.
I
think
last
week,
where
java
has
kind
of
just
removed
all
this
stuff
from
tracer,
and
it's
on
this
other
kind
of
namespace
tracing
context,
utils
and
that's
how
everything
works
and.
C
Like
our
stuff
is
not
working
this
way,
we
had
a
number
of
methods
on
tracer
that
kind
of
make
this
stuff
nice,
so
I
kind
of
so
I
was
advocating
for
us
being
able
to
keep
what
we
have
in
ruby
and
not
have
to
move
these
things
into
other
name
spaces
and
a
lot
of
these
methods
are
these
tracer
current
span
tracer
current
span
from
some
specific
context.
C
And
then
being
able
to
insert
a
span
into
a
context
and
getting
a
new
contact
for
that
span
inserted
into
it
getting
a
a
new
context
with
a
span
it
into
some
arbitrary
parent
context,
but
kind
of
one
of
the
things
was
one
of
the
arguments
about
kind
of
having
the
current
span,
and
I
guess
our
context
with
span
methods
is
that
these
aren't
really
like
tied
to
an
instance
specifically.
So
why
should
they
be
on
a
trace
or
instance?
C
So
for
this
and
other
reasons
like
it
made
sense
to
for
me,
anyways
to
kind
of
have
these
just
have
a
default
tracer
that
you
can
get
a
handle
on
while
they
can
go
as
class
methods.
I
feel
like
the
problem
is
the
like
the
lookup
path
for
where
you're
going
to
call
these
methods.
It
becomes
very
different,
at
least
in
ruby.
C
C
It's
just
open
telemetry.tracer
method
and
it's
basically
it
delegates
to
tracerprovider.tracer
with
one
slight
variation
in
that.
If
you
don't
pass
a
name,
this
will
give
you
a
name
tracer
named
default.
C
I
realize
I
don't
actually
have
to
safely
navigate
here
by
the
way,
because
our
current
span
always
returns
something
it
might
be
in
invalid
span,
but
that's
fine
but
yeah.
I
think
I
think,
there's
a
little
discussion
here
about
whether
or
not
we
can
name
this
thing
in
default
based
on
the
spec
and,
ultimately,
I
think
all
this
stuff
is
just
like
up
in
the
air,
I
think
they're.
Basically,
the
same
prototype
was
written
in
java
and
I
think
people
are
thinking
about
things.
C
C
C
Happening
so
yeah
at
this
point
yeah,
I
would
like
to
just
open
the
floor
to
to
anyone
and
everyone
for
for
issues
that
you
have
or
kind
of
next.
The
next
thing
we
should
talk
about
sure.
E
Can
we
just
jump
back
to
an
earlier
issue
where
we
talked
about
the
is
recording
after
span
end.
C
E
So
where
has
that
actually
ended
up
right
now
there
seemed
to
be
some
a
little
bit
further
down.
There
seemed
to
be
some
like.
Yes,
it
should,
but
it
could
be
bad
in
terms
of
performance.
E
It's
actually
okay
for
us,
in
the
sense
that
we're
already
I
mean
firstly
like
the
mutex
kind
of
doesn't
matter
in
in
ruby
for
setting
this
particular
flag.
Secondly,
we're
already
taking
a
mutex
during
exit
anyway
right
now,
the
distinction
for
recording
is
like
an
api
span,
is
not
recording,
so
it
always
returns
false,
whereas
a
an
sdk
span
always
returns.
True,
it's
probably
easy
for
us
to
change
that.
True
to
be,
you
know,
not
ended.
E
We
already
have
a
flag
for
whether
it's
ended,
so
I
mean
it's.
It
means
checking
that
thing
is
marginally
less
efficient,
but
we
don't
need
to
take
a
mutex
for
it.
So
for
us
this
is
fine,
but
at
the
same
time
I
don't
want
to
have
significantly
different
behavior
from
what's
in
the
spec.
C
Was
if
if
there
is
recording
flag
value,
can
change?
Do
you
not
need
to
protect
reading
that
flag
under
a
mutex.
E
And
I
think
not
in
ruby
in
some
other
languages,
yes
or
you
would
need
that
flag
to
be
an
atomic
in
ruby,
it's
effectively
an
atomic.
So
this
is
true,
for
would
this
be
true
on
j
ruby
as
well?
It
has
to
be
because,
like
j,
ruby
and
truffle,
ruby
both
need
to
preserve
the
semantics
of
being
able
to
read
member
variables,
atomically
read
and
update
them
atomically.
So,
yes,
this
is
like
implicitly
true
for
those
platforms
as
well.
C
So
ultimately,
it
is
a
performance
optimization.
I
think
that
is
like
the
thing
to
keep
in
mind,
so
that
is
the
benefit
for
for
allowing
this
and.
C
C
E
It
does
flush
and
the
spec
actually
requires
pretty
sure
it
requires
that
after
a
span
is
ended,
operations
have
no
effect,
I
don't
think
they
raise,
but
they
had,
they
have
no
effect,
and
the
issue
is
that.
Well,
I
think
the
larger
issue
is
that
there's
no
way
as
far
as
I
can
tell
right
now,
there's
no
way
to
query
a
span
to
say:
have
you
ended
so
instead
people
want
to
use
like
overload.
E
This
is
recording
flag
right
to
be
able
to
say
you
know
it
was
recording,
but
it's
no
longer
recording
and
is
recording
is
supposed
to
be
the
thing
that
you
use
to
avoid
expensive,
like
instrumentation.
E
So
if
the
span
is
not
recording
you
just
don't
bother
doing
like
computing,
a
bunch
of
tags
or
whatever
it
is
that
you
want
to
do
so.
Yeah,
like
that's
a
rationale
for
doing
it.
Arguably,
if
you
could
query
a
span
to
say,
are
you
ended
that
would
make
this
problem
go
away?
E
You
know
people
could
check
either
like
they
could
check
his
recording
and
his
recording
could
be
constant,
but
if
they
care
about
this
case,
if
you
know
the
span
might
be
ended
at
this
point,
where
I'm
trying
to
access
it,
then
they
could.
Just
query
is
ended.
E
E
We
have
a
bunch
of
cases
so
if
we
add
an
event,
for
example,
to
an
ended
span,
we
end
up
logging,
a
warning
saying
that
you're
calling
an
ad
event
on
an
ended
span,
but
as
far
as
I
can
tell,
we
don't
actually
expose
ended
as
something
you
can
query.
C
Yeah
to
answer
the
question:
I
don't
know
what
other
language
are
going
to
do,
but
I
think
your
points
or
the
things
that
you're
bringing
up
make
this
a
little
bit
more
clear
as
to
like
why.
C
Yeah,
I
don't
know
all
the
reasons
behind
everything
like
why
there
is
an
in
is
ended
flag
for
the
most
part
like
there
has
been
like
great
care
to
make
sure
that
a
span
is
essentially
right
only
from
from
the
api
and
like
there's,
definitely
a
desire
to
make
only
immutable
things
readable,
and
this
is
for
to
facilitate
things
like
streaming,
tracers
and
other
use
cases.
As
soon
as
you
start,
making
things
readable
like
a
lot
of
those
things
become
problematic.
I
guess
so.
C
It's
like
there
are
models
that
kind
of
want
to
be
able
to
treat
like
all
these
span
operations
as
like
a
bunch
of
discrete
events,
and
you
kind
of
think
that
all
of
your,
like
you
know,
set
attribute
ad
event,
and
they
all
end
up
just
like
being
these
events,
that
stream
out
somewhere
and
get
processed
in
order,
and
you
ultimately
arrive
at
having
the
same
span.
E
I
suspect
one
of
the
problems
here
is
that
span
is
actually
an
entity
in
the
api
and
you
can
hold
on
to
a
span
reference
right
in
your
code
and
do
some
arbitrary
thing
with
it
later
on.
It's
usually
like
it's
an
error
to
do
that.
The
common
case
would
be
particularly
now.
We
don't
have
like
spam
context
or
like
we're
talking
about
getting
writer's
man
context.
If
you
want
to
have
something.
E
That's
like
a
parent
of
a
thing
in
another
thread
or
like
you
want
to
start
a
child.
Another
thread
then
passing
the
span.
Reference
around
might
seem
like
an
obvious
way
to
do
that.
But
then
sometimes
people
lose
track
of
the
fact
that
the
span
that
they're
working
on
actually
was
owned
by
the
first
thread
and
has
long
since
ended
so
yeah.
I
think
that's
like
a
programming
error.
I
wonder
how
much
of
that
could
get
hidden
if
you
did
remove
spam
from
the
api
and
you
just
dealt
with
context.
C
C
C
So
yeah,
I
think
I
didn't
want
to
give,
is
it
chamec?
Am
I
saying
that
right
or
mad
with
one
t.
A
Yeah,
that's
perfect!
So
really,
I
think
we
have
a
pretty
short
question,
but
one
that
can
require
a
longer
answer.
But
we've
been
looking
at
various
client
libraries
for
various
programming
languages
and
I've
noticed
that
ruby
one
had
like
a
great
progress,
but
the
the
rhythm
states
that
it's
still
alpha,
st
the
the
status
of
the
of
the
client
library,
is
still
alpha,
which
means
it's
not
being
recommended
for
production
environments
and
I'm
wondering
if
this
still
holds
true.
A
E
So
we
did
a
beta
release
or
a
release
that
we
call
beta.
Certainly
for
metrics
like
metrics,
is
essentially
not
there.
You
can
just
ignore
the
part
of
the
metrics
api,
but
for
the
tracing
api.
We
regard
that
as
beta.
I
would
actually
argue
it's
closer
to
sort
of
it's
close
to
ga,
but
we're
not
going
to
ga
until
the
spec
gas.
So
I
I
think
it's
actually
in
pretty
good
shape.
Right
now,.
E
The
some
of
the
peripheral
things,
so
the
instrumentation
may
not
be
at
the
level
that
everyone's
happy
with,
so
we
are
getting
issues
open
for
problems
either
with
instrumentation
or
with
exporters.
E
D
I
have
I
have
a
question
in
because
I
see
there
are.
There
are
a
bunch
of
of
issues
with
with
instrumentations
to
implement
for
for
some
specific
libraries,
and
where
is
the
community
focus
right
now?
Is
it
focus
on
the
to
make
to
make
the
the
the
open
territory
rugby.
D
How
to
say
that,
as
first
to
implement
open,
telemetry
protocol
specification
inside
or
or
you
want
to
guys
focus
a
little
bit
more
right
now
on
implementation
of
missing
instrumentations.
C
I
think
I
said
that's
a
good
question
and,
like
generally,
like
you
know,
for
ga,
if
you
look
at
ga
requirements,
the
ga
requirements
are
all
just
kind
of
like
sdk
and
api
related,
like
you
could
technically
reach
ga
with
like
zero
instrumentation.
So
like
that's,
that's
a
little
unfortunate
that
that's
how
the
the
project
is
managed.
So,
as
a
result,
we
it
does
seem
like
we
give
a
lot
more
weight
towards
the
apis
and
in
some
ways
that
makes
sense,
because
the
instrumentation
does
depend
on
those.
C
But
I
think,
as
a
group,
we
have
tried
to
sprinkle
in
some
instrumentation,
as
as
it
makes
sense,
and
like
I
don't
know
our
philosophy,
or
at
least
the
thing
that
I
have
regularly
said
is
like
nobody
is
going
to
be
upset
if
a
new
instrumentation
pr
shows
up.
So
if
there
is
something
that
you're
interested
in
or
want
to
work
on
like
do
it
open
a
pr
and
okay
there
yeah
it's
like.
We
have
a
ton
of
issues
there
for
instrumentation.
C
E
Indicated
that
he
was
going
to
pick
that
up
probably
next
week
where
well
he's
actually
focused
on
rolling
out
otlp
internally
at
shopify
this
week
and
yeah
from
next
week.
I
think
he's
planning
to
pick
up
the
rails,
instrumentation
and
start
on
that
and
really
start
small,
so
start
with
a
probably
just
covering
off
the.
E
On
top
of
that,
in
general,
I
would
say,
our
focus
right
now
is
like,
as
a
community
is
trying
to
keep
up
with
the
spec
and
making
sure
we're
on
top
of
any
spec
changes
and
we're
able
to
check
off
all
the
things
in
the
the
table
of
like
implementations
in
the
in
the
specification,
repo,
the
subsequent
focus,
or
at
least
the
focus
for
shopify,
is
getting
this
into
production,
and
for
us
that
means
parity
with
the
instrumentation
that
we
have
for
our
internal
jam.
E
So
we
had
developed
an
internal
tracing
gem
some
years
ago,
there's
a
bunch
of
stuff
we've
instrumented,
because
we
needed
to,
and
we
want
to
make
sure
that
that
stuff
is
all
covered,
whether
it's
sort
of
internally
a
shopify.
So
we
have
a
wrapper
jam
for
open
telemetry
internally,
whether
it's
it's
internal
or
we
do
it
externally.
E
In
some
cases,
we're
developing
it
internally
and
then
porting
it
to
the
the
external
repo.
So
yeah,
like
focus,
is
spec
compliance
and
then
for
shopify
getting
this
into
production.
The
list
of
instrumentation-
that's
here
in
the
repo,
is
actually
taken
from.
I
believe
that
datadog
instrumentation,
so
this
is
not
like
what
shopify
requires.
This
is
actually
what
like
exists
in
the
datadog
repo
that
we
said
we
should
port.
C
I
at
one
point
did
like
create
a
spreadsheet
of
all
these
things
and
look
at
like
rubygem
downloads
to
try
to
prioritize
them
that
hasn't
made
it
over
here,
but
I
think
yeah
I
think
instrumentation
is
definitely
a
focus.
Is,
is
somewhat
of
a
focus
but
yeah.
C
If,
if
there
are
things
out
here
that
you're,
seeing
that
you
are
especially
interested
in,
we
always
welcome
pers,
a
and
b
in
lieu
of
that,
like
it's
always
nice
to
know
what
people
want.
So
you
just
want
to
like
put
a
thumbs
up
on
something
or
just
plus
one
anywhere.
That
also
is
useful.
D
Okay,
cool,
and
so
you
said
that
you
based
mostly
on
what
the
datadog
have
has
so,
if
you,
I
don't
know,
could
rate
in
some
way
or
show
the
differences
between
open,
telemetry,
robbie,
instrumentation
and
data
dog
instrumentation,
let's
say
in
terms
of
manual
instrumentation.
D
Is
it?
Is
it
simple
this
in
the
same
way
in
both
or
is
it
harder
in
somewhere?
And
could
you
please,
you
know
describe
this
in
some
way.
B
Can't
get
much
worse
than
datadog's
manual
instrumentation,
because
I
wrote
it.
No
it's
it's
pretty
similar.
I
would
say
I
I
think
the
hotel
apis
are
better.
They
give
you
some
more
flexibility.
We
might
not
have
there's
some
there's
a
and
I
apologize
for
speaking
over
anyone.
There's
a
translation,
markdown
doc,
nestled
somewhere
in
our
a
repo
that
should
give
you
a
pretty
good
guide
in
terms
of
like
any
examples
you
might
see
in
ddtracerb
what
those
would
look
like
in
an
open,
telemetry
context.
B
I
would
one
feel
free
to
rely
on
that
to
feel
free
to
to
ping
me
in
the
chat
or,
if
there's
some
concept,
that's
confusing,
but
yeah.
I
think
they're
pretty
similar,
some
slight
semantic
differences
and
I
think
open
telemetry
gives
you
a
few
api.
I
think
it's
api
is
a
little
more
robust.
To
be
honest,
it
uses
there's
some
naming
issues
that
might
be
a
little
confusing,
but
things
like
a
resource
and
an
open,
telemetry
context
are
completely
different
than
a
data
dog
context.
B
So
just
be
aware
of
some
of
that,
but
but
yeah
I
would
say
it's
some
similar.
It
takes
some
level
of
effort
to
do
manual
instrumentation,
but
there's
some
nice
helper
functions
around
it.
Does
that
help
at
all?
I
kind
of
sorry
I
heard.
B
F
D
I
was
just
just
wondering
about
the
general
general
overview
and
about
and
about
automatic
instrumentation.
I'm
not
sure
if,
if
there
is
in
data.
B
Yeah
I
mean
it's
the
it's
similar.
We
try
to
improve
it
as
it
gets
ported
over
okay,
a
lot
of
the
data
argumentation.
If
you
look
at
it,
it's
pretty
old,
you
know
it's
it's
stuff
that
was
written
in
you,
know
2017
or
something
and
is
using
class
evals
when
there's
been
better
approaches.
So
if
you
do
want
to
port
any
of
that
stuff
over
certainly
don't
feel
like
you
can't
improve
it.
B
If
you
see
anything,
it's
probably
not
by
design
a
lot
of
the
choices,
it's
just
the
nature
of
enterprise
software
that
you
know
kind
of
sits
around
until
people
bug
you
to
fix
it
so
but
yeah
the
logic
should
be
almost
it
most
stuff
should
be
able
to
translate
pretty
one-to-one.
You
can
see
some
of
the
previous
pr's.
You
can
see
where
the
differences
are,
but
yeah
again
feel
free
to
ask
if
there's
questions
on
a
specific
one.
Okay,.
C
This
is
the
doc.
I
think
that
eric
was
mentioning
the
data
dog
reporting
guide
and,
like
I
had
to
look
over
this
actually
over
the
weekend
and
it's
kind
of
out
of
date.
Actually
a
few
things
have
changed
in
open
telemetry,
so
we
we
could
make
a
pass
through
this
and
update
it.
C
Your
mentioning
of
class
evals
reminded
me
of
you
know
alias
method,
aliasing
methods
versus
module,
prepend,
which
we
had
an
issue
where
you
know
these
things
are
fundamentally
incompatible
if
the
order
is
if
if
the
ordering
is
not
correct,
but
there's
there's
a
big
chance
for
incompatibility
when
you
mix
these,
I
I
forget
which
one
has
to
happen
first,
but
if
you
alias
alias
and
then
prepend,
I
think
you
get
an
infinite
loop.
I
could
have
it
the
other
way
around.
B
C
C
Maybe
we
should
prefer
module
prepend
for
things,
I
guess
and
then
when
people
have
a
problem
with
instrumentation
like
to
be
honest,
the
only
the
only
ones
I've
seen
this
be
problems
with
is
rails
and
I
think
it's
like
maybe
rails
four
or
five,
because
I
think
rails,
five
kind
of
like
ditched
the
whole
alias
method
chain
approach
for
module.
Prepend
like
rails,
definitely
made
a
change,
but
there
are
so
many
other,
like
gems
out
in
the
in
the
wild
that
did
not
make
that
same
change.
E
And
I
think
the
issue
that
was
opened
was
prometheus
related,
I
think
prometheus,
a
lot
of
instrumentation
or
whatever
is
using
the
alias
method
chain
thing
instead
of
prepend
and
where
using
prepend
so
yeah.
B
Sorry
yeah,
I
think,
there's
a
popular
profiling
tool
and
http
sniffer
people
use
that
it
pops
up.
We
get
all
these
reports
about
it.
C
I
don't
know
yeah
that
was
a
bit
of
a
sidebar,
but
maybe
if
we
do
make
a
pass
to
this
document
and
maybe
as
a
future
meeting
item,
we
should
kind
of,
we
should
at
least
have
a
game
plan
around.
What
do
we
expect
from
instrumentation
like?
Are
we
going
to
be
mixing
these
things,
or
should
we
kind
of
standardize
on
something
and
then
how
to
handle
potential
conflicts?
There.
B
Just
to
be
I'm
just
curious,
what
is
like
for
you
guys
at
sumo
logic.
Is
there
something
specific
you're
looking
for
right
now
that
we
should
be
prioritizing
or
that
you
would
help
adoption
if
it
were
prioritized.
D
Yeah,
I
think,
from
my
point
of
view,
it's
it's
about
a
little
bit
more
instrumentation,
so
missing
the
the
libraries
I
would
say
if
I
I
I
I
made
a
say,
a
journey
over
the
open,
telemetry,
instrumentation
languages,
let's
say
and-
and
I
was
looking
to
python
java
et
cetera-
and
there
is
a
bunch
of
of
of
instrumented
libraries
packages
and
in
comparison
to
ravi.
Here
is
it's
not
so
much
yeah,
but
but
I
also
consider
that
the
number
of
contributors
is
is
different.
D
E
I
think
we
also
have
this
open
issue
for
adding
instrumentation
packages
to
the
registry
and,
depending
on
how
you're,
looking
at
this
or
how
people
are
looking
at
this,
it
may
appear
that
we
have
no
instrumentation
when,
in
fact,
we
have-
probably
I
don't
know,
half
a
dozen
things
or
something,
maybe
even
more-
that
are
instrumented
so
yeah,
that's,
probably
something
we
should
fix
sooner
rather
than
later.
C
D
I
also
I'm
I'm,
I
said,
I'm
a
total
noob
in
the
in
the
arabia.
I'm
not
able
to
to
to
judge
how
many,
how
many
libraries
should
be
or
how
many
libraries
are,
are
the
most
common
or
which
and
are
the
most
used
one
on
the
word
yeah.
But
I
was
just
taking
a
look
in
comparison
with
with
other
languages,
cool.
C
Well,
we
are
down
to
the
last
three
minutes,
so
I
feel
like
we
did.
Have
we
have
our
our
beta
v0.7
milestone
looks
like
we
are
43
complete.
C
B
Oh
now
I
do
plan
to
finish
the
graphql
stuff.
I
just
had
been
stuck
doing
some
collector
stuff
internally,
also
mo
so
one
of
my
colleagues
had
had
nudged
me
to
submit
a
cfp
for
the
open
telemetry
community
day.
I
figured
I'd.
Let
other
folks
here
know
that
I
believe
the
open
cfps
are
open
until
the
11th.
If
anyone
has
an
interesting
thing,
sounds
like
they're
looking
for
for
folks.
I
sure
I
don't,
but
that's
never
stopped
me
from
talking
before.
C
B
C
F
I'm
just
going
to
officially
claim
the
the
rails
issue
just
put
my
name
next
to
it,
so
it
doesn't
look
like
it's
not
being
looked
at.
I
started
working
on
it
just
this
past
week,
a
little
bit
and,
like
francis
said,
I'm
gonna
like
try
to
narrow
down
the
focus
to
just
request
like
control
requests
and
splitting
out
looking
at
how
we
might
split
out
some
of
the
rack
stuff.
So
it's
more
reusable,
and
even
if
we
do
go
that
route,
so
I'm
just
pretty
sure
we're
looking
at
that.
C
Awesome
yeah,
I
think
you
will
be
a
hero
and
if,
as
as
you
get
into
this,
if
there
are
other
discrete
bits
of
work
that
you
want
to
kind
of
chunk
out
and
talk
about,
I
think
I
think
it
will
be
easier
to
get
some
participation
if
the
if
the
mountain
of
work
is
broken
down
into
kind
of
some
smaller,
manageable
bits.
C
Right
well,
thanks
for
coming
I'll,
see
you
on
twitter
or
next
week.
Thank
you
very
much.