►
From YouTube: 2020-10-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).
A
D
Yeah
sometimes
I
am
successful
in
that
endeavor,
but
yeah.
I
think
that
there's
it's
kind
of
just
my
only
thing
I
wanted
to
touch
on
today.
There's
16,
open,
pr's
and
probably
wanna
make
some
make
some
calls
or
get
some
eyes
on,
or
something
like
that.
I
definitely
know
there's
a
few
in
here
that
I'm
woefully
behind
on
reviewing,
so
I
definitely
wanted
to
jump
in
there,
but
yeah.
Everyone
else
welcome
be
sure
to
add
yourself
to
the
attendees
list.
D
Cool
yeah
we
can,
I
guess,
start
with
the
bureaucracy,
because
that's
always
boring
and
people
can
kind
of
filter
into
that
time
frame.
D
My
god,
that
is
huge
cool.
Can
everyone
see
my
screen?
I'm
guessing
okay,
cool
awesome!
Well,
thanks
again
for
joining
just
to
kind
of
start,
it
off
wanted
to
go
over
some
of
the
project
boards,
actually
a
fair
amount
of
progress
in
the
triaging
of
issues.
This
week
I
was
able
to
wade
through
the
majority
of
the
existing
ones
in
the
open
cemetery
go
space
and
we've
actually
had
a
fair
amount
of
progress
in
just
moving
things
into
that
working
column
definitely
got
a
big
bump
here.
D
The
to-do
definitely
went
up,
given
the
large
number
that
we
were
able
to
triage
and
we're
seeing
some
successful
conversions
to
you
know
resolving
some
issues,
so
that's
pretty
awesome
to
see
in
both
the
main
repo,
as
well
as
the
contributor
so
yeah
to
everyone
on
the
call
that's
contributing
to
this.
I
just
want
to
extend
my
thanks.
That's
definitely
appreciated
yeah,
and
I
think
that
specifically
this
in
progress
thing,
we
could
probably
do
a
little
bit
better
on
making
that
conversion
happen,
but
it's
just
a
matter
of
hours.
D
I
was
telling
steve
right
before
the
as
we're
starting
there's
a
few
pr's
here
that
I'm
definitely
behind
on
reviewing.
So
I
understand
how
that
goes,
but
yeah.
Anyone
on
the
call
that
had
something
they
wanted
to
talk
about
in
the
agenda
for
today,
please
be
sure
to
add
it
to
the
end.
Otherwise,
I
was
planning
on
just
going
through
the
16
open,
prs
and
kind
of
getting
everyone's
opinion
on
that
and
understanding.
D
If
you,
if
you
have
opinions
actually
reviewing,
would
be
ideal,
but
there's
a
few
that
have
some
open
questions
about,
so
we
should
probably
just
discuss
it.
I
wanted
to
discuss
them
as
a
group
and
yeah
just
kind
of
moving
moving
on
which
we
can
just
jump
into.
D
This
is
the
oldest
one
from
july.
This
is
lose
open
this
in
an
attempt
to
restrict
the
multi-dimensional
arrays
to
not
being
multi-level
to
conform
to
the
specification
which
is
needed.
There
was
a
related
specification
issue
that
was
also
closed.
That
also
said
that
this
should
be
done.
So
this
is
the
correct
move
to
be
done.
However,
this
has
just
been.
It
was
sitting
for
so
long
due
to
the
specification
issue.
It
was
hard
to
keep
updated
and
then
the
changes
have
made
this
almost
untenable
to
make
it
updated.
D
I've
tried
a
few
times
to
update
this,
but
it's
I
can't
actually
update
this
branch,
so
I
have
to
re-implement
the
changes.
Liz
doesn't
join
the
meetings
too
often,
so
I
I
don't.
Let
me
see
if
I
can
scroll
through
this.
I
don't
see
liz
on
the
call.
So
I
believe
the
governance
committee
meets
at
the
same
time,
yeah.
C
D
Right,
that's
right!
Yeah,
thanks
yeah!
I
forgot
about
that
so
much
to
kind
of
heart.
I
wonder
if
I
can
ping
liz
in
the
channel
afterwards
or
something
like
that
and
have
somebody
else
take
this
to
get
this
resolved,
because
I
think
this
is
yeah.
I've
listed
this
as
a
p1
because
it
is
a
breaking
change
or
breaking
functionality.
At
least
I
don't
know
if
it's
actually
an
api
breaking
change,
this
might
need
to
be
a
p2,
but
regardless,
I
think
it
needs
to
get
resolved,
probably
sooner
rather
than
later.
C
C
D
Yeah,
that's
actually
a
good
point.
There's
there's
two
components
here
and
you're
talking
specifically
on
the
fact
that
it's
returning.
D
Yeah
they
should
copy
the
return.
Value
should
be
copied
not
the
this
is
the
function
array,
value,
yeah.
D
Yeah
correct:
that
is,
I
think,
the
the
point
here.
I
think
it's
that's
right
and
then,
when
I
was
looking
at
just
redoing
this,
there
was
the
issue
that
when
this
actually
happens,
it
actually
copies
it
into
an
array.
So
not
a
slice,
I'm
not
mincing
words.
There
like
it's,
actually
an
array,
that's
being
returned,
which
is
going
to
be
a
problem
for
a
few
different
implementations
when
this
does
get
updated
because
they
rely
on
the
fact
that
this
can.
D
When
you
return
from
this,
you
get
a
slice,
even
though
the
method
is
called
array
here,
and
that
is
that's
kind
of
a
tough
one
that
I
think
should
probably
get
addressed
in
the
redoing
of
this.
So
that's
going
to
be
a
that's
going
to
be
a
hard
one
to
actually.
I
was
kind
of
wondering
if
we
should
maybe
re
rename
this
instead
of
array
call
as
a
slice
and
return
a
slice
when
we
actually
have
that
slice
value,
because
it
seems
like
that's
the
more
common
data
type
and
go.
D
C
E
Yeah,
I
agree
with
that.
It
would.
I
think
it
would
be
worthwhile
also
to
look
at
the
things
that
expect
to
slice
explicitly
and
see
if
that
behavior
can
change,
because
I
think
the
expectation
should
be
that
they
receive
an
interface
and
have
to
deal
with
the
various
types
that
that
interface
may
be
right.
D
Yes,
the
problem
is,
though,
that
arrays
are
distinctive
types
based
on
the
length
right
so
receiving
a
length
or
a
length.
Two
array
versus
a
length
three
array
is
totally
different
type.
So
if
the
structure,
I'm
pretty
sure
this
is
in
the
otlp
exporter,
if
the
structure
is
trying
to
export
say
like
expand,
arrays
and
there's
a
method
for
attributes
or
something
like
that
and
that
I'm
sorry
a
function
for
attributes,
you
can't
just
pass
the
array
to
the
attributes
function
because
there
are
different
types.
D
D
I
guess
it
was
my
my
question
once
I
was
doing
that
you
know,
because
you
have
to
break
up
the
reflect
package
to
find
out
what
the
type
is
again
and
then
from
that
build
the
slice
and
then
pack,
but
things
back
in
and
I'm
just
saying
to
myself
like
yeah,
I'm
going
to
do
this
every
time
like
I
don't
know
if
this
is
a
really
useful
return
value
at
this
point.
D
D
D
Moving
on
this,
has
I
didn't
even
look
if
this
has
had
any
progress,
I
don't
think
it
has.
There's
been
some
asks.
This
is
sorry.
I
have
a
lot
of
context
up.
Add
support
for
pretty
printing,
pretty
printing
the
histogram
and
standard
out.
Standard.Exporter
didn't
actually
have
an
export
mechanism
for
histograms,
and
this
was
intended
to
add
them.
The
format
of
that
output
is
kind
of
it
was
up
for
debate,
and
I
think
that
there's
still
some
work
to
be
done.
D
The
current
way
that
it's
actually
set
up
to
to
have
this
output
is
is
a
very
unique
way
where
the
output
is
in
a
somewhat
some
pseudo
prometheus
format
and
it
doesn't
conform
with
a
lot
of
the
other
formats
that
the
other
standard
exporter
had.
This
is
kind
of
deriving
from
the
comments
that
josh
had
made
that
you
know.
Maybe
we
should
have
a
standard
exporter.
You
know
be
able
to
output
in
a
prometheus
format,
which
I
think
is
a
cool
idea,
but
I
think
that
we
should
probably
not
mix.
D
The
two
was
the
question
and
I
left
it
left
a
review
kind
of
asking.
You
know
a
little
bit
about
that
and
then
I
never
heard
back
on
this
and
it's
been
open
since
august,
which
we
are
now
in
october.
So
I'm
kind
of
wondering
what
we
think
about
moving
this
forward.
I
don't
know
if
there's
any
any
work
being
done
by
mooshtab.
He
hasn't
shown
up
to
the
meetings
in
a
while.
D
You,
if
you
would
like
to,
I
think,
if
that's
fine,
I
don't
it's
it.
I
labeled
this
as
released
for
after
ga,
and
I
think
this
is
why
it's
kind
of
just
sat
on
the
back
burner
for
me
for
so
long,
because
I
don't
think
it's
a
top
priority,
but
yeah
like
if
you
have
a
passion
for
this
kind
of
thing,
which
I
yeah,
I
think
we
could.
It
would
be
helpful
to
a
lot
of
people,
especially
going
into
ga
to
see
the
the
data
coming
in
yeah.
A
I
I
mean
I
do
use
standard
out
exporter
to
check
things
quite
often,
and
it
would
be
nice
to
see
a
histogram
pop
out
of
there
right,
yeah.
D
A
Just
leave
this
one
for
me,
I
think
I
can.
I
mean
yeah
leave
this
one
for
me
I'll,
take
it.
D
D
D
I
don't
think
anybody
is
I
don't.
I
think
that
josh
and
me
are
the
only
ones
that
are
really
like
have
taken
a
look.
So
that's
kind
of
the
idea,
but
the
the
point
here
is
that
steps
taking
on
the
challenge
that
open
telemetry
exporter
needs
to
be
able
to
send
different
signals
to
different
endpoints,
and
this
is
by
definition
of
the
specification
and
it
needs
to
have
a
fallback
to
the
some
sort
of
default.
D
I
guess
is
the
idea,
and
what
has
happened
here
is
just
a
re-encapsulation
of
that
otlp
connector
itself
into
its
own
structure,
so
that
it
can
be
reused
for
each
one
of
the
signals
and
from
the
high
level
I've
taken
a
look
at
this
looks
good.
The
thing
that's
always
tripped
me
up
and
I
always
spend
time
on
and
then
I
get
called
onto
20.
Other
things
is
the
option
format.
Here
I
was,
I
still
I
still
haven't
wrapped
my
head
around
it.
D
I
think
that
the
the
question
that
I
have-
and
this
is
this-
is
an
ignorant
understanding
because,
like
I
said,
I
haven't
fully
wrapped
my
head
around
it
is
that
I
wonder
how
the
default
scheme
looks
and
how
the
use
case
looks.
So
if
you
go
and
set
up
an
exporter
with
just
the
default,
is
it
really
simple
or
is
there
a
simpler
way
that
we
can
restructure
these
options
to
enable
that,
I
think
was
my
only
like
question.
I
was
looking
through
this.
D
D
Okay,
this
is
one
where
okay,
I
can't
promise
today,
but
tomorrow
I
I
have
it
on,
like
my
docket
that
I'm
going
through
I'm
going
to
put
a
review
on
this
yeah,
I
feel
really
bad
and
feel
really
guilty
because
I've
just
been
like
it's
got
an
open
tab
of
this
one
for
like
the
past
week
now,
and
I
just
keep
jumping
onto
other
things.
D
D
Great
work
in
here-
and
I
just
I
feel
bad-
that
it
has
been
sitting
for
as
long
as
it
has.
F
So
I
mean
it's
also
a
pretty
big
change,
so
this
usually
take
a
while.
E
It's
true:
are
we
settled
on
the
approach
of
maintaining
the
separate
connections,
then,
as
opposed
to
what
josh's
suggestion
of
just
having
the
separate
exporters.
D
Well,
so
the
that's
a
good,
that's
a
good
question.
I
was
kind
of
just
assuming
that
we
would
have
to
do
the
separate
signals
just
based
on
the
fact
that
to
conform
with
the
specification
itself,
at
least
I
can
just
pull
this
up.
D
The
endpoints
need
to
be
specifiable
as
the
span
endpoint.
The
metric
endpoint
like
these
are
these
are
environment
variables
that
the
exporter
needs
to
be
taken
to
conform
to
the
specification,
and
so
that
seems
to
me
that
we
need
to
be
able
to
separate
out
the
signals
like
to
run.
Different
exporters
like
that
also
seems
like
a
viable
solution,
but
then
you
don't
conform
with
this
like
standard
approach,
and
I
think
the
I
think
part
of
it
could.
E
Couldn't
you
I,
I
think
if
you
have
separate
exporters
as
long
as
you
tell
each
one
you're
for
metrics
and
your
four
traces,
then
it
can
it
can
during
configuring
its
connection,
look
to
the
appropriate
environment
variables
if
it's
told
that
it's
a
trace
exporter
look
to
the
the
span.
Endpoint
then
otl,
p
endpoint.
If
it's
called
the
symmetrics
exporter,
looks
metrics
endpoint,
then
otlp.
D
That's
a
good
point.
I
didn't
think
about
that
thanks.
What
do
other
people
think
on
this
one?
This
is
new
to
me.
I
think
I'm
still
registering
it.
Sorry.
F
My
only
concern
is
that
you
know
if
you
actually,
I
might
be-
I
don't
understand
it
completely
either.
If
you
don't,
I
mean
if
you
don't
take
this
separation
of
metrics
and
traces
exports
on
like
the
changes
that
we
did
here,
then
this
will
go
in
the
client
side
afterwards
and
they
will
have
to
manage
two
different
exporters
right.
E
Right
yeah,
I
think
that's
where
the
advantage
of
this
approach
comes
in
is
that
you
can
just
have
one
exporter,
but
it
can
be
configured
at
runtime
separately
for
the
different
signal
types.
So
I
think
there
is
an
advantage
here.
I
think
the
the
question
is:
does
that
advantage
introduce
additional
complexity,
and
is
that
complexity
worth
it?
It
certainly
could
be.
A
So
if
you
wanted
to
have
an
exporter
that
could
do
both
metrics
and
traces,
you'd
still
need
you'd
have
to
instantiate
two
copies
of
it
in
the
proposed.
A
Not
not
this
approach,
I
guess,
but
the
proposed
approach,
that's
what
that
josh
was
suggesting
right
and
and
essentially
have
one
of
them
just
send
stuff.
How
would
you
handle
that
case
where
it
doesn't
know
whether
it's
a
metrics
or
a
trace
exporter?
I
guess
you'd
have
to
tell
it
when
you
install
it
into
a
pipeline
right.
A
E
Yeah,
I
think
the
approach
of
handling
it
within
the
exporter
and
having
a
single
exporter
is
cleaner,
because
the
exporter
knows
which
type
of
signal
it's
sending
out
when
it
sends
it
out
and
it
can
choose
which
connection
to
use
and
it
would
be
simpler
for
users
to
simply
instantiate
a
single
exporter,
provide
it
to
the
appropriate
pipelines
and
then,
if
at
runtime,
different
environment
variables
are
provided
it's
handled
for
them,
they
don't
have
to
worry
about.
Oh,
I
want
to
change
this
now
on
a
per
signal
basis.
Let
me
go
refactor.
D
Yeah,
I
think
that
the
other
side
of
things
is,
if
you
run
this-
and
you
wanted
to
like,
take
your
kubernetes
configuration
that
accept
these
environment
variables,
but
change
it
from
you
know
a
javascript
app
to
a
go
app
or
something
like
that.
You
would
you'd
have
to
redo
the
entire
orchestration
pipeline
on
your
side
right
instead
of
just
being
able
to
say,
like
oh.
D
Yeah,
and
on
top
of
that
there
is
I'm
actually
kind
of
surprised,
josh
didn't
think
of
this
one,
there's
a
slight
overhead
of
resource
consumption,
just
from
the
exporter
itself.
So
from
the
super
optimized
standpoint
of
probably
like
a
few
bytes
of
memory
having
a
single
exporter
is
probably
a
better
approach
but
yeah.
I
think
if
that
sounds
correct
to
me,
to
go
ahead
with
this
approach
and
to
try
to
bring
it
into
the
same
exporter.
D
E
D
Yeah,
absolutely
I
I
really
appreciate
it.
That's
the
whole
thing
meeting
up
and
syncing
with
some
smart
people,
so
I'm
all
about
it
cool.
I
think
that
sounds
good.
I
think
we
kind
of
have
a
decision
to
kind
of
like
keep
going
with
this
again
could
do
some
eyes,
I
think
anthony
I
might
have
misspoke
yeah.
You
definitely
have
taken
a
look
at
this
as
well
so
yeah.
If
other
people
want
to
take
a
look,
I
think
that'd
be
awesome.
E
D
You
and
me
both,
so
I
again
feel
bad
about
that
sorry,
stephan,
stefan,
it
is
on
my
docker.
D
Cool
the
next
one
this
is
mine,
so
I
should
have
some
context
in
this.
Hopefully
this
is
updating
the
propagation
to
conform
with
the
open,
telemetry
specification,
the
idea
this
is
breaking
out
the
api
propagation
package
and
putting
it
up
at
the
top
of
the
hotel
package
as
part
of
that
initial
refactor
that
I
was
describing
a
few
weeks
ago
in
doing
that,
there
was
just
a
you
know:
there's
an
already
an
open
issue
to
migrate
to
from
http
propagators
to
a
text
map
renaming
propagation
scheme.
D
So
I
was
looking
at
that
as
well.
The
thing
is,
I
also
realized
that
our
propagation
api
is
it
predates
the
specification
propagation
api.
So
it's
it's
not
conforming
to
what
has
eventually
evolved
into
the
propagation
specific
specification
api.
So
this
also
includes
changes
to
to
bring
that
in
line
with
the
specification,
I
think
it's
a
positive
change
as
well.
D
It
reduces
a
lot
of
the
complexity
of
the
api,
with
the
goal
to
to
to
drive
that
maintained
code
in
the
long
term
to
a
minimal
set
and
to
provide
the
functions
that
I
think
are
going
to
be
useful
in
the
in
the
core
like
an
atom
of
the
actual
change
we
said
I
can
just
bring
up
the
package
should
get
better
at
this.
D
The
idea
is
that
it
used
to
be
called
hp
supplier,
which
is
essentially
the
same
thing
as
this
text.
Map
carrier
at
this
point
renamed
to
the
text
map
part
just
because
text
map
was
what
the
specification
now
specifies.
It
also
is.
I
was
looking
the
other
day
comes
from
open
tracing.
They
have
the
same
terminology,
so
that's
nice
to
have
some
sort
of
syncing
with
that
it
is.
The
carrier
is
the
thing
that
actually
is
going
to
be
going
through.
D
This
text
map
propagator
the
text
map
propagator,
is
in
the
specification
the
only
defined
propagation
type,
currently
there's
a
proposal
or
in
I
think,
the
oteps
to
make
a
binary
propagator
eventually.
So
this
will
be
a
new
type,
a
new
interface
that
will
be
added
to
this
api.
So
there's
there's
an
extensibility
here.
One
of
the
things
that
isn't
here
is
the
old
propagation
or
propagator's
interface,
and
that
is
because
it
actually
was
not
in
the
api.
D
D
Essentially,
you
would
consider
them
as
a
collection
of
types,
so
that
was
removed,
and
I
think
it's
kind
of
nice
how,
when
it
was
removed,
it's
kind
of
useful,
because
it
was
really
kind
of
identified
in
the
specification
that
we
are
going
to
be
returning
a
propagator.
D
You
need
to
be
specifying
that
propagator
type,
so
you
need
to
be
returning
an
explicit
propagator
and
returning
a
generic,
propagator
or
collection
of
propagators
really
only
made
sense
in
the
context
that
they're
a
collection
of
the
same
type
of
propagator
and
that's
how
the
specification
is
actually
written
as
well,
so
having
this
switching
over
to
a
specific
type
and
removing
that
it
seems
in
line
and
all
the
changes
associated
with
this,
you
can
see
like
it
works
out
quite
well.
D
D
D
It's
I'm
definitely
love
some
feedback
on
this,
but
what
it
doesn't
do
is
it
doesn't
split
this
tex
mac
propagator
into
injectors
and
exporters.
Every
instance
I
saw
of
how
this
was
being
used
when
you
combine
them.
It
was
always
the
same:
propagator
would
be
used
for
both
exporter
and
injecting
are
extracting
and
injecting.
So
it
really
didn't
make
any
sense
why
you
would
want
to
do
this,
and
on
top
of
that,
there
is
a
way
you
could
wrap
the
propagator
to
have
like
a
no
op
for
one
of
those
methods.
D
If
you
really
did
want
to
actually
exclude
you
know,
you
didn't
want
the
trace
context
to
be
on
the
extract
or
on
the
inject
side.
So
you
would
just
you
would
wrap
that
essentially
into
your
own
propagator,
and
then
you
could
use
that
and
given
that
was
kind
of
like
the
odd
case
out,
given
the
use
cases
that
I
was
seeing
of
this,
I
just
said:
well
that
should
be
like
a
default
and
something
we
could
build
from
like
if,
after
the
fact
is,
we
really
realize
like
no
people.
C
D
D
A
D
Right
right
and
yeah
sorry
go
ahead.
E
I
think
that
that's
a
useful
capability,
though,
because
I've
definitely
seen
people
asking
about
okay.
Well,
I
I
know
I've
got
this
one
format
coming
in,
but
I
want
to
use
a
different
format
from
here
on
out,
right,
so
being
able
to
say
I'm
going
to
take
you
in
any
of
these
formats
on
on
the
extract
side,
but
I'm
only
going
to
inject
this.
One
format
I
want
to
use
going
forward
would
be
very
useful.
A
Yeah,
sorry,
sorry,
I
was
going
to
say:
oh
yeah.
I
have
a
case
in
istio,
for
example,
where
it's
all
set
up
to
use
b3
from
the
sidecars,
but
from
my
side
I
don't
want
to
send
out
b3.
I
actually
just
want
to
call
my
other
services
with
you
know,
h,
2,
to
b
trace
or
w3
trace,
whatever
it
is
so
yeah.
I
have
a
place
where
I
want
to
have
both
w3
trace
and
v3
on
the
incoming
and
only
w3
of
the
upcoming.
D
D
I
wanted
to
keep
it
small,
but
if
there's
a
strong
need
for
it,
I'm
open
to
adding
them
it'd
be
kind
of
nice
to
not
add
them
and
have
other
users
who
are
building
out
rappers
provide
their
preferred
format
of
how
they
want
that
rapper
to
look
instead
of
just
making
the
decision
at
this
point,
but
I'm
open
to
opinions.
E
Yeah,
I'm
fine
with
that,
too.
I
think
that
we
should
open
an
issue
to
track
the
desire
for
that,
even
if
it's
just
hey,
we
think
that
this
would
be
a
useful
capability.
Please
provide
feedback
and,
or
suggestion
suggested,
implementations.
D
Cool
keep
on
moving
on;
I'm
definitely
realizing
we're
not
going
to
get
through
all
of
these
next
one
is
an
also
one
for
me.
This
one
probably
shouldn't
require
as
much
discussion
the
specification
after
sticking
with
the
grpc
codes
for
the
longest
time
have
finally
been
changed
to
not
track
the
grpc
codes
anymore
and
they
reduce
it
down
to
three
different
codes.
C
D
Yeah
they
they
don't
they
don't
care
anymore.
There's
there's
been
a
lot
of
discussion
here,
there's
actually
the
errors
sub
sig,
I
don't
know-
I
guess
it's
called
the
sig
as
well-
have
been
meeting
for
the
past
month
or
two
now
kind
of
discussing
a
large
amount
of
how
they
want
to
encode
errors,
how
they
want
to
encode
statuses,
and
what
even
is
an
error
is
always
the
question
that
gets
raised,
which
is
my
favorite
but
yeah.
C
D
They
they
came
to
this
conclusion
of
after
a
long
deliberation
and
it's
just
around
reducing
the
overhead
there's
a
lot
of
other
languages
that
you
can't
separate,
separate
out
the
dependencies
for
grpc
without
including
the
library
which
is
a
large
overhead,
pretty
much
in
every
single
language,
and
we
we
have
that
same
dependency
in
this
language
below
the
sdk
and
exporters.
So
I
think
that
that's
a
big
reason,
but
I
think
it's
also
just
the
overhead
of
the
simplicity
of
it.
D
There's
really,
you
know
what
is
an
error
is
is
hard
to
describe
and
then
there's
the
the
classification
of
those
errors
and
choosing
the
paradigm
of
grpc
is
something
that
is
a
googleism
and
I
think,
a
lot
of
people
weren't
comfortable
with
that.
D
They
wanted
a
more
unique
hotel
way,
and
I
think
that
this
way
is,
you
know
it's
an
error,
because
it's
an
error,
you
know
whatever
that
is
or
or
the
user
says
it's
an
error
or
it's
the
user
says
it's
okay
and
but
those
are
two
explosive
things
and
then
otherwise,
essentially
the
sdk
should
just
never
set
something
it
should
always
be.
Unset
is
how
I
read
the
specification,
but
yeah
it's
pretty
much
just
two
states
in
the
in
the
status
at
this
point.
D
Correct
me
from
wrong
anthony
years
I
think,
but
like
yeah,
it's
for
ga.
It's
closed
like
this
is
what
this
is.
What
they've
recommended?
This
is
what
the
merge
br
is.
I
don't
think
the
group's
meeting
anymore.
So
it's
it's
what
it
is
yeah.
E
Yeah,
I
think
they've
wanted
to
keep
it
to
a
minimal
set
just
to
minimize
the
complexity
of
dealing
with
this,
and
there
was
the
other
concept
of
instrumentation
versus
user
set
errors.
Is
that
captured
somewhere
separately
from
the
codes,
or
did
they
end
up?
Moving
away
from
that
again,.
D
D
I
think
I
think,
if
I'm
understanding
correctly,
they
they
talk
about
when
they
should
be
set.
They
pretty
much
say
like
don't
set
it
unless
the
user
tells
you
to
or
like
you've
run
into.
You
know
a
language,
specific
error
and
then
down
here
in
the
semantic
conventions,
which
is
where
they
used
to
say
like
http.
That
kind
of
thing
like
they
give
some
guidelines
as
to
like
how
that
should
be
set,
but
yeah.
D
E
I
thought
that
in
an
earlier
incarnation
of
this
there
was
there
was
a
second
like
span
status
or
not
status,
but
status
source,
or
something
like
that
that
that
indicated,
whether
an
error
or
okay
indicator
came
from
instrumentation
or
some
automatically
derived
source
or
from
a
user
explicitly
setting
it
as
an
error.
D
Yeah,
I
think,
just
remembering
in
past
meetings
that
this
is
the
consensus
solution
to
all
of
that.
So,
yes,
they
they
aren't.
D
Like
if
you
wanted
to
there's
the
optional
status
message
as
well,
that
you
could
put
whatever
you
essentially
like
free
form
in
that,
but
otherwise
like
that,
the
source
is
not
coming
in,
and
this
is
also
the
other
side
where
they
were
just
going
to
completely
remove
the
set
status.
This
is
you
know
the
unset
set
status
is
the
compromise
there.
I
think.
D
But
yeah
I
I
think
this
is
solid
enough,
that
it
should
be
implemented
on
our
side,
and
I
think
that
it
also
means
that
we
don't
have
to
change
this
advanced
status,
which
means
we
have
to
ask
some
other
hard
questions
on
our
end
but
yeah.
I
think
this
is
good
to
go.
B
D
Is
a
pr
from
a
first-time
contributor,
adding
a
semantic
convention
for
messaging
option
send
pretty
straightforward.
The
issue
I
had
with
this
is
that
the
specification
back
really
clearly
states
that
you
shouldn't
set
this
and
that
if
the
operation
is
sent,
the
attribute
must
not
be
set
as
in
a
requirement
to
not
set
this.
So
I
don't
think
that
we
should
be
including
this
in
our
semantic
conventions
to
enable
users
to
actually
set
this.
I
kind
of
wanted
to
close
this
issue,
but
then
I
saw
anthony
approved
it.
E
D
I
approved
that
and
then
saw
your
comment:
oh
okay,
okay,
okay,
yeah.
I
I
think
I'm
gonna
close
this
issue,
because
I
don't
think
that
we
should
be
doing
this,
but
okay,
I
just
wanted
to
make.
I
didn't
want
to
do
that
before
we
have
a
discussion
yeah,
unfortunately,
github
doesn't
provide
a
method
for
retracting
approvals.
I
yeah.
I
know
I'm
I've
been
hit
by
that
one
as
well
really
awkward
times
when
you
approve
a
prototype
pr
where
you're
like
this
isn't
even
done
like.
D
Why
did
I
like
anyways
cool
I'll,
take
the
action
on.
D
D
It
looks
it
looks
really
good
to
start
with
and
then
there's
an
ass
to
correct
a
different
change
log.
Essentially
what
this
is.
This
removes
this
set
attribute
field
from
the
spans.
Given
this
exists
right
above
it
and
it's
a
variatic
functions,
so
you
could
just
easily
pass
one.
This
doesn't
even
use
our
label
set,
so
I,
I
really
don't
think
it
needs
to
be
existed.
There's.
D
C
Removing
spaces
about
how
there's
there's
sort
of
an
efficiency
trade,
because
you
know
you
wind
up
forming
an
array
or
a
slice
for
the
arguments
coming
in
and
in
some
cases
the
code
just
looks
nicer,
even
if
it's
slightly
more
more
verbose
to
see
line
by
line
you
know
set
attribute
set
attribute
but
yeah.
I
I
didn't
remember
that
this
had
been
approved,
but
it's
it's
interesting
to
see.
C
Yeah
I
wish
josh
was
on,
because
I
could
have
sworn
that
he
was.
He
was
defending
preserving
the
the
single
form
weekly.
So
though
you
know
I
do
I,
I
think
it's
kind
of
a
very
slight
performance
concern
and
it's
an
aesthetic
benefit,
but
really,
I
think
we
should
only
have
one
or
the
other,
because
it's
not
like
one
of
not
like
the
multi-attribute
form
is
necessarily
more
efficient
that
I
know
of.
D
Yeah
I
I
can
definitely
agree
with
the
fact
that
we
should
only
have
one
of
these.
I
think
that
was
really
where
this
came
from.
I
I
like
the
variatic
functions
there
used
to
be
some
concerns,
especially
in
the
older
versions
of
go.
The
periodic
functions
were
not
as
efficient
as
just
passing
slices
or
multiple
calls,
but
that
has
since
changed.
I
don't
even
know
if
it
was
really
an
issue.
I
think
that
was
somewhat
of
a
a
poor
benchmark
but
yeah
I
I
honestly,
I
just
wanted
one.
D
I
just
wanted
to
clean
up
the
api.
I
don't
want
to
support
both
of
these
going
forward
after
the
ga.
That's
the
thing
that
I
was
feeling.
C
D
Yeah,
I
I
think
it
was.
I
don't
think
there
was
really
strong
opinions
as
to
which
one
I
do
think.
I
do
have
a
strong
opinion
that
the
set
attribute.
D
If
we
wanted
to
keep
it,
we
should
probably
take
a
label
key
value
instead
of,
like
you
said,
the
two
arguments
but
like
because
because
we
added
the
infer
function
to
the
label
values
as
well
right,
so
you
could
just
say
infer
that
you
could
pass
the
same
arguments
if
you
wanted
to
do
that
or
yeah
so
like
that,
doesn't
make
any
sense
but
like
having
which
one.
I
honestly,
the
set
attributes
just
had
slight
advantage.
D
If
you
wanted
to
add
a
bulk
and
you
already
had
them
in
a
a
slice,
because
we
have
other
places
that
you
can
pass
slices
of
key
values
around.
That
was
where
I
was
thinking
about
it,
but
yeah
yeah
didn't
seem
like
too
big
a
difference
to
me.
Obviously,.
D
Fine
cool,
then
the
last
one
in
the
main
go
repo.
This
is
around
the
baggage
api,
a
rehash.
I
already
put
open
a
pr
to
try
to
do
this
move
prior
and,
of
course,
anthony
asked
like
a
one-line
comments
and
it
completely
derailed
my
thinking
on
the
entire
subject,
which
is
always
my
favorite.
So
this
is
a
review
of
that
and
it
includes
a
new
top
level
pac
top-level
file,
which
adds
a
baggage
api
itself.
What
what
happened
is
in
that
move?
D
We
realized
again
kind
of
similar
to
the
propagators
api
that
we
were
just
talking
about.
It
was
not
really
conforming
anymore
to
the
specification,
in
fact
again
probably
predated
the
specification
given.
This
was
written
as
a
one
of
the
first
translations
for
the
bridge
for
open
tracing,
and
so
this
is
an
attempt
to
try
to
fix
that.
I
kind
of
like
this
approach,
the
api.
It
adds
a
baggage
api
here,
which
is
probably
good
to
give
a
read
to
the
specification
in
the
process
of
reviewing
this.
D
D
Are
probably
want
to
make
them
more
idiomatic
of
go
and
the
section
names
are
not
requirements
and
naming
strategies,
so
I
think
that's
kind
of
the
only
thing
that
might
be
confusing.
I
laid
that
out
in
the
comments
here
as
to
how
that
actually
looks,
but
what
you
can
do
here.
It
adds
an
api
to
get
the
entire
baggage
back,
I'm
returning
back
as
a
label
set,
which
is
our
canonical
format
that
we're
returning
a
copy
of
labels
in
an
iterative
or
a
way
that
you
can
actually
iterate
over
them.
D
D
I
tried
to
base
this
api
around
the
same
mechanics
that
the
context
package
itself
has.
You
can
also
remove
baggage
values,
which
is
a
part
of
what
our
specification
requires,
and
then
you
can
just
remove
the
baggage
entirely
and
what
this
actually
does.
Is
it
wraps
the
existing
structure?
The
map
structure
that
already
existed
in
the
old
baggage
package
and
the
reason
behind
this
was
the
map
shouldn't
be
exposed
to
the
end
user.
D
It
is
moved
to
an
internal
package,
an
internal
baggage
package.
This
is
to
try
to
hide
this
because
this
this
internal
data
implementation
is,
it
doesn't
implement
the
api.
It's
not
a
part
of
the
api,
it's
not
something
that
should
be
interact
with
the
user.
Half
of
the
comments
on
all
the
functions
were
like
yeah.
This
really
isn't
for
the
end
user
to
be
using
it's
more
for
internal
details
to
to
work
with,
so
this
cleans
that
up
and
it
moves
it
all
into
the
internal
package
worth
reviewing.
D
But
I
think
it
also
is
a
cool
situation
because-
and
I
forgot
to
open
an
issue
on
this-
it
allows
us
the
flexibility
after
ga
to
look
at
this
and
do
things
like
unifying
the
storage
right
now.
The
map
is
like
really
close
to
the
label
set
itself
and
they
probably
need
to
be
unified
into
some
sort
of
unified
storage.
You
know,
otherwise
you
see
translation
functions
that
are
that
are
of
this
form
here
but
like.
D
D
E
So
I
haven't
looked
at
this
in
detail,
but
just
looking
at
this
api,
real
quick,
I
think
this
is
good.
This
is
more
in
line
with
what
I
was
thinking
when
I
was
asking
those
questions
about.
You
know
the
the
map
and
those
things
kind
of
not
sitting
right
in
the
propagators
package.
E
This,
I
think,
fits
much
better.
The
the
functions
all
indicate
clearly
what
they're
doing
what
they're
operating
on
yeah.
This
is
good
cool.
D
Yeah,
that's
positive
feedback.
I
imagine
you'll,
probably
look
deeper
into
it
for
sure,
but
yeah
cool
45
double
check,
nothing
else
to
add
to
the
agenda.
We
can
keep
cranking
on
this
out
of
the
open,
telemetry
contrib
prs.
I
don't
think
we're
gonna
be
able
to
get
through
all
of
these
in
the
next
15
minutes.
And
honestly,
I
want
to
give
you
guys,
like
five
minutes-
probably
10
minutes
afterwards
to
switch
up
because
I'll
be
getting
sometimes
running
along.
D
Is
there
anything
in
this
one
that
anyone
in
particular
wants
to
touch
on
this
list
that
I
can
highlight.
D
I
guess:
okay,
I'm
not
hearing
anything.
This
is
the
only
one.
I
think
that
I
kind
of
wanted
to
have
a
little
discussion
on
from
the
group
perspective.
The
other
ones
could
probably
just
use
some
eyes
or
responses
from
the
original
owner.
This
is
a
prototype
that
was
opened
by
one
of
the
interns
I
amazon
or
google.
I
totally
forgot
already,
but
it
was
a
it's
I
don't
know.
We
talked
about
big
changes.
D
Change
over,
you
know
almost
9
000
lines.
It's
a
completely
rework
of
the
sdk,
it's
an
alternate
sdk
in
itself,
and
it
is.
It
has
some
really
good
ideas
in
it
for
dynamic
configuration.
It
allows
the
configurability
of
different
metrics
to
different
configurations
of
the
processors
and
that
kind
of
thing,
so
there's
like
some
really
good
computer
science
going
on
in
this.
D
It's
just
that
at
this
point,
it's
diverged
far
enough
where
things
are
changing
in
the
main
repo
I
I
don't
have
I've
tried
looking
at
this
five
different
times
and
I
I
can't
I
can
get
maybe
a
thousand
lines
into
it
before
I'm
just
overwhelmed
with
the
sheer
volume
of
this
change,
and
I
don't
know
how
we
wanted
to
go
forward
this.
I
left
a
comment
asking
like
what
was
the
plan
on
this,
and
the
original
authors
said.
You
know
that
they're
no
longer
in
the
internship
program.
D
Moving
on,
I
don't
know
if
we
wanted
to
just
close
this
or
if
you
know
use
it
as
a
reference
in
a
future
change.
This
looks
like
something
that
we
may
need
to
take.
Some
feature
sets
from
as
we
go
to
ga,
but
it
also
looks
like
a
lot
of
things
in
here
may
be
things
that
we
need
to
do
after
ga.
So
I
I
didn't.
I
was
wondering
about
other
people's
opinions
on
this
one,
where
it
was.
E
I
I
think,
rather
than
having
this
in
contrib,
it
would
probably
be
best
suited
as
a
separate
repo,
a
separate
sdk
kind
of
like
you
mentioned
right
that
could
be
plugged
in
that.
Has
those
capabilities
basically
fork
the
the
sdk
and
add
on
to
it
from
there,
and
then
we
can
look
at
okay.
If
that
proves
to
be
useful
for
people,
should
we
fold
that
in
at
a
later
date,.
D
Yeah,
that's
actually,
I
think,
a
good
idea
just
holistically
how
we
want
to
like
structure
the
project
going
forward,
I
think
very
similar
to
like
go
packages
and
how
they
kind
of
live.
They
can
live
in
like
a
staging
experimental
area
before
they're,
you
know
considered
more
tenured
or
more
solidified
and
then
eventually,
maybe
even
merging
into
the
the
main
repo
I'm
thinking
of
that.
The
context
package
is,
as
like
a
parenthetical
case.
D
D
Cool
yeah
this
and
this
just
update
two
different
trace
provider
options
for
instrumentation.
These
were
holdovers.
I
think
we
had
a
blanket
one
that
did
this
and
I
don't
know.
I
know
that
the
grpc
one
is
was
probably
moved
over
afterwards.
So
that's
just
it
needed
to
get
changed.
The
macron
is
there's
some
weird
things
coming
out
of
that
lately,
like
I
don't
know
why
some
of
the
things
have
been
kind
of
holding
over.
It
was
one
of
the
earliest
instrumentations.
So
this
is.
This
is
correcting
this
as
well.
D
This
instrumentation
to
use
the
trace
provider
not
tracer
directly
as
an
option,
could
use
some
ties.
If
you
took
a
look
at
the
other
trace
provider
option
ones,
this
is
pretty
straightforward,
I'm
not
going
to
go
into
them!
This
one
here
needs
some
feedback
from
the
original
author.
Probably
don't
want
to
take
a
look
at
that
this
jaeger
prototype
for
the
jager
propagator.
I
haven't
taken
a
look
at
this.
This
came
in
yeah
just
earlier
on
this
week,
but
it
looks
cool.
D
This
is
something
that
I
think
was
not
on
a
top
priority
for
the
ga,
but
a
back
burner
item
and
obviously
some
users
are
excited
to
have
this
included.
It
looks
really
similar
to
the
b3
propagator.
In
fact,
I
think
the
prototype
is
a
copy
paste
and
then
it's
just
been
reworked
to
be
very
similar
to
the
b3
prototype.
So
could
you
surmise?
I
haven't
taken
a
look
at
this.
I
don't
know
if
anybody
has
to
call
it
something
they
want
to
talk
about.
D
Cool
this,
oh,
this
had
a
very
similar
issue
with
the
contrib
or
the
change
log.
Getting
some
added
changes,
look
like
most
of
them
fixed
a
really
straightforward
fix
what
was
happening
here
with
the
echo
instrumentation,
which
returning
two
errors
to
the
air
handler
instead
of
one.
This
just
continues
that
duplicate
can
use
more
eyes
on.
It
looks
pretty
straightforward,
though,.
D
Oh-
and
this
is
just
a
replace
of
371-
there
was
an
issue
with
the
cla
here,
so
this
is
a
a
re
attempt
to
solve
a
bug.
Existing
error
really
straightforward
change
here,
where
it
quotes
the
import
statements.
One
thing
that
I
was
thinking
about
when
I
was
kind
of
redoing
this
was,
I
don't
know
how
to
test
for
this.
E
Yeah,
that
was
something
I
was
wondering
about
when,
when
the
change
came
through
as
well,
I
don't
know
if
there's
a
great
way
to
test
for
it
other
than
maybe
some
creative
gripping
of
the
code
base
during
pre-commit.
D
Yeah,
that's
kind
of
how
I
found
I
like
double
check
to
make
sure
this
wasn't
happening
other
places
but
like
even
then
I
had
like
five
other
cases
and
I
was
like
visually
just
going
like.
Okay,
those
don't
really
count
so
I
yeah
the
creative
gripping
there'd.
Be
some
really.
If
you
have
some
linux
experts
on
the
call
or
unix
experts
on
the
call
you
could
use
some
help.
I
guess
I.
D
Tough
one
yeah
it
was,
it
was
kind
of
an
awkward,
so
yeah
could
just
use
an
approval.
It's
not
mission
critical,
but
cool.
We
did
it
with
nine
eight
minutes
and
fifteen
seconds
left.
So
that's
awesome.
I
don't
know.
A
I
do
have
a
an
additional
question
here,
so
I
had
when
I
at
one
point
I
moved
all
the
contrib
instrumentation
down
a
level
and
things
and
then
I
did
update
the.
A
I
think
it's
the
website,
repo
to
actually
add
those,
as
you
know,
instrumentations
so
they'll
be
listed
in
their
thing.
So
now
that
these
things
have
all
moved
around
to
be
renamed
again,
I'm
guessing
that
those
are
no
longer
pointing
to
the
right
things,
but
I'm
happy
to
go
through
and
redo
that
yeah.
A
A
Awesome
cool
thanks
that
yeah.
I
think
that
I'll
just
create
an
issue
to
say
you
know:
go
through
update
all
the
pointers
from
that
community
website.
D
A
D
Cool
yeah,
thanks
for
bringing
that
up,
I
totally
didn't
think
about
it,
which
are
important
things.
I
think
that.
D
The
more
unlike
the
usability
documentation,
side
of
things,
are
going
to
be
become
really
important,
so
we're
gonna
have
to
do
a
better
job
on
that
at
least
highway.
So
maybe
you
guys
are
already
there
thinking
about
it,
but
yeah
cool,
I'm
cool.
Well
anything
else
from
anybody
else.
Stop
sharing
at
this.
D
C
I'm
about
to
start
integrating
the
sdk
into
another
program
of
mine,
which
I
think
I've
I
haven't
tried
since
the
0.6
release
something
so
I'm
expecting
none
of
my
previous
code
to
work.
A
E
Yeah
I've
got
a
couple
at
0.9
that
I
need
to
update
that'll
be
fun.
E
D
I
know
all
right,
it's,
I
think.
If
that's
I've
been
talking
a
lot
of
people
about
this
one
lately,
I
I
think.
D
Of
really
positive
changes,
I've
gotten
a
lot
of
feedback
from
internal
to
new
relic
people
are
excited
to
see
the
direction
that
we're
taking
things,
but
also
external
jana
from
google
was
back
in
talking
a
little
bit
about
the
positive
direction,
so
I
think,
there's
some
positive
direction
of
the
user
base.
I
think
the
main
critique
that
I
hear
a
lot
lately
is
just
the
instability,
because
we
are
making
a
lot
of
changes,
so
I
am
excited
to
to
get
those
changes
in
so
that
we
can
build
up
some
street
cred.
D
Yeah
right
yeah
but
yeah.
I
I
think
it's
going
to
be
really
critical,
because
I
mean,
as
has
been
stated
before
in
this
meeting,
like
as
we
go
to
the
ga
release
like
that
is
what
we're
telling
people
to
migrate
from
open
census
and
open
telemetry
to
and
if
it
doesn't
include,
you
know
improvements
if
it
doesn't
look
better.
If
it's
not
a
use,
a
better
feel,
it
doesn't
have
features
that
aren't
in
the
other
languages.
D
There's
not
much
impetus
to
make
that
migration
right
and
so
other
than
the
community
just
saying
to
do
it
right
but
like
if
it's
a
big
overhead
like
it's,
not
really.
You
know
you
want
to
have
reasons
to
us.
I
want
to
make
that.
C
D
Positive
change
and
make
people
desirable
to
do
that
so
yeah
yeah,
well
cool
and
yeah.
It's
not
just
me
like
it's
all
of
us
working
together
to
make
that
happen,
so
definitely
important
to
say
that
everyone
yeah,
I
wanna,
take
my
five
minutes.
The
metric
saves
coming
up
and
I
need
to
get
some
water.
So
it's
good
seeing
everyone
thanks
for
joining
and
we'll
see
y'all
virtually
if
you
have
time,
take
a
look,
some
of
the
pr's
otherwise
we'll
see
you
next
week.