►
From YouTube: 2020-10-06 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
C
D
E
Start
how
else
do
you
have
right
access
to
the
calendar?
Can
you
repeat
the
question?
Do
you
have
right
access
to
the
calendar,
the
open,
telemetry
public?
Yes,
yes,
I
do
you
at
the
six-pack
meeting
there
because
it
vanished.
E
F
F
D
Well,
we
updated
the
event.
I
think
it's
done
now.
No
or
do
you
think
there's
anything
else
you
need
to
do
now.
D
Topics,
oh
yeah,
I
mean
usually
andrew,
gives
his
you
know
summary
of
what
has
been
happening,
so
we
can
start
with
that
and
then
we
can
get
into
the
actual
discussion.
C
C
It
okay,
all
right.
The
first
one
is
just
an
fyi
from
maintainers
meeting
the
topic
of
swapping
meeting
times.
It's
been
mixed,
so
decisions
no
swap
we
just
keep
the
same
schedule
that
we
got
going,
there's
just
too
many
conflicts
so
on
to
the
triage
of
new
issues.
B
D
Exactly
so
to
me,
this
seems
like
required
for
gna
both
walk
down
the
ground
and
every
anybody
else
is
fine.
C
Okay,
so
if
it's
required
for
ga
right
now
by
default,
I'm
putting
the
priority
one,
because
that's
we've
scrubbed
everything
else
out
of
it.
P2S
p3s
are
allowed
for
ga
or
allowed
for
ga
or
move
to
after
ga
based
on
previous
triage
sessions.
Is
there
an
area
this
one
would
be
suitable.
H
B
B
B
So
anyway,
yes,
carlos,
I
do
think
they
overlap
a
lot.
I
mean,
I
think
our
baggage
is
just
not
properly
specified
at
the
moment.
Okay,.
E
C
E
E
G
J
Yeah
I
fight
this.
I
think
this
should
actually
be
required
for
ga
that
we
decide
something.
J
C
So
in
general
I
I'm
trying
to
keep
the
party
once
just
for
the
required
for
j,
so
there's
no
mix
up
at
all
as
to
what
the
party
so
I'll
say.
This
is
probably
two
that's
the
highest
that
I
recommend
for
allow:
okay,
okay,.
C
Okay,
cool
that
helps
clear
all
of
the
issues
that
we're
talking
about
here.
Well,
I
can
use
the
triage
session
in
order
to
take
your
prioritization
for
allowed
for
gaa
later
in
the
week.
That
seems
to
be
lower
priority,
and
so
that
brings
well.
C
This
was
the
breakdown
before
we
did
the
triage,
but
compared
from
last
week,
more
to
do's
in
the
column,
this
was
mostly
because
of
metrics
labels,
issues
that
had
the
spec
metrics
labels
triaged,
and
that's
why
this
number
bumped
up,
but
we
have
got
a
few
more
in
the
ones
related
to
the
trace,
spec,
that's
blocking
for
the
freeze
now
that
we
have
triaged,
so
I
think
that's
higher
than
the
three
we've
got
the
six
open
now
that
our
p
ones.
C
D
B
On
the
baggage,
stuff,
yeah,
so
there's
two
main
issues,
and
one
of
them
is
related
to
implementing
the
w3c
propagator
and
the
other
is
related
just
to
the
general
structure
of
the
baggage
spec.
With
regards
to
the
w3c
propagator
w3c,
I
know
it's
not.
The
spec
is
not
complete,
but
it
is
in.
At
least
I
think
it's
been
stable
for
at
least
a
little
while
specifies
metadata,
although
with
no
semantic
information
associated
with
the
metadata,
our
spec
does
not
currently
have
a
spot
for
metadata
at
all.
B
So
that
means
that
implementing
a
propagator
is,
at
the
very
least
under
defined
and
at
the
very
end,
the
worst
impossible.
So
we
could
we
mean
there's,
there's
various
options
we
could
do
here.
I
don't
know
what
the
right
answer
is
for
right
now,
whether
we
introduce
metadata
or
we
just
kind
of
drop
the
metadata
or
we
cram
the
metadata
into
the
value.
Anyway,
there
are
options.
B
It
would
be
great
if
someone
who
was
more
intimately
involved
with
the
w3c
effort
could
take
this
on
and
get
our
get
the
at
least
the
propagator
implementation
defined
in
the
specs.
So
implementers
know
how
to
do
it.
L
I
was
gonna
say
as
far
as
open
telemetry
goes.
I
I
was.
I
was
going
under
the
assumption
that
that
metadata
would
just
be
kind
of
undefined
and
unused
for
now
and
essentially
dropped.
L
I,
I
guess
we
should
probably
think
about
what
that
means
for
for
propagating
outbound,
but
I
think
it
might
be
reserved
for
future
use
like
baggage
way
back
in
the
beginning
of
open,
telemetry
was
called
distributed
context
and
when
we
had
distributed
context
it
had,
it
did
have
some
metadata
like
how
how
many
hops
should
this
thing
be
propagated
and
that
stuff
disappeared
at
some
point,
so
I
could
see
like
wanting
to
have
that
stuff
come
back
in
and
having
that
live
like
in
in
the
metadata
portion
of.
L
Somebody
knows,
I
remember,
there
was
a
debate
around
it
and
it
was.
I
don't
remember
the
exact
reasons,
but
but
this
is
the
thing
that
I
think
would
would
live
in
in
the
metadata.
F
M
N
F
O
Yeah,
this
sort
of
just
got
dropped
out
by.
I
think
the
amount
of
confusion
that
surrounded
it.
We've
talked
about
how
you
could
you
could
have
something.
That's
like
distributed
context.
That
is
more
of
a
semantic
thing
where,
by
saying
I
associate
this
correlation
with
this
spanish
trace
id
that
you,
the
vendor,
can
record
this
locally
and
reconstruct
this
later
downstream.
You
don't
actually
have
to
propagate
it,
because
it
was
a
semantic
statement,
whereas
the
existing,
like
baggage
and
open
tracing,
was
much
more
of
a
user-defined
thing.
O
F
So,
okay,
personally,
I
still
believe
that
I
would
like
to
see
this
option
to
add
things
into
the
baggage
that
are
only
local
to
that
process,
and
I
have
in
mind
for
me,
for
example,
the
receiving
rpc
method
and
package,
because
these
are
these
are
just
properties
of
the
the
current
process
that
this
is
the
incoming
method
that
I'm
executing
right
now.
So
I
can
associate
all
the
spans
and
all
the
metrics
with
that
if
I
want.
F
But
that
being
said,
it's
probably,
as
daniel
pointed
is
not
something
that
we
need
to
to
put
on
the
wire
and
can
be
done
only
on
the
api
level.
I
think
a
decision
about
the
metadata
has
to
come
also
from
from
the
w3c
in
a
way
that
what
can
be
in
that
metadata,
how
can
we
parse
that
metadata?
What
is
the
format
of
that
meaning
and
and
so
on?
B
Yeah,
so
I
don't
know
who
is
a
good
person
to
take
this
issue
and
try
to
at
least
I
mean
I
think
at
the
very
minimum
we
need
to
say
if
metadata
comes
in
with
the
w3c
format,
what
do
we
do
with
it?
B
So
I
think
that
would
kind
of
be
the
minimum
that
we
need
to.
We
need
to
address
on
this
particular
issue,
so
I
don't
know
who
the
right
person
to
assign
this
to
us
but
hard
to
implement
when
we
can't
figure
that
out
at
the
moment.
F
B
F
Is
probably
a
reasonable
solution
for
our
backwards
compatibility
story.
L
Yeah,
I
think
that
makes
sense.
I
think,
at
this
point
in
time,
like
open,
telemetry
isn't
going
to
use
it,
so
I
don't
know
that
we
need
apis
to
interact
with
it,
but
as
long
as
we
propagate
it
and
don't
break
you
know,
downstream
requests
seems
like
a
reasonable
solution.
F
F
L
Yeah,
that's
fine,
I
guess
we
will
have
those
conversations
there.
Just
just
so
we
know
like
is,
is
open,
telemetry
interested
in
possibly
using
the
metadata
like
in
the
future.
O
I
feel
like
we
have
a
used
case,
but
it's
so
confusing
and
we're
still
trying
to
get
to
ga
that
we
should
just
drop
this
for
like
post.
Ga,
like
the
use
case,
is
you
you
want
to
make
a
semantic
meaning
out
of
like
a
trace
attribute
like
for
spans.
We
have
set
attribute,
and
we
know
what
that
means.
We
don't
have
a
trace
set
attribute
and
that's
what
we
can
do
with
this
metadata.
But
let's
do
it
later.
B
All
right,
I'm
happy
to
take
on
writing
up
kind
of
what
we
talked
about
here,
where
we
propagate
but
do
not
assign
any
sort
of
structure
or
meaning
to
the
metadata.
B
Cool
well,
the
other
one
is
a
it's
a
different
kind
of
issue.
The
other
issue
is,
I
think
that
the
the
baggage
api
is
specified
right
now
is
very
weird.
It
makes
the
way
it's
written.
It
makes
you
interact
with
the
context
for
every
single
baggage
attribute.
B
And
this
feels
very
unnatural,
like
if
you
compare
this
to
a
span,
the
equivalent
would
be
the
context
for
every
attribute,
and
that
seems
like
a
very
strange
way
to
structure
the
api.
It'd
be
nice
if
they
were
a
little
bit
more
parallel,
like
baggage,
was
a
thing
that
you
a
first
class
concept
and
not
just
somehow
a
tagged
attribute
list
inside
the
context.
B
B
So
I
don't
know
I
was
chatting
with
tristan
a
little
bit.
It
sounded
like
he
didn't,
implement
it
to
spec
and
java
doesn't
have
an
implemented
to
spec
at
the
moment
either.
We
both
kind
of
both
both
implementations
have
assumed
that
oh,
we
should
have
a
baggage
structure.
That
actually
is
the
thing.
That's
put
wholesale
into
the
context,
so
I
wanted
some
more
opinions
whether
anyone
had
actually
implemented
this
api
as
it
was
spec
or
whether
everyone
just
kind
of
assumed.
We
wanted
something
more
structural
and
ignored
the.
B
D
I
don't
remember
exactly
the
details,
but
I
think
we
wanted
to
make
this
structure
optional,
but
we
failed
to
update
the
specification.
Probably-
and
the
second
thing
is
whether
this
is
still
a
good
idea
or
not
like.
Maybe
we
should
reconsider
making
this
a
structure
for
all
languages.
I
don't
have
a
strong
opinion
on
this.
Oh,
I
think.
F
I
think
this
was
some
idea
floating
from
yuri
who,
who
also
wants
to
to
remove,
span
and
make
all
the
the
span
operations
work
against
the
context
which
don't
get
me
wrong,
maybe
right
to
do.
But
as
long
as
we
keep
a
span
for
trace,
I
think
we
should
have
an
equivalent
in
baggage
called
baggage
or
whatever,
that
has
this
operation
similar
with
the
spam
here
most
focus
on
consistency
between
the
two
apis,
I'm
not
necessarily
seeing
which
version
is
better.
K
The
gosig
recently
updated
their
api
implementation
and
they
did
what
the
api
is
specified.
So
there's
really
no
structure
for
baggage.
That's
exported,
there's,
definitely
an
internal
structure,
that's
kept
with
the
context,
but
there's
a
set
of
functions
that
are
sitting
in
the
api
that
you
can
interact
with
the
package
structure
itself
by
getting
attributes
removing
attributes,
removing
the
baggage
structure
from
the
context
itself
it
ended
up.
K
L
L
If
you
wanted
to
update
multiple
keys
at
once,
it
does
kind
of
have
like
a
a
builder
that
allows
you
to
kind
of
make
multiple
changes
to
your
baggage
before
that
gets
kind
of
committed
into
the
context.
That
makes
sense,
and
then
there
is
also
a
there
is
a
values
method
that
will
return
you
all
the
values
for
the
baggage,
but
that's
really
a
read-only
kind
of
return
of
of
the
baggage.
B
So
it
sounds
like
in
ruby.
You
do
have
the
capability
of
adding
multiple
keys
at
one
time
or
key
value
pairs
at
one
time
and
retrieving
all
of
them,
which
I
don't
think
is
in
the
spec
at
the
moment,
but
doesn't
seem
like
a
bad.
If
we're
going
to
go
with,
this
style
seems
like
it's
a
good,
a
useful
addition
for
performance
from
a
performance
perspective.
L
Yeah
I
felt
like
adding
in
the
builder
kind
of
kept
this
situation,
where
you're
still
only
changing
you're,
making
a
change
to
your
baggage,
but
you're
only
changing
it
in
the
context
once
as
a
result,
you
can
do
kind
of
like
multiple
operations.
B
L
F
Right,
I
think
I
think
sorry,
I
also
think
in
goal
tyler,
you
have
this
label
that
set,
which
is
the
baggage,
because
you
have
a
method
at
line:
25
called
baggage
which
essentially
returns
the
the
object
from
the
context
or
the
entire
thing
from
the
context.
K
Yeah
I
mean,
if
you
want
to
call
it
that
label
set,
is
a
primitive
of
the
language
that
we
use
in
many
other
places
as
well.
So
it's
not
really
confined
to
the
magic
baggage
object,
it's
more
just
a
immutable
set
that
you
can
iterate
over
and
that's
the
format
that
we
return
it
in,
because
it's
a
grouping
of
labeled
key
values
but
yeah.
K
If
you
want
to
think
about
it
that
way,
that
seems
reasonable
and
in
truth,
it's
not
like
in
truth,
there's
an
underlying
structure
implementation,
that's
kind
of
similar
to
the
functionality
of
the
set
that
it's
actually
stored.
As
it's
called
a
map.
It's
an
older
implementation
which
probably
is
going
to
get
changed.
It
was
abstracted
away.
So
it's
not
exported
anymore.
P
K
That's
kind
of
it's
an
api
design
choice
for
probably
the
future
optimization
but
yeah.
If
you
wanna
think
about
the
set
that
sounds
reasonable.
I
mean
it
may
eventually
become
the
underlying
representation
as
well.
K
F
K
Yeah
yeah
exactly
and
we
just
kind
of
tried
to
map
a
lot
of
similar,
go
functionality
like
the
context
package
itself
has
a
you
know,
a
with
with
value
function
for
a
context,
and
so
we,
you
know,
mapped
our
functional
elements
around
something
similar
yeah,
like
I
said
like
it's
go.
So
there's
like
it's
kind
of
a
first-class
idea
in
the
language
as
well.
So
just
a
data
point
for
everybody.
F
F
And
go:
go
can
do
things,
maybe
they're
feel
and
again.
We
should
not
forbid
somebody
to
do
other
things,
but
I
think
I
would
first
first
of
all,
I
would
specify
it
kind
of
in
a
way
we
do
it
for
trains.
L
So
yeah
I'm
trying
to
think
back
to
why
this
all
works
the
way
that
it
does
and
it's
been
a
while
since
I've
worked
on
it.
But
I
feel,
like
part
of
the
reason
for,
like
the
the
weirdness
around
how
baggage
how
these
baggage
apis
work
is
that
I
think
you
don't
just
wanna
hand
off
like
a
mutable
baggage
struct
to
the
user
and
still
have
that
reference
from
your
contacts,
because
I
think,
like
you
want,
you
want.
L
So
that's
why,
at
least
from
from
what
I
remember
of
implementing
this.
This
is
why
it
made
sense
to
have
to
set
the
keys
and
values
one
at
a
time
or
have
like
a
builder,
where
you
kind
of
take
that
current
baggage
transform
it
and
then
kind
of
commit
that
change
like
update,
update
that
by
writing
it
into
a
context.
F
F
L
Yeah
exactly
so
that's
what's
happening
is
you're,
always
kind
of
deriving
the
new
baggage
off
of
another
baggage,
and
you
end
up,
I
think,
returning
a
new
context
for
each
one
of
those
operations
and
it's
up
to
the
user
to
actually
make
that
thing,
the
active
context
or
not,
and
that
way
you
kind
of
preserve,
like
the
scoping
of
of
the
baggage,
which
is.
F
F
L
I
think
you're
probably
right.
I
think
this
is
an
alternative
approach.
I
think
it
it
does
depend
on
what
support
your
language
has
for
immutable
objects.
Some
some
languages
have
pretty
poor
support
for
this,
so
like
the
best
thing
we
end
up
doing
is
making
make
a
deep
copy
of
the
thing
and
then
hand
it.
I
Off
I
see,
let's
see,
I
see
that
problem
and
that's
because.
C
F
F
K
F
I
would
personally,
I
would
we
all
have
structure
and
we
add
a
new
notion
of
an
extension
of
the
api
that
that
essentially
does
what
you
have
right
now,
but
that's
not
the
official
api,
that's
an
extension
of
the
api
that
is
still
provided
by
us
that
works
across
against
context
directly.
So
people
can
use
that
instead
of
of
manipulating
directly
the
object,
because
essentially
what
I'm
asking
you
tyler
in
go
is
to
expose
that
map
object
or
whatever
you
call
it
that
you
have
and
then
and
then
all
this
api
can
be
built.
F
On
top
of
that,
as
you
did
already
proven,
proven
its
work.
But
then,
then
the
raw
api
looks
kind
of
the
same
with
spam
and
I
think
maybe
maybe
we
should
do
the
same
thing
for
tracing
as
well,
have
a
have
a
extension
api
that
allows
you
to
say
set
attribute,
pass
the
context
and
the
attribute
and
don't
don't
worry
about
grabbing
the
spam
from
the
context
and
so
on.
K
F
I
think
I
think
that's
that's
a
reasonable
thing
to
do
to
have
an
extension
of
the
the
raw
api.
I
don't
know
if,
if
we
try
to
achieve
more
consistency
across
languages,
if
we
believe
this
is
not
required,
I'm
fine.
This
is
my.
This
is
my
preference
so
far,
but
I
want
to
hear
others-
and
I
hear
you
tyler,
I
think
for
go.
It
feels
more
natural
to
use
these
apis
that
you
have
right
now,
but
my
my
my
thoughts
are
more
about
about
consistency
between
languages
and
between
apis.
K
I
I
don't
imagine
there's
too
many
people
out
there
that
are
working
across
languages,
so
if
they
pick
up
the
idioms
of
a
particular
language
and
they
find
that
the
package
conforms
to
the
idioms
of
that
language
they're
going
to
be,
you
know
easy
to
pick
that
up
and
then
I
really
imagine
that
there's
not
going
to
be
much
friction
if
they
go
from
an
imperative
language
to
more
of
a
functional
language
or
something
like
that
they're
going
to
expect
some
sort
of
differences
across
those
two
different
languages
so
having
different
structure
types
having
different
like
interactions
with
the
api,
seem
reasonable
to
me
to
having
those
different
distinctions
but,
like
I
said
we
can
just
work
it
out.
K
I
I
we
just
changed
this,
so
I
was
just
kind
of
like
you
know.
I
thought
this
was
done,
so
I
you
know-
and
this
is
just
like
once
we
get
this
out-
then
we
have.
Our
users
are
gonna,
expect
some
sort
of
stability
and
we're
going
to
change
it
again,
and
so
I
was
just
like.
F
Yeah,
I
would
also
challenge:
why
isn't
that
it
is
not
in
a
package
called,
I
mean
in
sub
that
in
the
directory
called
api.
K
F
K
F
Right
now,
but
yeah,
okay,
okay,
perfect,
no
make
sense,
only
thing
that
I
in
my
mind,
consistency
like
if
everything
moves
there.
That's
you
you
and
I
are
in
the
same
place.
Yep.
A
So
bob
didn't
just
to
this
is
our
later
just
to
follow
up
on
your
question
again.
Is
there
something
written
that
is
being
discussed
about
consistency
and
moving
to
to
this?
You
know
consistently
to
the
same
place
like
go
is
from
what
tyler
mentioned,
because
I
I
mean:
where
do
you
follow
these
conversations.
F
I
mean
I
don't
know
if
tyler
has
an
issue
for
that,
but
I
would
imagine
that
issue
like
in
the
rep
or
not
personal
issues.
F
So,
but
I
think
I
think
it's
reasonable
at
the
language
level
to
have
consistencies
between
don't
know,
we
need
to
write
it
down,
but
I
would
expect
that
at
the
language
level,
somebody
will
not
put
the
trace
api
in
somewhere
in
the
api,
completely
different
path
and
different
ways
of
organizing
these.
That's
that's
why
I
was
asking
this
question
no.
A
F
I
think
in
the
specs
there
is
a
structure
proposed,
so
so
I
think
let
me
find
that
there
is
something
in
the
library
layout.
Yes,
there
is
a
library
layout
thing
that
talks
about
some
kind
of
consistency
right.
A
K
I
can
just
speak
for
go
sorry.
I
think
we're
getting
kicked
on
time,
because
we
are
really
focusing.
F
So
who
wants
to
take
a
step
trying
to
make
the
specs
look
a
bit
more
like
trades
and
then
and
then
we
can
have
a
decision
on
the
end
of
the
thing
that
an
alternative
can
or
cannot
be
directly
using
context,
but
I
I
would
like
at
least
let's
start
making
specs
look
a
bit
more
like
trade
and
then
and
then
the
decision
of
not
exposing
this
structure,
api
and
exposing
just
functions
on
context
can
be
a
separate
decision
that
we
can
make
at
the
bottom
of
the
document
like
from
specification
perspective,
I
would
like
to
see
it
structure
a
bit
more
like
trace
and
then
and
then
from
implementation
perspective.
F
Yes,
so
the
second
issue
is
more
like:
do
we
ask
everyone
to
have
the
structured
public
and
people
can
work
directly
on
the
structure,
or
do
we
allow
languages
to
hide
the
structure
and
work
on
context,
the
same
thing
as
kodi
and
I'm
happy
to
to
to
have
that
discussion
separately,
and
I
see
benefits
of
that.
But
again
it's.
I
think
it's
important.
D
So
I'm
having
a
short
week,
but
if
I
could
work
on
this
next
week,
if
nobody
took
it
by
then.
F
Okay,
and
also
I
will
I
would
encourage
everyone
to
look
at
the
java
implementation,
which
is
a
bit
structured
and
to
look
at
the
goal.
Implementation,
which
is
using
directions
and
maybe
try
to
use
it
or
whatever
and
get
feedback
collect
feedback
about
the
the
final
decision
of
which
way
we
allow
or
not
to
do
stuff.
B
I'm
not
sure
I
would
look
at
the
java
implementation
right
now,
because
right
now
it's
implemented
only
in
the
sdk
and
the
api
is
a
no
op
implementation.
It's
not
about
implementation.
F
It's
the
api,
I'm
like
trying
to
use
the
api,
which
is
the
structure
case.
We
do
have
a
an
object,
called
baggage.
It
has
all
this
functionality
and
so
on
again.
D
J
The
next
point
is
just
a
question
that
is
in
the
agenda.
I
made
a
pr
to
clarify
the
behavior
of
span.end
and
one
point
I
added
there.
Actually
only
as
a
note,
I
think,
is
that,
since
ended
span
is
usually
not
recording
anymore,
it
is
recording,
should
return
false
after
the
span
is
ended,
except
if
you
have
like
a
streaming
a
sdk
that
doesn't
know
if
it's
ended,
then
it's
okay
to
return
true,
but
generally,
this
recording
should
return
false.
If
the
span
is
ended,
can
we.
J
I'm
not
sure
I
mean
is
recording
or
is
ended.
It
might
be
implementable
as
an
atomic,
for
example,
and
actually
it's
probably
okay.
If
you
use
an
a
lazy
set,
for
example
in
java,
because
it
doesn't
have
to
be
that
exact.
J
F
And
also
also
think
about
think
about
if
this
span
is
in
two
contexts
at
the
same
time,
in
two
different
threads
yeah
and
some
of
them,
one
of
them
change,
does
end
in
in
languages
like
like
java.
There
is
no
problem,
you
have
an
atomic,
it's
fine,
but
in
english,
like
c
plus
plus,
you
require
them
to
use
a
sharepointer
because
they
have
to
share
some
memory.
They
cannot
just
copy
the
the
the
structures
that
they
need.
J
That
that
should
not
be
an
issue,
because
if
you,
if
you
support,
for
example,
setting
attributes
on
two
threads
separately,
you
will
have
some
synchronization
anyway
and
then
the
synchronization
for
israel
recording
shouldn't
be,
should
be
a
non-issue.
Actually,
I
think,
if
you
call
is
recording
you
will
afterwards
call
set
attribute,
probably
because
otherwise
it
doesn't
make
sense.
The
core
is
recording.
If
you
do
nothing
with
it
with
it,
and
for
this
set
attribute,
you
will
need
synchronization
anyway.
So
so
I'm
not
sure
if
this
is
a
good
argument.
J
F
Can
we
maybe
make
this
may
instead
of
I
mean
shoot,
is
fine
because
it's
not
must
so
yeah
I
find
it
should
and
in
languages
which
is
easy
to
achieve
this.
I
bet
there
are
languages
like
I
I
don't
know.
F
Maybe
erlang
has
a
problem
or
others
that
I
don't
know
of.
N
J
Yeah,
I
I
can
reword
this
a
bit
to
make
a
shoot,
because
right
now
I've
written
a
note.
But
with
these
new
considerations
I
should
might
be
better
yeah.
F
If
that
causes
more
performance
problems
and
and
stuff,
they
use
the
use
of
atomic
shouldn't,
be
a
big
problem
because,
because
I
bet
is
changing
only
once
so
the
cash
on
x86,
I
think
the
cache
will
will
will
handle
it
very
nicely
and
it
will
just
cause
one
memory
barrier
whenever
you
change
it,
which
is
already
caused
whenever
you
do
a
and
you
already
do
a
mutex
and
you
change
the
is
ended
like
variable
stuff
that
you
were
checking
before.
I
think
I
think
this
may
be
actually
better.
F
D
P
So
this
issue
was
opened
a
few
weeks
ago
about
consolidating
the
concepts
of
labels
and
attributes.
These
are
similar.
There's
definitely
some
nuance
here,
but
by
having
them
be
named
differently,
we're
forcing
every
single
user
to
think
about
the
nuance
and
why
they're
different-
and
I
wonder,
if
that's
necessary
and
then
an
additional
reason.
This
came
up
is
for
users
who
are
using
both
tracing
and
metrics.
K
Just
for
the
record,
I
know
that
it's
been
kind
of
discussed
in
this
meeting
before,
but
I
also
share
that
same
sentiment
that
I'd
like
to
see
these
unified.
I
don't
really
have
a
feeling
one
way
or
the
other.
I
do
know
that,
as
I'm
seeing
some
duress
go
across
some
people's
faces
in
some
languages,
they
have
distinct
semantic
meanings
in
their
minds.
I
don't
know
if
that
can
be
resolved
or.
E
K
K
K
Sure
I
think
that
that
seems
reasonable.
You
know
I,
if,
if
you
don't
want
that,
I
think
the
exporter
itself
could
have
a
string
conversion
of
an
n64.
That
seems
completely
fine.
You
know
having
a
specific
bit
like
type
is
yeah.
I
I
mean.
Maybe
it
doesn't
make
sense
from
a
performance
standpoint,
because
the
overall
idea
is,
you
know,
communicated
number,
but
if
you
want
to
communicate
that
number
as
a
stringer,
you
want
to
communicate
the
number
as
a
an
n64
and
32
and
8..
I
mean
it's
all
fine
to
me.
K
At
the
end
of
the
day,
it's
just
you're
trying
to
communicate
a
key
value
set,
and
I
think
that
that's
kind
of
a
the
takeaway
from
the
user's
standpoint.
The
user
looks
at
that
and
they
go
like
okay
cool.
I
have
just
a
mapping
and
that
mapping
is
the
same
in
the
attributes
and
it's
the
same
in
the
labels.
F
That's
one
of
the
the
thing
the
other
one
is
in
in
in
other
languages
that
are
not
as
nice
as
gold,
this
every
encapsulation
or
generic
like
this
forces.
Yet
another
allocations
for
us.
If
we
just
use
strings,
is
it's
easier.
O
Yeah,
I
was
going
to
say
the
same.
We
could
we
could
rename
the
concept
of
attribute
and
label
without
changing
the
protocol
and
just
say,
metrics
are
required
to
course
label
values
string,
which
is
a
little
bit
of
a
blemish,
but
it
solves
the
question
that
k
was-
and
donna
has
pointed
out
and
many
others
actually.
F
O
F
Okay,
for
me,
for
my
conversation,
okay,
for
me,
the
most
interesting
part
is
the
type
that
the
name,
the
unifying
the
name,
comes
with
the
fact
that
we
need
to
support
all
the
types
everywhere,
and
that's
that's
where
I
have
struggled
and
that's
why
I
was
pushing
to
have
different
names
because
they
have
different
meaning
one.