►
From YouTube: 2021-04-01 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
Hey
look
who
it
is
yeah
glad
to
see
you.
I
missed
you
last
week,
okay,.
A
Yeah
I've
I've
had
some
long
running
maintenance
operations
scheduled
on
thursdays,
the
last
few
weeks
that
the
last
week
it
ran
until
almost
10
p.m.
So
that
was
kind
of
nasty.
B
Yeah,
that's
not
so
great
understandable,
though
yeah.
Well,
I'm
glad
you
could
make
it.
I
remember
this
was
a
hard
time
for
you.
So.
B
Yeah,
so
we
enjoy
having
you
here.
Where
are
we
at
time
wise?
Oh,
it's
like
right
at
one
o'clock.
We
can
definitely
wait
a
little
while,
though
I
don't
have
too
much
on
the
agenda.
Personally
looks
like
brian's
added
one
other
thing
but
yeah.
I
guess
with
that
be
sure
to
add
your
name
to
the
agenda
and
document,
and
if
you
have
anything
you
want
to
talk
about
today,
please
add
us
to
the
agenda
at
the
bottom.
B
B
Hey
look
what
we
have.
I
guess
we
don't
have
any
google
folks,
but
sometimes
they
are
a
little
bit
late.
B
Yeah
no
worries,
let's
see
if
I
can
share
a
screen-
and
I
can
jump
into
this.
Maybe
I
can
give
everyone
back
some
time
afterwards.
B
Cool
awesome,
so
just
to
start
things
off,
we
go
a
little
bit
over
the
project
boards.
I
do
want
to
maybe
just
actually
start
things
off
by
saying
I'm
going
to
be
out
tomorrow.
Not
that
big
a
deal.
I
don't
have
access
to
the
out
of
office
calendar
for
hotel
anymore,
so
just
gonna
post
it
here,
but
maybe
I'll,
maybe
I'll
figure
out
how
to
get
access
to
that
again.
Okay,
cool
going
over
our
project
boards.
B
This
project
board,
which
I
said,
was
going
to
be
completed
by
today.
It's
not
complete,
although
the
day's
not
over.
So
I
I
don't
know
if
I'm
gonna
be
honest
with
that.
One
though
so,
there's
one
more
task
left
and
that's
the
zipkin
exporter
audit.
I
definitely
spent
a
little
time
on
the
eager
one,
it's
kind
of
complex,
which
I
think
is
ripe
for
some
refactor
after
the
release.
B
But
according
to
this
we're
missing
a
few
things,
but
they've
all
been
addressed
and
the
spec
compliance
matrix
are
updated.
So
hopefully
this
week
should
be
well.
I
guess
I'm
out
tomorrow.
So
hopefully
I
can
definitely
not
have
to
talk
about
this.
On
the
next
meeting
is
kind
of
the
goal
here,
but
yeah
looking
pretty
good.
B
That
being
said,
the
main
project
board
that
we
really
need
to
care
about
now
is
the
rc
project
boards,
which
we've
seen
a
lot
of
movement
on
in
the
past
week,
just
a
kind
of
a
delta
right
before
the
meeting
14
issues
down
from
20
something
22.
I
think
that's
how
math
works
last
week
definitely
had
a
lot
of
movement
on
this.
A
lot
of
10
issues
are
completed.
So
a
lot
of
really
good
velocity
at
this.
This
direction,
I'm
a
little
worried.
B
There's
like
we
are
picking
off
the
easy
issues
right
off
the
top,
so
the
remaining
14
become
increasingly
harder.
I
think
as
we
go
along,
so
maybe
don't
expect
this
philosophy
to
persist,
but
I
think
that
this
is
good
nonetheless,
so
yeah
thanks
everyone
for
contributing
definitely
the
aws
intern
board
contributions
are
definitely
appreciated.
So
yeah
thanks
thanks.
B
Cool
awesome,
so
I'm
going
to
just
jump
in
one
of
the
things
that
was
kind
of
talked
about
at
the
open,
telemetry
specification
meeting,
of
course,
was
this
exception
semantics.
We
talked
a
little
bit
about
this
last
week's
meeting
with
the
idea
that
our
record
error
method
currently
records
an
event.
Titled
error
doesn't
title
or
doesn't
have
a
title
exception.
B
That
being
said,
the
kind
of
the
take
away
from
the
spec
meeting,
like
I
think
the
die
hard
hard
thing
we
can't
be
doing
after
we
make
a
release,
is
changing
the
api
for
instrumenters.
So
the
record
error
method
itself,
that's
kind
of
like
it
makes
a
lot
of
sense
like
you.
Don't
really
want
to
break
that
api,
going
forward
social,
something
like
that,
so
that
needs
to
remain
the
same.
B
The
back
end
behavior
is
a
little
bit
more
immutable
and
what
we're
able
to
do
to
support
that
going
forward,
especially
as
it
produces
things
down
the
pipeline.
Ideally,
we
try
to
make
things
backwards
compatible,
but
there
was
you
know
this
idea
that
eventually
one
day
errors
may
become
a
first-class
signal.
So
how
does
this
hook
in?
Does
this
hook
in
like?
Is
that
going
to
be
a
completely
separate
thing,
a
completely
separate
api,
our
you
know,
and
that
kind
of
approach
is
something
that
we
can.
B
We
could,
hopefully,
just
you
know,
keep
exporting
this
event
type
regardless
or
maybe
even
add
an
option.
Saying,
like
you
know,
do
the
new
thing
instead
of
the
old
thing
or
something
like
that.
B
But
we
have
the
record
error
method
set
up
to
accept
the
variatic
arguments
as
the
end
for
the
options,
so
we
leave
ourselves
a
decent
opening
to
try
to
extend
that
in
the
future
and
not
put
us
in
a
quarter,
but
at
the
same
time,
the
idea
here
is:
is
that,
like
we
can
kind
of
jump
in
with
whatever
other
sig
is
doing
and
record
these
methods,
so
that
back
ends
are
going
to
be
able
to
understand
what
the
exception
event
is
and
hopefully
do
something
with
it,
something
useful
that
is
yeah,
so
that
was
kind
of
one
of
the
tricky
wicket
issues,
as
ted
young
would
say
for
rc.
B
B
On
the
call
eric
muslin
here
but
yeah,
it's
a
lot
to
say,
and
I
don't
I
was
gonna-
actually
link
him
to
the
doc
or
to
the
youtube
video
for
the
spec
meeting
this
tuesday.
But
I
it's
not
posted
yet.
So
I
didn't
do
that.
Yet
cool.
B
D
Close
the
loop
on
that
then
1492
is
a
pr
that's
outstanding
for
that
that
has
that
behavior
implemented
it
looks
like
it's
got,
some
conflicts
that
need
to
be
updated
or
has
it
been
updated?
Oh,
it
looks
like.
B
Code
cover
patch:
how
bad
is
that?
Normally
that's
something
that
we
overlook
yeah.
This
might
actually
be
ready
to
merge
right
now,.
B
I
always
see
like
these
two
things.
This
makes
a
lot
of
sense.
I'm
cool
with
merging
this
right
now
he's
gonna.
Second,
that
second
make
it
so
yeah.
That's
a
long
commit
message
cool.
Now
we
are
implementing
our
exception
event.
At
this
point.
B
That's
right.
This
meeting
is
all
about
getting
into
compliance,
cool,
awesome,
so
yeah,
that's!
I
think
we
still
need
to
maybe
update
the
spec
compliance
matrix,
which
probably
should
have
been
done
in
this
issue,
but
I
can
take
that
on
afterwards,
cool
moving
on
brian
you're
up
for
the
split
driver,
question.
C
Hi,
I
am
one
of
the
before
mentioned
amazon
interns
that
are
picking
up
rc
issues,
so
this
was
discussed,
though
I
think
the
underlying
bug
here
is
what
anthony
mentioned
in
his
second
comment
is
that
how
should
the
split
driver
handle
handle
if,
like
a
config,
does
not
have
both
drivers,
because
I
believe
when
the
user
was
trying
to
set
this
up,
it
was
kind
of
incorrect,
but
should
we
panic?
C
If
should
we
panic
if
it's
initialized
incorrectly,
so
one
of
anthony's
suggestion
was
to
return
an
air
instead
and
then
that
gets
handled
or,
I
believe,
log
it?
But
if
you
scroll
up
tyler,
I
think
it.
It
shows
these
first
two
comments
are
the
most
relevant.
D
Yeah,
so
I
think
we
definitely
don't
want
to
panic
right.
That's
that's
the
current
behavior.
That's
no
good!
I
I
think
it's
probably
good
to
have
new
split
driver
return,
an
error,
but
that
means
you
can't
can't
directly
use
it
in
line
with
new
exporter
like
it
is
here
yeah,
but
it's
probably
safer.
C
B
B
Behavior,
if
I
see
I
don't,
I
think
that
that's
a
fine
option
to
return
an
error,
but
I
think
that
like
if
you
return
an
error
and
they're
of
the
opinion
like
well,
I
don't
really
care.
I
didn't
want
to
configure
the
metrics
from
split
driver.
Let's
just
yeah,
I'm
going
to
ignore
that
error
and
just
keep
going.
Is
it
still
going
to
panic.
D
No,
the
other
thing
that
needs
to
be
done
is:
is
that
anywhere
that
the
four
metrics
or
four
traces
driver
is
accessed?
We
need
to
have
a
nil
check
on
it,
just
to
make
sure
that
it's
not
nil.
D
B
Yeah,
I
think,
the
if
you're,
if
we
return
an
error
on
the
creation
here
and
it's
something
that
they
ignore
explicitly,
then
I
feel
like,
I
feel
fine
just
keep
on
ignoring
it
for
him.
You
know
if
it's
nil,
just
keep
go,
just
keep
shooting
and
if
it's
not,
then
yeah,
I
think
it's
up
to
them
to
just
handle
the
error
as
go
kind
of
like
defines
errors.
B
I
think
so,
and
just
do
yeah
just
do
a
nail
check
and
if
it's
you
know
if
it's
nil,
just
return
quick
from
the
function
and
make
it
a
no
op
sounds
good
to
me.
I
would
make
sure
that
the
returned
error
that
you
do
return
from
the
new
split
driver
is
something
that
we
export,
so
external
users
can
check
against
it.
B
E
I
have
a
question
if
we
explicitly
well,
if
we
don't
set
it
to
something
and
then
gets
the
nil
value,
are
we
always
going
to
con
consider
that,
as
a
error
case
like
it
seems
like
that's
just
what
you
know
that
the
default
should
be.
D
So
I
I
think,
because
a
split
driver
is
intended
to
be
able
to
send
metrics
to
one
place
and
traces
to
another,
if
you
don't
specify
one
of
them
you're
using
it
incorrectly,
and
that's
an
error
at
initialization
if
later
on,
that
driver
is
attempting
to
use
two
export
metrics
and
there's
no
driver
for
it.
That
is
what
I
think
we're
saying
we're
just
going
to
silently
ignore,
but
initializing
a
new
split
driver
with
only
one
of
the
signals
having
a
driver
is
a
misconfiguration.
B
Maybe
this
is
something
we
don't
know
yeah.
I
agree
like
we
probably
want
to
make
them
understand
like
this
is
a
returned
error
that
you
probably
should
just
not
be
wrapping
this
essentially.
One
of
the
questions,
though,
is
then
what
happens
when
we
have
like
a
split
driver
that
includes
also
logging
or
some
other
signal
that
we're
going
to
add
in
the
future
that
it
becomes
a
little
bit
more
likely
that
you're
gonna
say
like
well.
I
want
both
traces
and
metrics
to
go
here,
but
I'm
not
gonna
do
logging.
A
Right
well
also,
the
the
initialization
options
are
gonna
be
well.
I
guess
you'd
have
to
write
four
traces
driver
for
logging
driver
and
then
four
metrics,
nil
or
or
whatever
or
whatever
other
one
you'd
want
right.
You'd
have
to
repeat
the
drivers,
because
they're
broken
down
not
by
what
do
you
want
this
driver
to
do
rather
to
do
this
job,
which
driver
should
I
use
and
so
express
that
way,
not
passing
nil
is
basically
saying
don't
handle
that
kind
of
data
at
all
or
drop
that
data.
I
don't
really
know
what
it
means.
B
Yeah,
I
mean,
I
think
I
think
what
we're
saying
here
is
to
just
drop.
The
data
is
how
that
would
be
configured.
Don't
panic,
I
think,
is
that
the
takeaway.
D
D
Drop
the
data
return,
an
error
that
indicates
that
this
may
be
a
misconfiguration,
but
if
the
user
intends
for
that
to
be
the
configuration
they're
free
to
ignore
the
error.
A
I
I
realize
I'm
coming
late
to
this
because
there's
a
whole
discussion
in
the
issue,
but
so
I
think
it's
also
similar
to.
D
D
Right
you,
you
can
make
use
of
what
you
did
get
back
to
the
extent
that
it's
usable
to
you
or
you
can
decide
that
that
error
means
you
need
to
stop.
But
that's
up
to
the
user
at
the
point
that
that
error
is
returned.
A
So,
given
that,
I
think
this
is
maybe
maybe
aaron,
maybe
you
said
this
earlier,
and
it
didn't
quite
click
with
me.
I
think
we
need
to
provide
to
users
a
way
to
discriminate
that
error,
in
other
words,
something
that
satisfies
errors.
Dot
is
whether
it's
a
concrete
error.
We
provide
a
predicate
function.
That's
like
you
know,
is
under
configured
driver
or
something
that
allows
them
to
interrogate
the
error
and
see.
Is
it
this
one
that
I'm
willing
to
ignore.
F
B
A
Time
is
there:
does
there
exist
like
a
a
no
op
driver
or
like
a
dev
null
driver?
Not
current?
I
don't
think
there
currently
is
one,
but
there
certainly
could
be
because
it
seems
like
that.
If
so
it's
it,
it's
presumptuous
to
say
right
now,
but
I'm
just
going
to
say
you
know
we
could
mandate.
We
could
say
all
of
these
need
to
be
populated
use.
You
know
devnull
driver
or
no
op
driver.
If
you
mean
to
drop
the
data,
that's
actually
a
really
good.
B
Point,
that's
actually
a
really
good
point.
So
for
a
few
reasons,
so
let
me
see
if
I
can
just
not
get
ahead
of
myself
here,
but
yeah
the
that
would
be
a
really
good
way
to
like.
Have
it
explicitly
say,
like
I'm
explicitly
saying
like,
I
don't
want
the
logging
signal
once
that
actually
gets
added
like
I
will
make
that
in
go
off,
and
I
think
that's
a
really
good
idea.
B
Another
option
here
is
that,
like
what
we
had
initially
said,
is
just
to
go
into
all
these
methods
and
do
like
a
nil
value
check
right,
but
one
of
the
things
that
pablo,
I
think
is
on
the
call
kind
of
pointed
out
related
to
something
similar
where,
if
we
create
a
span
and
that
span
is
not
recording.
B
Currently
we
return
an
internal
span
type
that
internal
span
type
has
like.
You
know
all
of
the
fields,
all
the
memory
allocation
of
an
internal
span
type
all
of
the
methods
that
are
associated
with
it.
That
could
be
called
right,
but
in
reality,
since
it's
a
non-recording
span
like
we
also
have
this
this
new
thing
that
was
added
like
a
non-recording
span,
which
essentially
just
returns
the
span
context
and
tells
you
that
it's
not
recording
anything
and
then
everything
else
is
a
no-op.
B
There's
not
gonna,
be
a
lot
of
these,
so
it's
not
as
critical
as
like
the
span
type
that
probably
was
kind
of
talking
about,
but
that
could
then
be
doing
all
these
no
op
operations
by
default
instead
of
having
all
these
mill
checks
throughout
all
of
our
methods.
To
do
these,
you
know,
one-off
things
right.
A
Now
sure,
if,
if
we
weren't
already
indirecting
through
an
interface
to
call
in
the
driver,
I
might
I
might
fall
on
the
side
of
you
know,
this
is
a
less
efficient
way
to
go
that
you
know.
Don't
don't
force
method
calls
when
you
can
instead
just
check
if
it's
nil
probably
be
cheaper,
but
if
we're
already
calling
on
methods
than
adding
a
nil
check.
D
Yeah
yeah,
that's
right!
I
think
that
that's
probably
the
way
to
go,
because
if
we
do
ever
add
a
four
logs
attribute
to
the
split
config
here,
that's
a
breaking
change
if
we
don't
handle
it
in
that
manner.
Yes,.
B
A
D
Yeah,
so
I
I
kind
of
really
like
that
solution.
We
treat
a
nil
in
the
split
config
as
construct
a
no-op
driver
for
this
signal
and
then
that
dwap
driver
just
drops
any
export
requests
for
that
signal.
Type
on
the
floor.
B
Yeah,
okay,
actually
yeah-
maybe
anthony
already
got
this,
but
like
that
made
a
lot
of
sense
in
my
mind,
just
saying
that
all
of
a
sudden
like
we'll
you
know
if
in
the
future,
we
do
provide
like
something
with
a
log,
and
you
don't
provide
an
entry
for
one
of
these
things.
The
error
still
makes
sense
at
that
point
right,
because
you
didn't
provide
the
no
op
thing
in
that
in
that
situation,
so
the
error
would
still
be
like
no,
you
need
to
be
configuring
these
properly,
otherwise
so
yeah.
A
D
G
A
Where
I
was
going
rift
yes,
I
agree.
So
this
is
hard
if
they
wrote
their
code.
That
said,
if,
if
new
exporter
returns
an
error,
I
bail
and
then
we
add
logging
and
suddenly,
even
though
the
code
would
behave
the
same
if
they
carried
on
using
the
returned
exporter
now
they
have
an
error
in
their
code
that
I'm
sorry
I
mean
sorry
they
haven't.
D
I
I
wouldn't
say
that
that's
a
breaking
change,
though
right
the
code
will
compile.
There
will
be
a
runtime
deviation
from
expected
behavior.
I
guess
you
could
say,
but
that
also
should
be
detected
very
early
on
right.
If
they're
going
to
have
their
code
stop
and
say,
I
don't
have
a
driver,
I'm
going
to
exit,
they
do
a
test
build
and
it
immediately
fails
right.
They
they're
not
going
to
get
to
production.
Something
like
that.
I
would
hope
not,
if
they're
not
handling
that
error
in
a
way
that
allows
it
to
continue.
A
Or
or
just
related,
this
isn't
odd,
but
I'll
just
throw
it
out
there.
We
could
knock
it
down.
We
could
add
a
field
to
this
to
the
split
config
like
a
boolean
field.
That
says
something
like
you
know,
ignore
unset
or
like
tolerate
dropping
or
whatever.
That
basically
says
like.
I
acknowledge
this
is
partially
specified.
D
Thinking
about
this
more,
I
I
think
that
the
better
approach
might
be
to
drop,
split,
config
entirely
or
not
not
drop
it,
but
abstract
it
away
and
replace
it
with
functional
options
and
allow
the
user
to
say,
use
this
driver
for
traces
use,
this
driver
for
metrics
and
then
behind
the
scenes
we
fill
in
any
of
the
blanks
with
the
noaa
driver.
B
Oh
okay,
so,
instead
of
having
it
take,
this
config
you're
saying
have
the
new
split
driver
take
variatic
arguments
for
this
right
yeah?
That
seems
like
it's
almost
in
line
with
what
we're
doing
everywhere
else.
Anyways
almost.
A
Yeah
yeah,
that
sounds
like
a
good
idea.
It
sends
it
sends
the
caller
on
a
bit
of
a
hunt
to
figure
out
well
what
are
possible
options
here,
but-
and
you
know
it
allows-
calls
to
succeed
that
past
nothing,
but
I
think
it's
safer
for
future
evolution.
D
Yeah,
well
I
mean
it
is
splitting
rather
than
compositing,
but
I
I
see
your
point,
split
kind
of
implies
two
you
make
one
split
and
then
you
have
two
things.
B
Yeah
I
just
I
like
I
like
the
idea
like
in
our
in
our
trace
contact
situation,
where
we
can
build
a
trace,
call
a
composite
propagator
there
or
by
just
bypassing
you
know.
However
many
things
you
want.
I
guess
that's
not
necessarily
the
case
here.
Well,
I
guess
that
is
the
other
thing.
It's
like
what
happens
when
you
pass
two
options
that
are
like
you
know
for
metrics,
specifying
a
metric
driver.
D
B
That
is
true,
and
I
think,
if
that's
probably
the
behavior
we
want
because
well
I
mean
yeah.
I
guess
if
you
wanted
to
send
to
multiple
places,
you
just
set
up
multiple
exporters
at
that
point,
but
yeah
I
okay,
that
makes
sense.
I
I
would
probably
do
that
that
makes
I
probably
wouldn't
call
it
like
composite
then,
because
I
guess
just
ignore
everything.
I'm
saying
yeah.
Okay,
I
like
this
idea
of
just
going
with
the
functional
options,
because
that
also
takes
away
the
idea
of
having
it
return,
an
error.
D
C
Me
brian
does
that
make
sense
to
you.
Yes,
we're
going
to
change
new
split
driver,
whether
or
not
we
change
the
name
is
undecided,
but
it's
going
to
take
variatic
arguments
to
instantiate
it
instead
of
passing
in
the
config
and
not
return
in
air,
because
if
it's
not
defined
we're
going
to
do
the
non-op
driver,
yeah
and.
B
A
A
Okay,
just
ignore
me
on
that
one
yeah
are
we
gonna
say
just
just
because
we're
on
the
idea?
Would
we
export
this
no
op
driver,
or
would
we
just
use
it
as
an
internal
implementation
detail
for
now.
D
C
B
Cool
and
when
you
do
take
notes,
could
you
add
them
to
this
issue
and
be
better
than
anthony
or
myself
in
that
previous
issue?.
G
G
Hey
I've
got
a
question
that
may
be
for
us
if
a
customer
does
want
to
say,
send
metrics
to
new
relic
and
then
to
zipkin.
At
the
same
time,
to
compare,
or
maybe
their
boss
uses
the
zipkin
thing
and
they
want
to
see
their
stuff
in
a
relic.
Is
there
a
way
for
them
to
t?
Is
there
a
t
operator
for
things
like
that.
D
Not
exactly,
but
you
could
register
multiple
exporters,
yes
with
the
metrics
controller
or
the
the
span
processors
so
like
with
with
a
trace.
You
would
register
multiple
span,
processors
that
had
exporters
behind
them.
I'm
actually
not
positive
that
you
can
do
that
with
metrics,
but
I
think
so
yeah.
I
think
you
can
also
have
multiple
metrics
exporters.
B
Yeah,
it's
the
caveat
m
tour
on
that
one,
given
how
prototyping
metrics
is
right
now.
I
definitely
know
that
if
you
try
to
export
otlp
and
prometheus
at
the
same
time,
you're
gonna
have
problems,
there's
a
few
bugs
we've
already
gotten
on
that
one.
But
maybe
it's
working
right
now.
I
think
josh
might
actually
fix
that,
but
yeah,
it's
that's
a
little
bit
hairier,
but
yeah
multiple
traces
should
work.
B
The
span
provider
pathways
like
you
should
be
able
to
register
multiple
spam
providers
to
do
its
own
batching
for
each
exporter,
yeah
and
yeah,
maybe
you're
getting
at
a
point
here.
You
could
have
just
done
this
for
the
otp
as
well
set
102
for
exporter
for
metrics
and
set
another
one
up
for
traces
and
then
registered
them
differently,
but
the
specification
has
made
a
distinction
and
they've
specified
it
this
way.
So
that's
why
we're
going
with
this.
D
Two
yeah,
so
these
are
a
couple
of
issues
that
bogdan
created
that
I
think
are
probably
possibly
mutually
exclusive,
but
I'm
trying
to
look
at
the
part
of
the
span
context
where
the
spec
says
the
trace
flags
will
be
compliant
with
the
w3c
trace
flags
spec,
which
currently
defines
a
byte
that
only
has
as
a
bit
set.
That
only
has
a
sampled
bit
specified.
D
D
So
I
initially
started
looking
at.
Could
we
make
it
a
struct,
which
was
the
suggestion
in
issue
number
two?
I
think
I
don't
think
I'm
really
a
huge
fan
of
that.
That
kind
of
gets
to
the
question
I
have
in
the
next
item
on
the
agenda,
but
I
think
I
have
the
opposite
view
there,
and
we
can
certainly
have
a
struct
that
on
input
and
output
gets
transformed
from
a
byte
to
a
byte
and
and
the
only
external
view
of
it
is
compliant
with
a
w3c
spec.
D
So
I
think
that
the
the
option
I
would
like
to
go
with
is
the
first
one:
removing
those
undefined
trace
flags
having
creating
a
type
four
trace
flags
that
exposes
the
convenience
for
dealing
with
the
flags
that
do
exist
but
remove
the
debug
and
deferred,
and
then
the
question
becomes.
Where
do
we
put
those
do
we
want
to
have
some
ancillary
data
storage
on
span
context
that
propagators
can
use
it's
unspecified.
I
would
be
kind
of
reluctant
to
do
that.
D
We
could
put
them
in
the
context
context
alongside
the
span
context
in
the
propagator
and
expect
that
to
pass
through.
My
only
fear
there
is
it's
possible
that
that
becomes
out
of
sync
with
the
span
context
that
it's
intended
to
go
along
with.
So
I'm
wondering
if
there
are
suggestions
on
how
best
to
handle
that.
B
Yeah,
you
came
up
with
both
the
ideas
that
I
had.
I
went
with
option
one
when
I
initially
did
this
just
because
I
it
seemed
the
easiest
to
kind
of
bundle
it
all
together,
but
there's
conflict.
Now
with
the
specification,
I
think
bogdan's
recommendation
was
option.
Two
where
you
just
you
know,
put
the
deferred
and
put
the
other
flag
into
the
context
context.
B
But
yeah,
like
you,
said
what
happens
when
you
take
that
and
you
you
know,
move
that
out
of
one
context
and
then
use
some
mutation
put
it
into
another
context
like
that
whole
context
may
not
be
used
as
the
parent
at
that
point,
and
so,
like
there's,
there's
a
possibility
that
I
could
get
out
of
sync.
So
I
don't
know
I'm
not
particularly
happy
about
option
two
for
that
exact
reason,
but
I
don't
know
other
ways
to
to
get
around
it
given
it
needs
it
needs
to
shuttle
this
around.
B
It's
unfortunate
because
I
think
the
b3
propagator
wall
may
not
be
the
most
hip
and
current
there's
still
a
whole
large
section
of
the
industry
that
uses
it.
So
I
do
want
to
support
it.
You
know
that's
kind
of.
I
think
that's
a
really
good
idea.
I
know
the
people
over
zipkin
would
be
very
unhappy
if
that
was
not
the
case.
E
Could
we
do
something
where
sorry
I
had
a
thought
of
something
akin
to
what
they
do
with
grpc,
where
we
have
the
unexported
implementation
and
use
that
for
not
quite
stable
exportation?
E
Where,
like
I
know
that
that
has
some
overhead
in
passing
these
around,
but
we
have
like
the
unexported
or
no
no
yeah
an
unexported
method
on
the
interface
that
that
defines
the
got
the
flag,
the
trace
flags
and
then
to
receive
that
information.
The
the
x,
the
is
deferred
or
is
debugged.
You
have
to
like
cast
it
out
and
into
something
that
is
more
modern.
That
has
that
defined.
D
D
I
wonder
if
that
has
the
same
risk
that
putting
it
in
the
context
has,
though,
if
between
a
propagator
extracting
those
flags
putting
them
into
a
trace
context,
something
else
comes
along
and
wants
to
set
say
the
sampled
flag,
but
it
doesn't
know
about
the
information.
That's
that's
carried
in
there
and
it
replaces
that
because
it
has
to
replace
the
trace
flags
and
it
replaces
it
with
a
new.
If
a
new
implementation
that
doesn't
carry
that
data
along
then
that
data
is
lost.
D
Not
if
we
put
it
in
the
in
the
context
in
the
outer
context,
because
then
nothing,
that's
that's
changing
the
span
context
would
be
able
to
affect
that
the
risk
there
would
actually
be
that
a
context
either.
They
replace
the
outer
context
entirely
or
a
context
that
carries
that
information
gets
associated
with
a
span
context
that
shouldn't
that's
kind
of
the
inverse
risk.
I
think.
B
So
I
think
bogdan
said
that
java
does
the
the
second
option,
where
they
just
put
it
as
a
separate
field
in
the
context
context
and
that's
the
way
that
they
do
it.
D
Okay,
I
will
take
a
look
at
what
java
does
and
see
if
there's
anything
that
they
do.
That
looks
like
it
might
try
to
help
with
that,
but
I,
I
think
that's
probably
the
safest
approach,
even
if
it
does
have
some
risk
of
getting
out
of
sync.
It's
certainly
the
the
safest,
with
a
grid
to
spec
compliance
and
keeping
our
options
open
going
forward.
B
I
really
don't
look
forward
to
that
bug
report
when
somebody's
trying
to
debug
something
like
this
but
okay,
yep
cool.
Sorry,
I
can't
come
to
a
better
solution
for
you.
There.
D
Yeah
and
to
the
extent
that
I'm
not
you
know
off
in
the
weeds
or
thinking
about
it
entirely
wrong
yeah,
it's
helpful
that
everybody
else
sees
things
the
same
way.
So,
okay,
the
the
next
one,
was
an
issue
that
initially
marked
as
a
good
first
issue.
We,
I
think
you
were
working
on
this
one
right
yeah,
but
then,
as
we
started
to
dig
into
it,
it
seems
that
there's
a
bit
more
complexity.
D
So
the
these
effects
says
that
tree
state
and
baggage
should
should
operate
on
string,
string
pairs
and
trace
data
and
baggage
currently
take
attributes.
Now
looking
at
trace
state,
it
does
a
whole
lot
of
stuff
to
ensure
that
the
trace
state
stays
conforming
to
the
w3c
spec.
B
Yeah,
I
don't
know
bogdan
said
that
this
is
out
of
compliance
with
the
specification.
I
asked
him
to
send
me
something
later
on
where
it
says
that
this
is
out
of
specification
compliance,
but
he
never
did
so.
B
H
Yeah
I
feel
like
we
should
be
standardizing
on
one
type
of
label
and
attribute
that
we
use
everywhere.
I
think
it's
kind
of
silly
to
to
place
these
kinds
of
restrictions
on
the
end
user
and
we
should
just
do
the
conversion
for
them,
rather
than
forcing
them
to
do
the
conversion,
regardless
of
what
kind
of
data
types
we
accept
on
the
wire,
I
was
only
half
listening
to
the
conversation,
but
I'm
pretty
sure
that's
what
you're
talking
about
yep,
that's
100,
what
I'm
saying!
Yeah
yeah!
That's
that's
that's!
H
I
feel
like
there's
some
pendant
pedantic-ness
going
on
here,
but
we
should
just
do
the
conversion
for
them.
I
think
one
thing
we
have
to
supply
is
what
we
we
should
probably
standardize
on
what
like
string.
Conversion
looks
like,
I
think,
that's
the
one
missing
missing
component
for
you
to
add
it
to
the
spec.
B
H
I
I
mean,
I
think,
that
the
only
thing
I
guess
I
could
be
nervous
about
is,
if
you
know
we
roll
out
with
one
form
of
string
conversion
and
go
like
just
whatever
go,
does
natively
and
then
later
define
string
conversion
for
labels,
because
I
believe
we
also
want
this
for
metrics
right.
Metrics
is
another
thing
that
needs
this.
H
Then
you
might
be
like
caught
in
a
situation
where
we're
defining
it
for
something
differently
than
what
goes
already
doing.
That's
that's.
The
only
thing
I
can
think
of
that
would
be
thorny
and
to
be
clear
that
the
issue
here
is
especially
around
like
composite
types
right
like
maps
and
arrays
and
stuff,
like
that,
how
do
you
represent
those
as
strings
right,
yeah,
someone.
H
That
that
was
the
thing
I
was
gonna
do,
but
I
have
zero
time
for
it
turns
out,
but
that
that
would
be
something
that
would
be
helpful
just
to
define
what
that
would
look
like.
H
There
was
an
issue
for
this
when
we
decided
to
unify
in
attributes
right
exactly.
That's
that's.
Ultimately
what
this
is
about
right,
yeah,.
B
Well,
maybe
this
is
definitely
not
a
good
first
issue.
D
H
D
So
I
think
that
depends
on
the
type
of
value
in
in
the
attribute,
so
so
the
I
think
that
the
relevant
thing
would
be
attributes
emit
so
like
numeric
attributes
get
get
converted
with
the
idawa
or
format
in
right.
Arrays,
look
like
they
get
just
sprinted,
which
is
a
go
native
representation
of
that,
but
we've
got.
D
We've
got
other
places
where
we've
ensured
that
we
we
do
a
switch
on
the
value
type
and
then
decide
if
it's
an
array-
let's
json
marshall,
it
I
forget
where
exactly
that
was,
I
think
it
might
have
been
in
baggage,
fat
or
the
jaeger
exporter.
It
might
be
yeah
yeah
yeah.
Maybe
it
was
the
the
yeager
exporter.
I
know
one
somewhere.
I
was
reading
a
pr
that
that
I
saw
that
recently.
D
H
Yeah,
so
I
think
that's
that's,
like
the
only
caveat
I
would
say
is
like
what,
if
we
define
the
string
values
differently,
is
that
gonna
I
mean
it.
It's
sort
of
like
a
little
weird
like
why.
Why
are
you
using
baggage
with
like
an
array
type
or
whatever,
like
that's,
that
is
kind
of
strange
in
the
sense
that
if
it
is
like,
oh,
if
the
only
thing
you're
gonna
get
back
from
baggage
is
a
string.
Maybe
that's
my
other
question.
What
does
that
interface?
Look
like
and
go?
Are
we
returning
attribute
types
like?
D
H
Yeah
and
that's
the
part
of
like
compliance,
I
think,
is
more
important.
It's
not
promising
people
anything
other
than
a
string
and
if
that's
all,
you're
going
to
get
out,
it
seems
kind
of
weird
that
you
would
put
some
crazy
thing
in
there,
but
I
could
still
see
us
potentially
breaking
somebody
right
like
if
they're
expecting
json
and
we
decide
that
like
arrays
need
to
have
some
other
format
so
that
that's
my
only
concern.
D
Yeah,
even
that
isn't
really
saved.
If
you
look
at
the
attribute
or
the
the
trace
state
implementation
that
still
has
to
check
it
against
a
regex,
because
that's
the
way,
the
trace
date,
spec
is
defined
game
over.
D
No
baggage
is
separate,
but
free
state
has
the
the
same
restriction.
I
think
in
the
spec
yeah.
H
Yeah
for
baggage
you
could
also
provide
this
is
where,
like
helper
functions,
come
in
right,
like
I,
don't
think,
there's
a
problem
with
languages
where
that
is
expensive,
providing
a
secondary
function.
That
only
accepts
a
string
if
you
want
to
bypass
the
the
conversion
because
it
costs
costs
money.
H
So
I
think
it's
just
a
question
and
go
is
like
which.
H
You
know:
do
you
only
want
to
provide
the
string
thing
for
now
and
wait
for
us
to
define
baggages
like
accepting
accepting
other
types?
I
think
it's
probably
maybe
an
issue
where
other
languages
have
already
gone
out
the
door
where
they
only
accept
strings
here.
So.
D
H
F
H
It's
it's
what's
on
the
wire
is
important
and
I
mean
like
you
could
be
pedantic
and
say,
like
you
know,
we
should
accept
these
values
everywhere
or
nowhere,
but
I
don't
I
don't
know
I
don't
think
that's
you're
going
to
end
up
adding
a
convenience
method.
Anyways,
that's
that's
been.
My
argument
is
like,
even
if
we
have
a
method
that
only
accepts
strings,
there's
no
reason
to
not
add
a
convenience
method
that
that
does
the
conversion
and
as
soon
as
you're,
adding
that
convenience
method.
H
We
want
to
standardize
what
that
looks
like.
So
I
don't
know,
I
think
the
only
risk
would
be.
I
guess
either
breaking
people
later,
which
would
be
bad
post,
1.0
or
ending
up
with
like
a
slightly
crafty
interface
like
like.
If
we
do
change
how
this
stuff
is
is
converted
on
the
wire,
you
would
probably
want
to
add
another
function
later
and
like
deprecate
this
one
rather
than
break
people.
B
So
the
problem
is
that
we
would
need
this
for
the
rc
right
so
like
yeah,
I
guess
we
kind
of
have
to
if
that's
the
case
or
we'd
have
to
take
on
the
task
of
trying
to.
You
know,
specify
that
conversion
function
and
get
a
release
for
the
open,
cylinder
specification.
Yeah.
H
You
can
try
to
get
that
brush
out
the
door
and
we
do
need
it
for
metrics.
It
is
a
thing
that
would
be
fast.
Unfortunately,
like
this
thing,
I
was
like
I'll
help.
Do
that
and
I've
been
buried
trying
to
get
some
of
these
other
projects
off
the
ground.
So
it's
my
fault.
We
don't
have
this
bad
ted.
B
I
mean
to
be
honest:
I
I
think
that
you're
super
kind,
but
like
you
need
bogdan
to
help,
write
this
because
he's
gonna.
H
Yeah
I
know,
but
bogdan
and
and
josh
will
have
questions
and
they're
gonna
want
weird
things
like
you
know
some
some
things
around
like
floating
point
numbers
right
and
and
like
what
is
a
more
accurate
representation
for
metrics
versus
was
a
human,
readable
representation.
H
H
Maybe
thinking
thinking
about
how
you
name
it
so
that
you
can
then
add,
add
one
later
that
accepts
all
the
attribute
types
just
think
about,
and
the
advantage
honestly
is
what
rich
said
is:
if
you
have
a
string,
then
having
the
stringly
typed
function
is
gonna.
Save
you
a
type
check.
So
it's
not.
It's
not
like
that's
a
terrible
thing
to
offer
people,
because
that
does
actually
save
them
some
cpu
cycles.
H
B
Okay,
an
interesting
time
anthony.
Does
that
answer
the
question
there
yep
yeah,
I
think
so,
okay
and
I'm
going
to
leave
it
up
to
you
to
figure
out
what
you
want
to
do
on
that
one.
Unless
you
want
to
leave
it
up
to
me,
I
think
we
should
leave
it
up
to
each
other.
There
you
go
so
nobody
will
do
it.
Okay,
yeah!
B
I
will
okay
I'll
keep
thinking
about
that.
The
user
study
ted
brought
to
you
last
last
item
on
the
agenda.
H
Yeah,
oh
and
thank
you
all
for
for
moving
this
meeting
time.
I
haven't
been
able
to
come
to
the
go
working
group
in
forever,
just
because
it
overlapped
with
the
governance
committee
meeting,
so
I'm
stoked
that
there's
a
new
meeting
time,
yeah
user
studies,
so
we
matt
mccleary
from
microsoft,
did
a
bang-up
job
of
creating
a
user
study.
H
This
is
like
a
full-on
proper
user
study
user
study
for
open
telemetry,
so
it
takes
maybe
15
to
30
minutes
for
someone
to
fill
out
and
we
want
to
start
it's
hot
off
the
press
and
we
want
to
start
spreading
this
around.
So
I'm
just
going
around
to
the
6
asking
people
potentially
fill
this
out
yourself
as
a
user
of
the
project
and
also
hand
it
out
to
people
you
work
with
customers
post
it
on
the
internet.
We
really
really
need
feedback.
H
This
feedback
mostly
focuses
on
installing
and
setting
up
the
open,
telemetry
clients
and
what
that's
like.
It
does
have
a
section
on
data
and
data
quality,
but
I
actually
wanted
to
call
that
out
as
a
separate
ask,
because
I
don't
think
we
need
people
to
fill
out.
H
We
have
gotten
some
feedback
that
people
feel
like
our
instrumentation
is
a
little
anemic
compared
to
what
they're
used
to
from
from
other
tools.
Basically,
like
our
guidelines,
just
include
less
stuff
than
what
people
might
be
used
to
getting.
You
know,
I
think
some
things
that
that
john
watson
has
pointed
out
are
things
like
dns
information
and
stuff
like
that.
H
So
we
would
like
to
gather
feedback
from
people
who
have
been
looking
at
open,
telemetry
data
in
any
language,
just
just
to
get
feedback
about
what
what
about
the
telemetry
they're
seeing
you
know
could
be
improved.
H
So
again,
this
is
maybe
things
people
in
this
working
group
could
could
just
answer
off
the
top
of
their
head
and
if
you
work
at
a
company
that
has
customers
or
is
using
open,
telemetry
going
and
asking
those
people
to
to
give
us
feedback
and
that
feedback
can
be
literally
any
form
just
copy
and
paste
it
into
the
hotel,
instrumentation
slack
channel
or
hand
it
to
me
over
slack
or
anywhere
and
I'll,
do
the
job
of
kind
of
organizing
it,
but
but
just
basic
feedback
on
the
actual
data
we're
producing
and
what
we
should
do
to
improve
that
before
going
and
doing
like
another
pass
through
of
all
of
our
instrumentation
and
trying
to
write
a
lot
more
instrumentation.
H
So
I
think
the
other
thing
that
came
up
related
is
how
do
people
want
to
configure
this?
I
should
mention
that
as
well.
The
other
complaint
we
get
is
like.
I
want
to
configure
it
somehow,
and
I
don't
want
us
to
write.
I
don't
want
every
instrumentation
package
to
start
coming
up
with
its
own
bespoke
little
set
of
configuration
options.
Anthony
was
mentioning
you
guys
have
some
some
kind
of
standard
stuff.
There,
which
sounds
good,
but
I
would
like
to
yeah
figure
out
how
to
standardize
those
configuration
options
that.
A
A
Bong
jones
suggested
it
but
yeah.
I
was
noting
that
about
how
sometimes
you
you
have
a
program
that
you
didn't
write
and
the
the
prospect
of
getting
in
there
and
getting
involved
in
its
whole.
Initialization
procedure
is
untenable
and
you
really
wish
there
was
just
like
some
kind
of
environment
variable
that
you
could
dump
in
a
whole
bag
of
options
into
where
the
author
could
could
start
out
and
say,
I'm
going
to
turn
on
open
telemetry.
A
H
H
I
want
you
to
silence
because
they're
just
annoying
to
me
things
like
that,
so
that
that's
the
kind
of
feedback
we're
looking
for
right
now,
if
you're
interested
in
helping
out
this
effort,
there's
a
channel
on
slack
hotel,
instrumentation
and
really
it's
just
just
getting
this
feedback
in
right
now
is
the
most
important
thing.
So
so
that's
my
ask
and
thank
you
so
much
steve
for
filling
the
survey
out.
B
Yeah
awesome
thanks
ted
for
also
taking
this
on.
This
is
super
important
yeah
to
the
project
as
a
whole.
So
that's
really.
This
is.
B
That's
fine,
that's
that's
what
anthony
and
I
are
here
to
argue
over
who
doesn't
have
to
do
it.
Yeah
cool
that
sounds
great
looks
like
we
have
about
three
minutes
left.
I
didn't
even
know
if
anybody
else
says
anything
else.
I
wanted
to
add.
Nothing
else
is
on
the
agenda.
B
B
Cool
well,
I
think,
then,
with
that
we
could
probably
end
it,
and
I
will
give
you
a
whole
two
minutes
back.
So
I
said
I'll
give
you
some
time
back
cool,
awesome.
Everyone
thanks
for
showing
up.
I
definitely
again
appreciate
all
the
help.
All
of
the
people
contributing
really
excited
trying
to
get
this
rc
out
so
really
appreciate
it,
and
we
will
see
you
all
next
week
or
virtually
sounds
good.