►
From YouTube: 2020-10-13 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
C
D
D
E
E
E
E
E
Okay,
let's
start,
I
see
enough
items,
don't
forget
to
add
yourselves
later
or
now
to
the
attendee
list.
Okay,
I
guess
I
see
andre
that
you
changed
your
usual
time
box
to
the
end.
Is
that
correct.
C
E
C
Okay,
so
this
morning,
I
believe
we
got
three
issues.
That's
come
in
since
last
friday's
triage
issue
scrub
meeting,
so
we
just
need
to
go
over
those
in
order
to
have
a
priority
for
them.
C
B
Editorial
change
make,
making
the
readme
more
accessible,
so
I'd,
say:
p3.
B
I
think
we
could
have
a
few
more
opinions
on
that
one.
If
we
wanted
to
change
it,
we
should
do
so
before
g8,
because
this
is
about
the
parent
and
child
relationship
and
opposed
to
attributes
where
we
can
introduce
a
new
attribute
with
a
different
name
and
not
use
the
old
one
or
something
like
that.
We
don't
have
any
by
the
record
we
mean
so.
B
What's
that
yeah,
so
we
don't
have
any
means
of
versioning
if
we
change
the
semantics
of
the
parent-child
relationship
here,
and
so
we
should
consider
doing
or
discussing
it
before
ga.
E
There
were
some
related,
it's
like
the
relative
changes
regarding
the
child
or
follows
from
apart
from
open
tracing,
and
I
don't
know
if
it's
the
same
situation
but
based
on
the
fact
that
it
could.
We
could
break
things,
we
decided
to
leave
them,
for
you
know,
post
ga,
and
I
need
to
think
about
this
more.
But
after
a
first
read
my
my
feeling
is
it's
mostly
a
post,
ga
thing
but
yeah.
I
would
like
to
hear
other
opinions.
B
Yeah,
so
if
it
is
about
links,
we
could
introduce
a
link
attribute
after
ga
to
describe
the
relationship
further.
But
if
it
is
about
parent
and
child,
then
we
we
change
the
meaning
there.
Then
then
we
have
no
way
of
knowing
what
it
means,
because
we
don't
have
versioning
for
something
like
that.
So
I
would
welcome
some
some
opinions
on
that.
Ideally
before
ga
or
we
stick
with
what
we.
B
C
C
It's
allowed
for
gaa
the
way
we've
been
categorizing.
It
is
it's
editorial
change
and
party
three
coming
in
as
like.
Well,
if
there's
a
party
to
one
and
allowed
for
ga,
that
would
be
more
desirable
than
priority
three
for
a
lot
of
4ga,
but
it
can
come
in
4g,
but
it's
not
going
to
block
ga,
but
it
expects
to
be
editorial
only
not
like
change
implementation.
E
C
F
E
No
well,
I
I'm
not
sure,
because
this
is
more
like
about
making
the
decision,
so
we
need
somebody
I
don't
know
I
could
prefer
to
have
based
on
the
fact
that
he's
the
elder
of
this
issue
to
help
somebody
else,
because
probably
we'll
have
to
make
some
hard
choice
there.
So.
G
G
So
the
trace
context
back
is
trying
to
send
the
the
trace
id
as
a
as
a
header
of
each
individual
amqp
message
and
that's
a
clear
indication
that
people
want
the
same
trace
id
to
be
used.
Instead
of
saying
this
is
a
link
scenario,
and
I
I
believe
there
there
are
other
scenarios
where
people
do
batching.
For
example,
you
receive
10
messages
in
each
batch
and
it
doesn't
make
sense
to
take
any
trace
id
from
individual
message.
G
G
And
I,
if
I
remember
correctly
like
in
the
trace
context,
say
like
people
have
have
spent
a
lot
of
time
on
this,
so
based
on
the
complexity,
I
think
it's
hard
to
get
any
conclusion
before
and
of
this
year.
A
I
don't
know
if
trace
context
has
spent
a
huge
amount
of
cause
like
I'm
on
that
group.
I
don't
know
if
the
w3c
trace
context
group
has
spent
a
whole
lot
of
time
on
this,
or
do
you
mean
the
open,
telemetry
trace
context.
G
I
Yeah,
there
definitely
is
a
group
working
on
this.
They
meet
weekly.
I
was
just
looking
at
the
meeting
notes
to
see
if
any
regular,
open,
telemetry
folks
show
up
to
the
meetings
regularly
and
victor
suarez.
I
don't
know
if
he's
on
the
call
today,
but
I
know
he
is
involved
in
open,
telemetry
and
justin
foote
is
has
been
related,
but
the
most
of
that
discussion
is
around
binary
protocols,
not
messaging
specifically,
but
yeah.
F
I
Proto
messaging
protocols
happen
to
be
binary
fairly
often,
I
guess
so
there's
a
lot
of
overlap,
but
it's
not
specifically
about
messaging.
It's
more
about
binary
in
general,.
J
G
Yeah,
so
the
focus
of
the
trace
contact
spec
is
on
the
wire
protocol
itself.
However,
there's
a
problem,
for
example,
if
your
receiver,
you
receive
10
messages
from
amqp
as
a
batch,
each
of
them
has
a
trace
id.
Then
what
do
you
do
and-
and
I
I
think
we
need
some
some
common
understanding
there
or
we
can
say
like
like
the.
J
A
A
Sdk
but
riley,
I
do
agree
with
what
you
said
were
I
I
think
we
can
do
this
as
a
post,
ga
thing
yeah
even.
A
A
Yeah,
that's
true!
Okay,
in
that
case
justin,
do
you
want
to
work
on
this.
C
Cool
sorry
leave
the
conversation
in
market
as
postg8,
so
oops.
G
B
From
I
mean
from
an
instrumentation
and
consumer
point
of
view,
that's
pretty
much
an
api
because
it
it
specifies
the
semantics
of
what
you
get
there.
Of
course
you
it
would
not
change,
method
names
or
something
like
that.
A
I
I
just
don't
see
it
being
feasible
to
get
this
in
before
ga,
and
I
don't
see
it
being
that
high
impact
for
pre
ga
and
even,
if
involves
some
changes,
we'll
have
to
do
it
as
part
of
our
post.
Ga
versioning
strategy.
D
So
messaging
is
a
very
important
thing,
but
I
I
do
also
understand
that
we
will
not
be
able
to
cover
all
the
conventions
before
ge,
so
we
have
to
to
to
be
prepared.
For
this
I
mean
from
the
api
point
of
view
from
open
terminal
api.
We
should
have
everything
ready
for
g,
but
I
I
cannot
see
all
the
possible
conventions
or
all
the
exactly
the
cover
before
that
so
yeah
yeah.
I
agree
so.
C
F
E
D
I
don't
know
based
on
the
suggestion
of
moving
the
method,
it's
a
breaking
change,
so
it
has
to
be
before
ga,
but
the
way
how
I
would
resolve
it
is
probably
simply
remove
the
whole
concept
of
propagated
span
and
just
tell
people.
You
know
what
come
up
with
your
own
solution
and
everyone
will
come
up
with
similar
solution
and
I
feel,
like
this
propagated
span
is
used
against
us
a
lot
more
than
expected.
K
I'm
personally
a
fan
of
the
propagated
span.
I
am
not
a
fan
of
this
change
because
for
several
of
the
languages
I
work
in
the
our
no
op
spans
for
the
default
implementation
worked
perfectly
fine
as
the
propagated
span.
This
change
would
make
that
no
longer
the
case.
D
E
D
The
propagated
span
is
just
a
span
that
propagates
the
ids
and
doesn't
do
anything
kind
of
not
really
a
knob.
It's
just
a
knob,
plus
the
propagation
part
and
people
can
use
this
in
different.
Other
scenarios
is
not
only
this
specific
thing
between
the
propagator
and
the
first
span
created
on
that
service.
D
For
example,
propagated
span
can
be
used
if
somebody
decides
to
not
sample
a
trace,
but
they
still
want
to
propagate
ids.
I
see
I
see
the
same
concept
used
there
correct,
because
it's
still
propagation
of
the
ids
and
and
the
properties,
but
we
don't
record
anything
so
propagated
span-
has
way
more
usefulness
than
than
just
this
one.
It
happens
that
we
recommend
to
be
used
between
between
these,
maybe
maybe
the
way
how
I
we
should
solve
it
and
maybe
solve
the
the
the
inconsistencies.
D
The
the
the
things
that
are
not
clear
in
the
specs
is
by
explaining
better
what
is
propagating
span
because,
right
now
we
introduce
it
that
concept
only
for
for
the
pro
for
the
solving
our
proper
tr,
our
transfer
of
the
spam
context
between
between
propagators
and
the
in
the
instrumentation.
D
D
This
change,
but
we
need
to
just
to
clear,
clarify
the
property
span
and
everything,
because
this
is
not
the
first
time
I
see
that
propagated
span
coming
up
in
discussions
and-
and
I
I
would
like
to
clarify
that
it
means
that
it's
not
clear.
It
means
that
we
do
not
explain
it
correctly.
It
means
that
there
is
something
that
we
need
to
do
for
them.
C
B
D
C
Okay,
how
about
I
follow
up
with
finish
sorry.
B
C
Thank
you
I'll
just
do
a
quick
run
by
of
where
we
are
with
the
status
of
the
p1
issues
for
trace
spec.
We
have
three
in
the
to
do
four
in
progress
with
prs
up
on
it.
We've
closed
one
of
them
and
we've
got
some
important
items
on
here
that
I
will
show
my
time
for,
but
I
have
an
fyi,
it's
just
repeating
stuff
from
the
maintainers.
E
The
agenda,
thank
you.
So
much.
Okay,
sweet!
Okay!
Let's
jump
to
the
other
items,
then
there
was
a
finding
issue
from
last
week
k.
I
don't
know
if
case
here,
yeah,
I'm
here,
oh
perfect,.
L
Yeah
we
talked
about
this
at
the
very
end
last
week
about
consolidating
attribute
and
label,
but
josh
had
written
a
very
thoughtful
comment
on
this
issue.
So
maybe
josh
did
you
want
to
take
over
here.
M
Hi,
well,
I
wrote
what
I
thought
and
some
historical
perspective
on
it
and
I
wrote
my
opinion,
so
I
don't
know
if
I
have
any
more
to
say
than
that,
I
do
think
we
should
come
up
with
one
term.
I
do
think
it's
a
little
arbitrary
and
if,
if
the
group
decides
that
we
can't
change
terms
at
this
point,
then
we
we
have
no
decisions
to
make.
I
think
so.
E
So
I
don't
know
if
anybody's
opposed
to
that
change,
which
one
the
one
about
making
labels
attributes
for
metrics.
M
I
propose
I
mean
I
I
didn't
really
quite
propose
that
I
I
I
think
in
an
ideal
world,
I
would
propose
that
I
don't
think
this
is
an
ideal
world
and
I
I
put
in
the
end
of
my
legacy,
comment
that
I
think
we're
going
to
keep
having
this
problem.
M
If,
if
we
aren't
careful,
there's
an
intention
to
add
logging
apis
and
signals
to
open
telemetry
soon
after
ga,
I
think-
and
and
are
we
going
to
come
up
with
another
term
there
are
we
going
to
apply
the
word
attributes
to
logs
we're
going
to
have
to
make
that
decision?
Now
I
think,
and
and
we
may
we
we
may
end
up
choosing
attribute-
I
don't
think
it's
the
best
term,
but
it's
okay.
M
We
discussed
it
as
a
metric,
everyone's
okay,
with
just
whatever
it
takes
to
get
us
to
ga,
but
I
do
think
there's
an
opportunity
at
this
point.
If
we're
going
to
change
fan
context
to
spam
identifiers,
we
could
change
attributes
to
labels.
That's
my
position.
D
So,
for
example,
logs
for
sure
we're
gonna,
add
the
concept
of
a
map
in
the
attributes,
so
attributes
should
support
and
another
map
as
a
value.
How?
How
are
you
gonna
do
that
in
labels?
Are
you
gonna,
flatten
them.
M
I
didn't
address
that
in
my
comment.
I
I
just
want
to
say
adjust
that
in
the
comment.
I
don't
think
this
is
a
big
deal
and
I
would
try
to
point
out
because
it's
semantics
of
it
like
there's
no
difference
in
semantics
for
like
oh,
I
have
a
map,
valued
attribute
label
thing
I
did
I
you
know.
I
said
something
about
potentially
calling
that
I
forget
what
the
word
I
used
but
unrepresentable.
M
N
Yeah,
I
think
that
just
josh's,
maybe
being
a
little
bit
modest,
it's
worth
reading,
it's
also
a
little
bit
of
a
novella
as
well
in
the
issue.
Yeah.
Sorry
about
that!
No!
No!
I
I
really.
I
actually
think
it's
really
great,
because
it's
it's
kind
of
a
research
paper.
N
He
goes
back
into
talking
about
how
the
project
was
started,
with
open
census
and
open
tracing
and
how
that
inherited
terms
like
tag
and
attributes
and
labels
all
already
in
the
mix,
and
so
there
was
already
a
point
of
contention
and
then
how
that
how
we
came
to
the
current
state
of
affairs.
I
think
he
points
out
a
good.
You
know
summary
of
both
sides
and
the
fact
that
label
is
something
that's
inherited
from
open
census,
as
well
as
prometheus,
datadogs.cssd
use
tags
in
the
metrics
world
as
well.
N
There's
already
overloading
of
terms
here-
and
I
guess
it's
just
really
finding
you
know
some
sort
of
accord
in
that
respect,
and
then
it's
pointed
out
that
a
large
amount
of
the
api
is
designed
around
semantics
like
it's
something
that
he
points
out.
N
We
inherited
from
open,
tracing
and
likely
other
places
not
unique
to
open
tracing,
but
like
the
idea
being
that
the
api,
being
a
semantic
terms,
is
really
critical
and
having
those
terms
then
separated
off
into
a
completely
separate
sdk
is,
is
by
design
something
that
we
allow
for
the
customizability.
N
I
think
it's
a
good
point,
because
if
we're
making
a
distinction
around,
you
know
maybe
the
type
restriction
of
what
these
things
can
be
based
on
the
terms
that's
not
really
useful
to
the
user.
At
the
end
of
the
day,
the
user
wants
a
semantic
term
coming
in
from
the
api
that
they
can
use.
That's
cohesively,
a
concept,
that's
uniform
right
and
passing
that
along
and
as
josh
points
out
correctly.
That,
like
you,
know,
yeah.
N
To
be
edge
cases,
you
know,
how
do
you
deal
with
performance
issues
out
here?
How
do
you
deal
with
complex
data
structures
showing
up
in
your
labels?
How
do
you
deal
with
all
these
other
things?
And
I
think
that's
something
that's
these
are
great
questions
and
I
don't
think
that
they
should
be
dismissed,
but
it's
also
not
something
that
it
needs
to
be
resolved
at
the
semantic
input
level
at
the
api.
That's
that's.
Why
there's
a
separation
there!
That's!
N
Why
there's
that
there's
layers
that
can
actually
deal
with
these
sort
of
complexity
as
you
move
down
the
processing
chain
of
these
pipelines,
and
I
think,
if
that's
a
really
good
point
to
make-
and
I
think
that
the
thing
that
gets
lost
a
lot
in
this
discussion
is,
you
know
you
can
only
have
strings
here.
So
therefore
they
have
to
be
different
types,
and
it's
like
well
from
a
user's
perspective.
You
have
a
set
of
keys
and
you
have
a
set
of
values
right.
They
don't
you
know.
N
Even
in
some
languages
they
don't
have
types,
there's
no
such
thing
as
a
type
right,
so
well,
or
a
dynamic
type
at
least
and-
and
the
idea
is,
is
that
they
just
want
a
way
to
pass
keys
and
values.
They
don't
really
want
to
be
confused
by
in
this
situation,
I
pass
keys
and
values,
but
I
call
it
labels
in
this
situation.
I
pass
keys
and
values
are
called
attributes,
and
this
one
I
call
it
tags.
I
think
that's
a
really
important
thing.
A
lot
of
the
time.
N
I
know
that
most
people,
I've
talked
to
that
start,
using
the
go
implementation
or
that's
it's
one
of
their
first
questions
is:
why
is
there
different
things
or
attributes
and
labels?
And
I
think
that
it's
something
we'd
be
remiss
to
not
address
at
this
point
in
time
with
some
sort
of
clean
eyes.
I
think
is
really
critical
here.
E
By
the
way
borgin
had
to
leave,
but
he
left
a
comment,
basically
he's
afraid
about
the
that
objects,
overhead
in
languages
in
which
objects
need
a
new
location.
All
the
time.
N
Yeah
this
is
again,
I
think
this
is
comes
back
to
the
performance
issue,
like
the
the
conversation
always
gets
mudded
into
this
performance
issue.
I
think
that
there
are
ways
that
we
can
solve
the
performance
issue,
but
if
we
lose
sight
of
the
user-based
issue,
which
is,
I
think,
under-represented
in
a
lot
of
these
discussions,
where
we're
going
to
be
fielding
a
lot
of
questions
that
are
not
as
easy
to
answer.
G
Yeah,
I
agree
with
tyler,
I
think
in
donna
we're
facing
similar
issues
where,
instead
of
having
a
generic
like
key
value
pair,
where
value
is
an
object,
we
decided
to
go
with
like
a
template
approach,
so
we
have
generic
functions
that
could
take
a
structure
where
it
has
no
heap
allocation,
though
there
are
the
things
that
I
think
we
as
the
maintainer
of
each
language
isdk
should
address,
but
from
the
user
experience
I
think
it's
super
confusing.
To
have
things
like
you
can
add
a
tag.
G
You
can
add
a
property,
you
can
add
attributes,
you
can
add
something
like
key
value
pair.
It's
a
hard
sell.
Whenever
you
explain
like
I,
I
imagine
this
telemetry
is
going
to
be
used
by
every
single
developer
on
this
planet,
and
most
of
them
would
be
junior
developers
and
they
will
have
a
hard
time
understanding.
What's
the
difference
and
it
seems
like
creating
a
job
security
for
us.
G
Yeah
and-
and
one
particular
thing
I
learned
in
microsoft-
is
because
people
they
won't
have
strict,
like
like
separation
between
those
terms
and
eventually
we
have
the
young
generation
of
developers
realize
this
thing
is
so
complicated.
Let's
invent
it
another
thing,
so
they
start
add
xyz
and
try
to
uniform,
like
all
the
existing
stuff,
and
it
will
fail
and
later
people
add
another
term.
So
we
end
up
with
like
20
different
terms
and
technically
it's
just
key
value
pair
and
the
figure
like
when
I
started
with
node.js.
G
It's
so
like
it's
so
straightforward,
like
coming
from
the
nether
world,
I
have
like
all
the
all
all
the
concepts-
and
you
know
gs
is
just
keep
up
here,
put
whatever
you
want
and
still
it's
very
successful
language.
So
I
I
I
think
it's
only
like
the
people
who
invented
those
system,
they
have
a
strong
affinity
of
having
those
distinguishing
like,
but
from
the
user
perspective
they
want
something
similar.
P
So
I
just
want
to
call
out,
in
addition
to
that,
I
think
this
area
of
the
spec
and
api
is
most
likely
to
hit
end
user
applications
so
like
from
like
a
span
perspective,
if
that's
a
little
bit
gross,
I
think
that
doesn't
hit
quite
the
number
of
people
that
the
metrics
api
will.
So,
if
that
lends
any
weight
to
this
discussion,
I
think
this
is.
This
is
the
place
where
you
want
your
terminology,
nice
and
clear
and
easy
to
use
when
it
hits
metrics.
L
Well,
it
sounds
like
the
only
objection
here
is
coming
from
bogdan,
who
is
is
absent
right
now,
so
I'm
not
sure
carlos.
What
do
you
think
the
right
way
to
move
forward
here.
E
I
think
we
could
probably
leave
a
comment
on
the
issue
and
outlining
that
the
advantages
are
are
important
enough
and
yeah.
We
should
try
to
go
with
this
and
see
what
book
then
says
but
yeah,
okay,
so.
G
Yeah
right
for
one
question
already
in
agreement
that
we
want
to
solve
this
issue
before
ga,
because
this
seems
to
be
our
last
chance.
Otherwise,
we'll
have
to
wait
for
a
couple
years,
probably
like
for
version
two
yeah
so
number
one
thing
I
I
would
vote.
We
treat
this
as
a
serious
problem
because,
like
all
the
users
would
be
affected
and-
and
we
decided.
E
A
M
A
Yeah
I
mean
I,
I
think
we
just
want
to
rationalize
between
the
three
of
them.
I
could
see
us,
you
know,
still
cutting
a
tracing
rc
like
the
first,
the
first
pass
of
tracing
rc.
That
doesn't
include
this
and
we
have
a
follow-up
that
does,
I
think,
that's
okay,.
M
I
have
a
question
on
this,
sir:
I'm
thinking
of
the
the
world
of
protocol
buffers
where
there's
a
compatibility
guarantee
that's
on
the
wire
level
and
then
it's
okay
to
change
field
names
like
it's.
Just
it's
not
a
meaningful
protocol
change.
Do
we
have
that
type
of
guarantee
here?
In
other
words,
if
we
change
attributes
to
label
it
it's,
it
is
a
breaking
change,
but
it
is
a
trivial
change
and
I'm
curious
what
people
think
about
that
distinction.
N
A
N
A
A
M
Yeah
some
people
had
proposed
change.
Replacing
label
with
attribute
is
that
metrics
is
less
mature
than
trace,
and
so
that
way
we're
not
disturbing
traits
right
before
ga.
I
have
sort
of
proposed
that
label
is
a
better
name
and-
and
I
I
wonder
if
we
could
resolve
this-
I
don't
know
if
a
vote
is
appropriate,
but
there's
two
there's
several
factors:
there's
one
about
the
disruption
budget
and
there's
one
about
the
long-term
user
benefit
and
there's
one
about.
I
don't
know,
I
don't
know,
there's
probably
more
than
that.
E
Well,
first
of
all,
I
guess
that
we
can
mark
that
related
issues
as
p1
and
required
for
ga,
so
we
are
forced
to
think
our
options
and
decisions,
and
somebody
needs
to
read
a
summary
of
what
we
discuss
and
you
know
trade-offs.
There.
N
So
carlos
just
just
heads
up
like
I
I
I
didn't
that
wasn't
me
talking
that
was
josh,
essentially
josh.
All
that
stuff
came
from
josh's
comment
like
I
think
this
has
already
been
pretty
summarized
in
his
comment,
so
I
think
it's
the
opposite
side
of
you
know
what
what
are
the
the
other
sides
of
why
we
wouldn't
want
to
do
this
or
or
other
proposals
outside
of
the
attribute.
Sorry,
I
didn't
need
to
catch
up.
I
just
wanted
to
make
that
clear.
E
M
M
The
way
I
like
to
approach
this
type
of
issue
with
metrics
is
like
propose
everyone
think
on
this
for
a
week
and
come
back
with
like
ready
to
make
a
hard
decision,
but
I
don't
think
this
should
be
a
tc
decision.
That
should
be
a
larger
group
here
and
there
are
many
factors
so
so
maybe
we
should
and-
and
I
think
I
noticed
nobody's
defending
the
word
attribute
like
there-
should
be
somebody
defending
the
word-
I
should
do
if
it's
just
like
our
schedules
are
too
complicated.
G
G
Basically,
you
have
the
the
like
the
the
class
attribute
and
and
fields,
and
it
is
already
a
hard
to
explain
thing
for
a
lot
of
like
new
developers
to
donate
and
adding
like
the
overloaded
term.
Call
that
attribute
is
it's
too
confusing,
so
the
architects
from
dotnet
have
decided
they're
going
to
call
it
everything
tags,
I'm
leaving
the
middle.
So
I
think
calling
that
text
seems
to
find
a
reasonable
balance
between
open,
telemetry
and
non-net,
and
I'm
not
going
to
argue
and
try
to
convert
that
into
attributes.
N
So
riley
and
ken,
could
you
possibly
add
that
to
this
ticket?
I
think
that
might.
N
Just
to
get
a
summary
carlos
can
we
get
somebody
assigned
to
this
ticket
to
make
sure
that
this
is
addressed
before
ga.
E
Yeah,
I
guess
that
I
don't
know
gmark
did
you
have
time?
If
not,
I
can
help.
I
can
help
always,
but
if
somebody
with
more
background
metrics
could
have
could
happen,
they
would
be
happier
because
I'm
not
that
up
to
date
on
the
metrics
I
mean
I
can
be.
M
Assigned
this-
and
I
will
you
know
where
my
pc
has
on
this-
I've
already
stated
my
opinion,
but
I
don't
think
it's
necessarily
the
right
thing
to
do
so.
Yeah.
E
C
I'd
like
to
piggyback
on
this,
I
didn't
write
this
line
down,
but
what
this
stems
from
is
the
conversation
that
we
had
at
the
maintainers
meeting
yesterday
relating
to
the
upcoming
blog
post,
that
morgan
will
be
putting
out
next
week.
We
have
a
desired
date,
for
I
think
it
was
the
tuesday
nine
a.m
where.
H
Oh,
is
it
wednesday
morgan
because.
A
Yesterday,
okay,
we
we
said
wednesday
the
end
of
the
meeting
right
before
I
hopped
off
last
time,
so
that
we
have
time.
C
All
right
so
wednesday
at
9
00
a.m
is
the
desire
time
for
the
blog
post,
we're
talking
about
the
upcoming
status
on
open
telemetry,
with
the
trace,
spec
freeze
and
also
the
following
road
map
afterwards
of
the
languages
implementing
the
trace,
spec
and
metrics
api
being
frozen.
C
So
those
timelines
in
relation
to
that
there's
discussion
of
well
how
much
time
is
required
for
each
one
of
the
languages
in
order
to
implement
the
trace
spec
the
trace
spec
api,
so
that
follows
discussion
of
the
compliance
matrix,
whether
that
should
be
split
between
api
and
sdk
in
order
to
clearly
separate
out
what
work
needs
to
be
done.
So
that's
how
this
item
came
about.
H
Everyone,
I
have
a
question
carlos
sorry.
I
just
had
a
question
that
would
the
maintainers
be
able
to
provide
input
for
completion
on
their
languages
by
next
week,
or
is
it
just
bogdan's
matrix
for
the
compliance
matrix
andrew.
C
C
H
Mean
that
was
why
we
wanted
to
kind
of
bring
it
up
in
this
meeting,
also
right,
so
that
there
is
a
wider
understanding
across
this.
C
E
E
Okay,
in
that
case,
let
me
go
to
the
next
item,
so
the
next
item
is
renaming
spam
context
to
spam
reference.
This
was
not
to
alleviate
some.
I
don't
know
how
to
call
it
confusion
or
you
know
excessive
use
of
the
word
context.
Nobody
has
posed
strongly
against
that,
but
please
review
that.
Will
you
distribute
reviews
pr
and
just
either
approve
it
or
leave
your
your
feedback
there?
I
think
in
general,
it's
it's
a
good
change,
but
yeah.
I
would
like
to
hear
any
opinion.
S
Yeah,
so
I
put
this
put
this
issue
in
last
week:
it's
been
assigned,
but
there's
been
exactly
zero
discussion
on
it.
S
S
E
E
Otherwise,
you
cannot
provide
out
of
the
box
propagation
for
this
in
the
absence
of
sdk.
If
you
want
to
do
that.
K
My
two
cents
is
that
baggage
and
w3c
trace
contacts
should
be
implemented
in
the
api.
I
think
the
more
controversial
thing
is
whether
they're
operational
by
default,
but
I
think
it's
uncontroversial
that
they
should
be
part
of
the
api
package.
If
that
helps.
K
I
think
whether
or
not
the
api
is
configured
to
use
them
out
of
the
box
or
whether
this
is
one
additional
step
for
the
user
is.
S
S
K
Yeah,
I
think
what
you
just
said.
I
totally
agree
with
so
kind
of
the
same
thing
that
we
do
for
trace.
Contacts
would
be
what
I
think
we
should
do
for
baggage,
but
we
should
actually
write
this
down
somewhere.
E
E
Okay,
next
item
is
well
andrew.
I
don't
know
if
you
already
covered
these
yeah.
C
I
already
covered
this
yeah
if
I'll
be
putting
more
status
updates
in
the
guitar
channel,
but
we
can
get
the
next
item
yeah.
The
next
one
is
yours
as
well.
Metrics
api,
all
right,
fyi
this
coming
friday,
we're
going
to
be
scrubbing
through
the
metrics
issues,
so
metrics
folks
would
be
desirable
to
attend.
E
Make
sense
tristan
said
attributes
in
on
nth.
O
Q
Yeah,
actually,
I'm
just
discussing
that
with
someone
now
who's
trying
to
mimic
a
functionality
of
the
honeycomb
b
line,
where
you
can
add
trace
fields.
B
Same
issue,
I
think
this
was
already
discussed
some
time
ago
and
we
were
not
sure
because
of
the
order
of
spam
processors
being
called
so
that
that
it
might
be
non-deterministic
if
one
or
the
other
spam
processor
sees
it
already
at
the
time
it.
It
gets
it
when
it's
added
by
another.
B
Like
I'm,
I'm
not
sure
if
we
define
the
in
the
spec
that
it
must
be,
the
other
must
be
preserved
or
or
even
reversed
and
preserved.
Not
sure
here.
O
O
E
Yeah,
please,
because
I'm
trying
to
look
for
army's
issue.
I
remember
that
one,
but
I
cannot
find
it,
but
having
an
issue
will
help
us
not
forget
and
try
to
yeah
do
something
sounds
good
perfect
and
then
we
have
one
minute
left,
but
we
don't
have
time
just
and
just
for
your
information
there,
there's
there's
also
the
possibility
about
renaming
status,
canonical
code
to
the
status
code
or
something
shorter.
Just
take
a
look,
I
think
it's,
it
seems
trivial.