►
From YouTube: 2021-02-23 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
Doing
well,
how
are
you,
I
don't
think
I've
actually
been
on
video
much
before
I'm
andrew
from
github.
B
No
worries
I'm
eric
from
datadog
pleasure
to
meet
you
likewise
yeah.
I
think
I
met
some
of
your
colleagues
whose
names
I'm
I'm
really
bad
with
names,
but
some
of
your
colleagues,
people
who
exist.
A
There's
a
few
of
us,
we
all
email
in
from
time
to
time.
I
know
arielle
has
joined
the
call
before
in
the
past.
B
Yeah
yeah
yeah,
it's
cool
to
see
y'all.
You
know
you
guys
are
so
involved
in
rails.
It's
nice
to
see
some
folks
being
interested
in
open
telemetry
as
well.
A
Yeah
trying
to
be
anyways
we're
going
through
the
motions
internally
to
start
trying
to
open
source
some
of
the
stuff
we've
been
doing
and
get
in
a
an
official
fork
of
the
ruby
gems.
So
we
can
start
contributing
back
and
things
like
that.
A
B
C
I
did
this
is
they're
like
acoustic
tiles,.
B
C
If
I
don't
put
something
up,
then
then
everything
sounds
super
echoey
and
what
you
are
not
seeing
is
that
I.
D
D
B
D
D
D
D
Today
was
like
the
day
of
people
bringing
in
documents,
there
are
three
that
people
wrote
up
and
kind
of
presented,
so
one
is
kind
of
around
open,
telemetry,
metrics
and
generally
kind
of
the
plans
and
timeline
around
that.
D
D
D
D
D
D
D
You
know
all
the
pieces
won't
be
in
place
until
next
fall,
but
there
will
be
a
lot
of
pieces
in
place
kind
of
like
spring
to
early
summer,
where
we
can
kind
of
start
building
on
things.
I
think
and
experimenting
with
it
using
it
in
an
experimental.
D
D
All
right,
the
next
document
that
showed
up
was
the
open,
telemetry
metrics
data
model.
D
D
D
But
yeah
everybody
should
probably
read
through
this.
If
you're
interested
in
in
the
current
data
model
issues
and
things
that
they're
doing
to
kind
of
try
to
resolve
them,.
D
D
Basically,
I
think
there
are
four.
D
D
Many
different
scenarios-
many
different
setups-
you
can
kind
of
you-
have
many
extension
points
with
which
to
kind
of
set
up
your
propagation
set
up
your
exporters,
but
that
makes
it
hard
to
get
off
the
ground.
So
I
think
all
cigs
have
done
a
little
bit
to
try
to
make
that
a
little
easier.
D
I
know
things
were
really
hard
in
the
early
days
of
the
ruby
project
and
things
got
a
little
better.
I
think
there's
still
like
a
long
ways
for
things
to
come,
and
I
think
most
like
they're
in
the
in
this
boat,
where
we've
kind
of
taken
some
steps
to
improve
stuff,
but.
D
D
See
if
it
makes
sense
to
have
like
configuration
files,
perhaps
in
addition
to
in
code
and
environment
variable
configuration,
I
see
mention
of
yaml.
E
D
D
Basically,
the
the
desire
is
for
tracing
to
not
crash
your
system
for
your
observability
to
not
crash
your
system
like
under
really
any
circumstances.
So,
while
in
some
situations,
if
we
weren't
writing
observability
software,
the
way
we
want
to
handle
some
things
is
by
like
raising
an
exception
to
alert
the
programmer
that
you
know.
D
This
is
something
that
we
can't
deal
with
interpret
or
fix,
but
for
open,
telemetry,
the
in
most
cases,
what
we
end
up
doing
is
just
trying
to
like
fall
back
to
a
default
or
just
log
log
that
something
went
wrong,
but
because
not
everybody
just
because
it's
it's
not
so
obvious.
When
things
go
wrong,
it's
sometimes
hard
to
figure
out
that
a
something
has
gone
wrong
and
be
like
what
it
is.
D
So
we
would
like
better
diagnostics.
D
I
think
a
lot
of
this
is
around
kind
of
like
things
that
fail
at
installation,
time
or
startup
time,
but
I
think
just
in
general
like-
and
I
think
the
one
thing
that
ted
was
saying
is
just
like
having
like
a
standard
way
to
if
somebody
is
having
trouble
with
their
open,
telemetry
setup.
D
Ideally,
there's
like
a
command
that
you
can
run
or
like
a
environment,
variable
that
you
can
set
to
like
output,
a
bunch
of
stuff
that
you
could
cut
and
paste
into
like
slack
or
getter,
and
somebody
can
start
helping
you
with
it.
So
just
kind
of
having
things
together
enough
where
there
is
some
process
like
that
to.
D
Setup,
the
next
thing
is
convenience
apis,
so
kind
of
the
api
that
we
have
specified
is
it's
kind
of
like
the
bare
bones
tracing
api.
It
can
be
a
little
verbose
sometimes,
but
it
it
has
everything
that
you
need.
D
It's
everything
that
you
need
most
instrumentation
authors
will
find
it
to
be
pretty
sufficient,
but
for
like
higher
level
users,
they
might
want
things
that
are
a
little
more
high
level,
things
that
do
not
require
quite
so
much
knowledge
of
how
things
are
working
underneath
and
are
just
easier
to
use.
So.
D
I
think
languages
will
start
adding
convenience
methods.
He
was
saying
that
you
know
these
don't
necessarily
have
to
be
like
standardized
between
the
different
languages,
because
there
are
going
to
be
like
different
idioms
and
different
things
that
you're
going
to
want
to
do
like
in
java.
This
might
take
form
of
like
having
some
annotations,
so
that
would
be
something
that
wouldn't
really
apply
to
ruby.
D
D
But
there
may
be
other
things
that
that
pop
up
either
from
like
user
feedback
or
that
we
see
other
sigs
kind
of
adding.
That
might
be
interesting
to
add.
D
And
then
I
think
the
fourth
main
item
here
was
just
instrumentation
like
we
have
tracing
stable.
Instrumentation
is
not
technically
stable
yet
so
I
think
you
know
there's
kind
of
really
a
couple
main
ideas
behind
this
instrumentation
task.
One
is,
I
want
us
to
actually
fill
out
like
our
instrumentation,
offering
like
we've
been
we've
been
gradually
adding
to
that
over
time
and
it's
been
getting
better,
but
it's
probably
not
yet
on
par
with
like
what
day
the
dog
offers,
for
example.
D
So
I
think
that
would
be
like
a
long-term
goal
is
to
have
some
some
level
of
parity
at
least
like
in
in
coverage,
and
then
I
think
the
other
thing
we've
kind
of
talked
about
a
little
bit
before
it's
just
like
some
kind
of
standardization
around.
D
How
different
types
of
libraries
are
are
instrumented
and
you
know
what
things
what
thing
belong
belong
as
fans.
What
things
might
belong
as
events
like
what
happens
in
interesting
situations
where
you
might
have
spans
nesting?
I
think
we've
talked
about
kind
of
how
these
clients
fans
can
tend
to
want
to
nest
depending
on.
D
D
Technically,
experimental,
meaning
that
all
the
all
the
telemetry
could
change
coming
out
of
it
like
the
the
attributes,
could
change
the
exact
spans
that
are
created
the
span
names.
D
D
Trying
to
have
implementations
from
other
languages
that
kind
of
bind
to
the
c
plus
plus
implementation,
so
you
could
have
like
a
a
ruby
implementation
that
that's
built
on
top
of
of
ac
plus
plus
implementation,
for
example.
D
So
this
is
a
huge
list
of
things
reading
through
it,
yeah
speaking
of
which
I've
been
talking
a
lot
and
saying
a
lot
of
words.
Does
anybody
have
have
anything
they'd
like
to
chime
in
with
questions
commentary.
B
I
mean
I
don't
want
to
turn
the
whole
meeting.
I
think
it's
an
important
document
and
which
we
could
spend
the
rest
of
the
day,
probably
getting
nowhere
on
discussing
with
a
lot
of
valid
points
being
said,
and
it's
a
massive
amount
of
work,
especially
as
you
dive
into
the
instrumentation
and
really
like
performance
too.
I
think
it's
just
like
be
careful
with
setting.
You
know,
you
know,
like
yeah,
you're
you've
increased
the
the
latency
of
an
app.
B
That
does
nothing,
but
you
know
it's
like
hard
to
like
what
are
you
benchmarking
yourself
to
so
all
that
stuff
would
be
interesting.
I
did
give
a
really
good.
I
think
I
gave
a
community
today
presentation
on
trying
to
true
up
instrumentation
configurability,
which
I
think
has
relevance
here
I'll
try
to
comment
on
this.
I
think
it
would
be
really
nice
to
see
some
of
especially
like
the
client
and
server
instrumentations
have
some
similar
configuration
options
around
like
hooks
and
things
like
that
and
then
with
troubleshooting.
B
I
think
for
us
it
would
be
nice
to
maybe,
like
maybe
we
put
in
the
slack
channel
thing
like
hey
grab
these
four
things.
Every
time
you
ask
a
question
like
dude:
what's
your
collector
config?
What's
your
application
version
in
library
and
config
like
do
you
have
debug
logging
setup
like
a
nice
little
checklist
might
be
just
save
us
a
lot
of
trouble
yeah
one.
E
Thing,
I
think,
yeah
sorry,
I
think
it'd
be
nice
if
we
had
something
that
actually
dumped
out
all
the
bits
of
configuration
that
apply
to
the
sdk,
you
know
what
are:
what's
all
the?
What
propagators
do
you
have
set
up
in
kind
of
a
human
readable
format?
So
what
are
your
propagators?
What's
your
exporter,
look
like!
E
What's
your
spam
processor,
look
like
what
instrumentation
do
you
have
installed
and
what
the
configuration
options
set
for
for
that
and,
ideally
having
a
single
command
that
would
just
grab
all
that,
so
you
can
paste
it
whether
it's
into
a
github
issue
or
whatever
sorry,
I
didn't
want
to
cut
you
off
but
like
rather
than
sort
of
a
set
of
four
commands.
If
there's
just
one
that
we
can
grab
everything
and
paste
it
that'd
be
that'd,
be
helpful.
B
Yeah,
I
agree:
I'm
gonna
drop
in
the
chat.
We
have
a
diagnostic
logger
in
the
datadog
tracer,
which
is
actually
a
subject
of
much
anger
because
it
doesn't
it's
just
logs
regard
it
logs
it
logs
automatically
as
an
info
log
and
every
three
to
five
days.
There's
like
some
random
user
who's
like
my
logs,
are
polluted
you
I
have
not.
You
know,
like
you've,
violated
your
trust
with
me.
It's
like
a
just
like
a
json
string,
but
yeah.
Occasionally,
someone
gets
very
upset
about.
B
It
might
be
overkill
because
it
is
a
little
bit
like
it's
super
loud,
for
you
know
a
third-party
library,
but
maybe
having
something
like
this
behind
a
to
start
an
environment
variable
or
something
would
be
a
an
easy
way
to,
but
yeah
I'm
I'm
like
a
far
I'm.
I
I'm
a
big
fan
of
this.
I
think
it
helps
reduce
debug
investigations.
A
lot.
E
Yeah,
I
think
the
other
approach
is,
as
I
say,
something
that
would
just
dump
out
the
configuration,
even
if
that's
something
that
you
can
run
like
after
the
startup
that
would
just
dump
it
to
your
logs.
So
you've
just
got
a
single
blob
of
thing,
like
single
blob
of
information
that
you
can
cut
and
paste
somewhere.
E
The
other
thing
that
we've
noticed
in
some
of
the
errors
that
are
being
reported
or
some
of
the
problems
that
are
being
reported
is
that
they
relate
to
instrument
like
other
things,
that
are
patching
the
same
things
that
we
are
in
our
instrumentation.
So
prometheus
exporter
is
the
main
offender
here,
but
in
general
I
think,
there's
going
to
be
things
that
are
in
the
environment
and
I'm
not
entirely
sure
how
to
capture
that.
E
B
Yeah,
I
mean,
I
think
you
do
like
for
contacts
at
datadog.
We
ask
for
things
like
gemfile
or
you
know.
If
it's
k8cad's
manifest
the
trick,
there
is
like
there's
super
there's,
often
pii
in
there
or
sensitive
information,
and
so
we're
using
us.
You
know
we
have
them,
send
it
through
zendesk
or
whatever
are
secure.
You
know,
and
if
the
file
like
see
the
certain
size
of
this
whole,
like
you
have
to
upload
it
via
this
thing.
B
So
it's
like,
I
don't
know
how
that
works
in
slack
or
whatever
might
be
something
eventually
and-
and
you
know,
the
the
risk
of
people
just
dropping
their
api
keys
and
slack
is,
like
surprisingly,
not
zero,
but
so
worth
it
yeah.
So
we're
thinking
about
yeah,
I
think
we're
all
on
the
same
page.
I
don't
know,
I
guess
what
the
next
steps
would
be.
I
should
comment
on
this
document
to
you
know
actually
do
anything
besides.
Just
like
shooting
agrees
with
you,
you
all.
E
Yeah
environment
variables
also
influence
a
bunch
of
what
we
do
so
capturing.
That
would
be
helpful,
but
then
also
has
the
same
risk
of
pii
or
other
information
that
should
not
be
shared.
D
Yeah
so
on
on
this
note,
like
I
know,
we
have
an
issue
about
making
some
improvements
to
the
configurator,
and
I
was
just
kind
of
thinking.
I
think,
as
we
were
discussing
that,
like
dumping
out
the
config,
I
feel
like
it's
a
little
bit
hard.
The
way
that
stuff
is
currently
designed.
It's
like,
I
don't
know
the
config
really
isn't
modeled.
We
don't
have
a
thing
that
models
like
here
are
the
options
and
robert
added
some
stuff
with
the
options
right.
Well,
that's
that's!
D
Maybe
where
I
was
going
with
this
little
bit,
I
think
for
for
instrumentation.
He
added
this
stuff
with
the
options
and
it's
actually
pretty
nice
and
like
we
started
off
with
this
configurator.
I
introduced
that
and
we
didn't
really
have
a
great
way
to
model
the
config.
So
it
was
just
kind
of
like
this
layer
that
would
kind
of
glue
things
together.
D
It
would,
you
know,
basically
wire
up
the
the
proper
things
in
the
proper
place
for
open
telemetry,
but
it
gives
you
kind
of
this
one
standard
way
to
provide
all
the
information,
and
I
was
kind
of
thinking
that
it
would
be
nice
to
model
the
config
a
little
bit
more
and
maybe
use
something
like
what
robert
has
introduced
for
instrumentation
just
for
general
sdk
config.
D
E
E
I'm
not
sure
how
much
you're
going
to
be
able
to
encapsulate
that
all
in
one
configuration
spot
like
one
configuration
object,
we
may
want
to
define
additional
api,
for
example,
for
the
exporter
that
would
dump
its
configuration
in
a
json
format
so
that
you
can
just
iterate
of
like
all
the
span
processes
and
dump
out
their
information,
plus
the
exporters
that
are
at
the
end
of
that
processor
chain.
Yeah.
D
D
I
agree,
I
think
that's
one
of
the
reasons
why
configuration
ends
up
being
a
little
bit
tough
for
open
telemetry.
Is
that
like
it
is
very
flexible,
so
you
don't
really
know
what
you
can
expect
in
the
export
pipeline
or
even
if
it's
your
thing,
that's
there,
because
there
are
so
many
extension
points.
So.
E
Yeah,
like
for
for
our
use,
we've
had
to
wrap
span
processes,
so
we
have
the
batch
span
processor,
but
we
have
like
another
couple
of
span
processes
in
the
way
and
if
you
were
just
going
to
try
to
extract
information
automatically,
you
probably
wouldn't
see
the
spam,
the
batchman
processor
and
wouldn't
know
what
to
do
with
the
span
process
that
we
have,
which
is
kind
of
why?
If
we
can
define
an
api
for
gathering
the
diagnostics,
it
would
be
helpful
and
would
probably
be
helpful
to
do
that
at
a
spec
level.
D
Yeah,
that
sounds
good,
and
I
think
the
other
thing
that
stuck
out
that
eric
brought
up
that,
I
think,
is
a
really
good
idea
is.
D
I
see
like
each
sig
kind
of
taking
its
own
approach
to,
like,
I
don't
know,
adding
like
anything
like
allow
deny
lists
to
like
http
instrumentation
for
for
various
things,
for,
like
traces
requests,
don't
trace
this
request.
Propagate
contacts,
don't
propagate
context,
whatever
those
things
would
be
like
super
useful
to
kind
of
have
a.
D
Some
kind
of
standardization,
I
think,
between
different
cigs,
on
how
that
should
work
and
what
they
should
be
called
because
as
it
currently
stands,
it's
like
you
know
some
cigs
offer
these
things,
some
don't
some
instrumentations
do
some
don't
and
you
just
kind
of
have
to
usually
do
a
lot
of
reading
to
figure
out
a
lot
of
reading,
often
down
to
the
source,
to
figure
out
if,
if
this
thing
exists
or
not,
and
how
to
use
it
so.
B
Yeah
for
what
it's
worth,
oh
for
context,
a
lot
of
the
integrations
or
instrumentations
on
which
maybe
some
sigs
have
based
their
own.
The
datadog
stuff
was
not
written
with
as
much
intention
as
maybe
people
think
and
and
also
especially
when
it
comes
to
generating
numbers
of
spans
at
the
time.
B
Datadog
wasn't
charging
for
ingest
of
tracing
data,
and
so
there's
really
no
regard
given
to
like
here's,
a
million
spans
hope
hope
you
don't
charge
on
ingest
and
we
and
we
actually
started
doing
that
recently
and
people
are
not
super
happy
because
it
turns
out
some
instrumentations
are
very
expensive,
so
it
might
be
nice
at
a
sig
or
spec
level
to
have
some
like
thought
or
statement
around
like
don't
don't
make
spans
for
no
reason
sort
of
thing.
So
that's
another
thing.
I
should
write
on
that
doc.
E
All
interestingly,
some
questions
that
we've
had
internally
at
shopify
about
this
have
been
what
is
the
overhead
of
tracing
and
is
it
okay
to
add
it's
kind
of
like
people
asking
for
permission
to
trace
their
stuff
to
add
spans,
and
you
know
I've
given
guidelines
around
that.
E
But
we
have
this
tremendous
spectrum
of
people
who
people
who
are
very
reticent
to
add
any
spans
because
they
think
it's
going
to
be
expensive
and
then,
at
the
other
end
of
the
spectrum
we
have
people
who
use
meta
programming
to
attach
to
basically
wrap
every
method
of
a
controller
or
some
random
class
in
a
span
right.
E
B
Yeah
yeah,
it's
good.
This
document's
being,
I
think
it's
important
for
it's
nice
to
see
a
document,
that's
more
than
just
let's
push
for
ga
and
let's
cut
scope
or
whatever,
and
I
think
these
are
important
questions
that
need
to
be
answered.
You
know
and
it's
about
whether
we
it
gets
done,
kicking
and
screaming
or
proactively.
E
D
Yeah,
so
I
guess
just
to
round
this
all
out,
we'd
probably
talk
about
it
forever.
We
should
probably
move
on.
C
D
No,
no!
No.
I
I
think
this
has
been
useful
and
it's
good
to
see
the
ideas
and
kind
of
interest
in
this
in
this
topic,
but
I
think
I
think
we
spent
like
a
lot
of
time
just
like
getting
getting
the
bare
bones
api
out
there
and
deciding
on
it,
and
this
is
kind
of
like
the
next
step
is
really
like
refining
and
making
this
stuff
a
lot.
A
lot
nicer
to
use-
and
I
think
you
know
that's
an
important
and
critical
step.
D
But
you
know
what
we
have
been
working
on-
has
been
kind
of
a
prerequisite
for
that,
so
so
yeah
this
stuff
will
will
continue
and
any
ideas
that
people
have,
I
think,
definitely
make
them
known.
Make
issues
kind
of,
as
as
topics
as
time
goes
on.
E
Yeah
one
thing
that
occurs
to
me
is
that
a
lot
of
the
semantic
conventions
are
written.
As
you
know,
this
is
like
a
table
of
you
know
this
tag.
These
are
the
values
and
is
it
required
or
not,
and
the
underlying
assumption
is
that
if
it's,
if
it's
not
required,
it's
still
a
nice
to
have
so
it's
more
like
you
know
required.
Yes,
is
stuff
that
you
absolutely
your
instrumentation,
absolutely
must
capture
and
required.
No
is
still
provide
it
if
you
can
possibly
get
it
from
whatever.
E
The
thing
is
that
you're
instrumenting
and
one
of
the
bits
of
feedback
that
I've
gotten
from
some
people
is
that
when
they
look
at
spans
generated
from
some
of
our
instrumentation
there's
a
huge
amount
of
stuff
there,
that
just
seems
irrelevant
or
repetitive.
E
But
if
you
look
at
the
semantic
convention,
systematic
convention
said
you
know,
you
should
probably
try
to
capture
that,
if
you
possibly
can.
So
I
wonder
if
we
want
some
kind
of
refinement
around
that,
where
things
that
are
not
required
are
optional
and
the
instrumentation
should
have
configuration
options
to
say
I
you
know.
Yes,
I
want
that
or
no
I
don't
and
then
we
need
to
make
a
decision
about
whether
to
default
to
having
it
or
defaulted,
not
having
it.
E
D
Yeah,
I
think,
that's
good
feedback.
I
think
that's
the
sort
of
feedback
that
that
the
community
is
looking
for
from
from
people
who
are
using
this
in
the
real
world.
I
don't
know
what
the
answers
are
to
that.
D
I
think
that
conversation
is
needs
to
be
had
like
my
just
from
hearing
that,
like
my
gut
feeling
is
that
we're
collecting
too
much
and
that
we
should
probably
trim
that
set
down
just
because,
like
the
none
of
this
stuff,
is
free,
like
every
attribute
that
you
collect
every
span
that
you
create
is
just
it
you
know
it
it
takes
from
a
you
know.
D
It
takes
some
resources
that
your
application
could
use
in
theory.
For
the
most
part,
it's
worth
the
trade-off,
but
there
is
a
trade-off
being
made.
I
guess
so.
I
think
that
needs
to
be
recognized.
I
don't
know
what,
like
the
larger
opinion
would
be
on
this.
D
I
could
see
some
people
just
saying:
well,
you
should
just
collect
it
all
and
filter
it
out
with
a
collector
or
something,
but
I
feel
like
that's
not
a
great
approach
just
because
of
the
fact
that
there's,
while
you
can
filter
things
out,
it's
like
you
can't
regain
the
the
performance
loss
from
collecting
it
in
the
first
place
so
like
I
could
see
the
debate
going,
something
like.
D
D
E
I
briefly
wanted
to
mention
in
terms
of
the
in
terms
of
documenting
instrumentation,
I've
added
so
robert
had
created
internally
at
shopify,
a
checklist
of
instrumentation
that
we
want
to
implement
in
order
to
have
parity
with
our
olds
like
legacy
tracing
library.
E
So
I've
created
issues
for
those
things
in
the
open,
telemetry
ruby
project
and
assigned
some
of
them
to
to
robert
just
so
that
we're
tracking
the
things
that
we're
intending
to
implement
and
then
for
all
the
other
instrumentation
issues
that
made
sure
that
they're
tagged
with
instrumentation
and
also
tagged
with
help
wanted
for
for
the
things
where
like
either.
You
know,
google
api,
client
instrumentation
we're
trying
to
guilt
daniel
into
doing
that,
and
then
for
other
things.
E
It's
shopify
is
not
using
those
things,
so
we're
not
intending
to
build
that
instrumentation.
But
we
understand
that
there
are
people
in
the
community
who
do
want
those
things,
whether
it's
for
parity
with
datadog
or
just
because
they're
using
those
things
so
yeah
I've
tried
to
make
sure
things
are
tagged
appropriately.
Also
things
where
we
have
instrumentation.
But
we
know
there
are
some
things
we
want
to
improve
in
it.
I've
made
sure
those
are
tagged
with
enhancement,
so
those
are
the
big
things
we
talked
last
time
about.
E
Creating
this
table
and
francis
was
going
to
go
off
and
and
has
actually,
he
started
working
on
pr
to
improve
the
documentation
around
this.
We
were
talking
about
creating
tables
in
the
readme.
After
looking
at
francis's
pr
and
his
comments
there,
I
think
we're
better
off
just
having
pointers
from
the
readme
to
the
appropriate
things.
The
point
is
to
like
a
query
like
couple
of
query:
sorry,
a
couple
of
github
issue
queries.
So
that's
one
thing
and
then
making
sure
that
all
our
instrumentation
that
we've
implemented
is
in
the
registry.
D
No,
this
all
sounds
good.
I
think
we've
probably
not
been
great
about
getting
stuff
into
the
registry.
Our
registry
is
empty
right
now.
I
think.
C
It's
not
empty,
I
looked,
we
have
we,
someone
put
it
in
there
at
some
point.
Oh.
D
But
yeah
this
backlog
is
looking
really
nice
and
labeled.
Thank
you
for
that.
E
Milestone
yeah:
this
is
our
release.
Candidate
milestone,
so
yeah,
jaeger
propagator
is
a
pin
exporter.
We
have
those
in
progress
right
now
implementing
fields
in
propagator.
That's
on
me.
I
haven't
pushed
up
a
draft
pr
yet,
but
I
should
I
should
do
that
soon.
E
D
So
if
the
injectors
and
extractors
implemented
fields
themselves,
you
could
just
take
like
the
union
of
the
fields
of
your
injectors
and
extractors
and
expose
that
off
of
the
propagator.
D
It
was
kind
of
the
way
I
envisioned
that
happen
happening,
and
you
should
only
need
to
do
that
once
you
know
at
initialization
time
the
fields
should
not
change
so.
E
Right:
okay,
let
me
see
if
I
can
try
to
do
that,
that
should
be
a
little
simpler
than
the
refactoring
that
I
was
doing
so
I'll
I'll.
Try
to
take
that
approach
and
get
a
pr
up
quickly
for
that,
because
that
will
at
least
help
us
get
past
the
rc
milestone.
E
So
if
we
take
the
simpler
approach
here
for
the
rc
just
so
we
can
get
the
checkbox
to
say,
we've
implemented
fields,
then
we
should
do
the
refactor
before
we
do
the
full
release,
which
I
think
I
can
do.
I
think
that's
fine.
I
just
have
some
infrastructure
issues
that
I
need
to
focus
on
for
the
next
week
or
so
that's.
D
Fine
yeah,
so
the
refactor,
just
I
don't
know
it's
on
the
same
page.
I
think
it's
like
right
now.
We've
implemented
injectors
and
extractors
as
their
own
separate
concerns,
and
you
kind
of
like
tie
them
together
into
either
a
a
propagator
that
I
guess
we
have
two
options
for
a
propagator.
We
have
something
called
propagator
that
takes
a
single
injector
and
extractor
and
makes
a
propagator,
and
I
think
what
francis
is
looking
at
doing
is
a
lot
of
these
kind
of
go
together.
D
They
injector
a
single
injector
pairs,
really
well
with
a
single
extractor
in
most
cases,
and
just
call
call
that
a
propagator
that
has
an
injection
extract
method
instead
of
a
propagator
that
takes
an
injector
and
an
extractor
there's
a
composite
version
for
if
you
want
many
of
these
things
so
yeah,
I
think
there.
I
think
there
are
pros
and
cons
to
the
approach,
like
I
think
one
that
I
was
going
to
call
out.
D
That
has
just
come
to
mind
that
I
don't
think
I
called
out
last
time
we're
going
over
the
pros
and
cons
is
that
I
implemented
b3
for
javascript
and
I
actually
was
wishing
for
the
separate
injectors
and
extractors,
mainly
because
I
I
ended
up-
writing
the
spec
stuff
for
b3
and
it
didn't
come
out
the
way
I
wanted
it
or
the
way
I
proposed
it
through
through
negotiations
in
the
spec
process.
D
Basically,
the
thing
that
got
decided
was
that
for
b3,
in
open,
telemetry,
like
the
b3
default
setup
should
be,
should
extract
both
b3
multi
and
b3.
Single
header
there's
two
b3
formats,
but
you
should
inject
the
b3
single
header,
so.
D
For
in
javascript,
they
do
kind
of
have
the
everything
modeled
as
a
propagator.
So
I
just
kind
of
had
had
this
b3
propagator
that
had
that
instantiated,
both
a
b3
multi
and
a
b3
single
and
delegated
to
either
one
or
both
of
those-
and
I
remember
when
I
said
I'm
like
this-
would
be
great
if
I
could
just
wire
up
two
extractors
and
one
injector
and
be
done
with
it,
but
that
I.
E
Think
we
can
support
both.
I
don't
think
it's.
I
don't
think
it's
unreasonable
to
to
support
both
of
those
both
approaches.
E
I
just
think
in
general
it's
both
more
efficient
and
easier
to
implement
a
a
single
propagator
that
does
both
the
inject
and
extract
rather
than
having
it
delegate
to
an
injector
and
an
extractor
in
the
common
case.
I
agree.
B3
is
unusual
and
could
benefit
from
something
that
delegates
to
injector
and
extractor
or
multiple
injectors,
single
extractor,
or
whichever
way
you
do
it
sorry.
D
Yeah
for
the
record,
when
I
was
writing
the
spec
work
or
when
I
was
doing
the
spec
work
on
that,
I
was
trying
to
like
specify
that
we
just
used
the
b3
multi
header
format,
because
that's
like
the
oldest
most
standard
of
them
all
and
it
would
be
easy
just
to
kind
of
default
to
that
for
b3.
But
I
don't
know
people.
E
D
B
E
D
I
mean
all
these
systems
have
evolved
over
time.
I
guess
and
things
that
we've
all
implemented
things
that
we
wish.
We
would
have
done
differently
in
the
past,
but
fortunately
most
of
these
things
aren't
nobody
uses.
So
we
can
change
them,
but
in
the
unfortunate
case
with
zipkin,
where
people
are
still
using
it
like
you
have
to
worry
about
them,.
B
Yeah,
if
I
don't,
I,
I
don't
think
my
for
just
a
segue
real
quick.
I
don't
think
the
exporter
is
ready
for
review,
yet
the
tests
aren't
done
and
I
haven't
even
really
tested
it
against
a
collector
but
should
have
something
in
the
next
day
or
two
for
a
review.
B
The
spec,
I
will
say,
is
just
outright
like
incomplete,
like
they
just
say
it's
incomplete
in
the
specification.
They
say
it's
a
work
in
progress.
Some
there's
been
some
choices
done
in
different
languages
that
don't
necessarily
can
have
conflict
but
are
yeah
there.
There
there's
just
a
lot
of
weird
choices
between
the
go
translation
and
the
javascript
exporter
that
I
tried
to
kind
of
just
pick
the
best
ones,
but
I
definitely
am
curious
what
you
you
all
think
around
some
of
these
choices,
I'll
try
to
highlight
them.
B
When
I
have
a
pr
ready
for
review,
I
also
only
went
with
ht
just
one
of
the
export
formats.
There's
a
number
you
can
do.
I
went
with
just
json
over
http,
because
that
was
easy
anyway,
the
yeah!
That's
all
I
have
on
that.
I
don't.
I
don't
think
it's
worth
anyone's
time
to
review
currently,
although
it
should
work,
I
think.
E
Okay,
a
related
topic,
the
jaeger
exporter.
I
took
a
look
at
like
I
had
this
open
issue
for
a
while
about
jaeger,
spec
compliance
with
a
couple
of
questions,
and
I
took
a
look
at
what
different
cigs
have
done.
The
spec
is
kind
of
weird,
because
it's
the
port
that
it
says
should
be
the
default
is
for
binary
thrift,
but
most
languages
have
implemented
compact
thrift
encoding,
which
targets
a
different
port.
So
the
the
weight
of
implementations
is
actually
a
compact
thrift
on
a
different
port
from
what
the
specs
says.
E
So
I've
kind
of
said
you
know,
most
people
are
using
compact
thrift,
so
we
should
just
keep
using
compact
thrift
and
call
ourselves
compliant
until
this
is
hand
like
yeah,
and
unless
somebody
comes
down
hard
from
the
spec
saying
no,
that
shall
do
binary
thrift.
I
think
this
is
the
way
we
should
go.
B
E
I
don't
remember,
I
know
the
collector
the
way
the
collector
stuff
works.
I
don't
think
you
can
go
back
the
other
way,
but
so
you
couldn't
make
that
compact
thrift,
for
example,
it
has
to
be
binary.
Thrift.
B
E
Yeah,
it
shouldn't
be
dreadful.
The
flip
side
is
binary.
Thrift
is
older
than
compact
thrift
and
less
efficient
and
encoding
less
compact.
As
the
name
suggests,
and
I
believe
binary
thrift
is
just
kind
of
a
almost
deprecated.
E
You
know
backwards
compatible
thing.
It's
not
really
the
thing
that
people
should
be
using
these
days
and
it's
not
the
thing
that
that
jaeger
recommends
either.
E
E
Says
yes,
but
all
the
languages
have
chosen
the
appropriate
port
for
their
implementation,
but
the
spec
currently
says
that
the
default
for
this
environment
variable
should
be
the
one
for
the
for
binary
thrift.
D
B
D
All
right
we
are,
we
are
at
time,
but
it
looks
like
we
have
a
focused
milestone
and
work
work
in
progress,
so
I'll
make
sure
to
get
eyes
on
the
jager
propagator
and
make
sure
also
to
kind
of
keep
at
least
maybe
just
keep
an
eye
on
what's
happening
on
zipkin
just
so
that
we
can
move
this
work
along.
I
guess
and
not
let
it
be
held
up
unnecessarily.
E
I'll
try
to
ping
when
there's
out
of
draft
cool
yeah
smaller
side,
we
should
so
we've
changed
the
documentation
to
point
people
at
github
discussions.
Instead
of
getter,
we
should
close
down
the
getter
channel,
maybe
in
a
week's
time,
and
then
everybody
can
close
that
tab
in
the
browsers.
The
other
thing
we've
done
is
create
a
slack
channel
in
the
cncf
slack.
I
know
like
I
added
daniel
and
eric
there,
because
I
could
find
them
in
cncf
slack,
but
maybe
some
other
folks
want
to
show
up
there
as
well.
E
The
general
discussion
around
slack
channels
for
open
telemetry,
seemed
to
be
that
that
was
probably
the
place
people
would
want.
It
like
new
users
might
want
to
drop
in
with.
You
know,
quick
questions,
and
then
discussions
would
be
used
for
more
as
kind
of
like
discourse,
so
I
don't
know
which
people
prefer,
but
anyway,
that's
that's.
What
we've
set
up
so
far,
let's
see
how
it
evolves.
I
guess.
F
Yeah
here
for
the
product
pitch
for
github
discussions
is
that
for
discoverability
or
I
find
that
github
discussions
might
be
more
useful
for
long
term
only
because
it's
more
of
like
a
stack
overflow
interface,
as
opposed
to
being
in
slack
where
we
might
run
into
a
situation
where
the
retention
limits
are
gonna
chop
off
some
historical
discussion
and
those
discussions
can
also
be
converted
over
to
issues
and
and
so
forth.
So
that
might
be
better
for
the
workflow,
but
I
don't
want
I'm.
I
am
biased,
obviously,.
E
Yeah
yeah
no
worries,
I
I
think
slack
is
effective
for
ephemeral
conversations.
It's
helpful
if
eric
needs
to
tell
us
he's
running
late
for
the
meeting
anything
like
that
right.
So
I
I'm
just
thinking
back
to
like
what
gita
has
been
used
for
in
the
past
and
then
anything
more
long-lasting
has
been
converted
to
an
issue.
I
think
the
model
we're
probably
going
to
take
is
you
know.
Slack
is
for
the
ephemeral
conversations
and
then
github
discussions
is
used
for
longer-lived
things
sounds.
F
Good
is
that
open,
so
you're
saying
that
this
is
open
to
anyone
to
join?
Do
you
have
that
happen
to
have
the
link
to
the
slack
john.
B
B
Anyway,
I
gotta
go,
make
lunch
but
I'll
see
you
all
thanks.