►
From YouTube: 2020-09-29 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
C
D
B
C
C
C
Okay,
shall
we
wait
one
more
minute
or
are
we
ready
to
start.
F
G
Oh,
I
will
share
and
I've
got
a
few
items
I'm
going
to
try
to
move
quick.
So
that
way
we
have
time
to
be
able
to
discuss
some
important
issues.
I'll
start
with
the
triage
of
newly
opened
issues.
G
C
B
Before,
if
we
have
time
to
do
one
or
two
one
or
two
prototypes-
and
we
see
that
there
is
no
problem-
I'm
happy
to
accept
this.
B
G
I
should
probably
point
out:
there's
a
new
label
that
was
added
on
friday
called
allowed
for
ga,
which,
instead
of
strictly
after
ga,
where
we're
not
going
to
look
at
how
this
effects
or
actually
it's
undesirable,
because
it
may
make
some
changes.
That
would
break
the
api
and
instead
of
required
for
ga,
where
we've
really
got
to
get
this
in,
for
the
freeze
allowed
for
ga
means
it
can
come,
it
usually
editorial
change,
but
it
does
not
affect
the
api.
So.
H
Yeah,
so
the
changes
added
to
the
changes
made
to
make
the
trace
the
sampling
result
from
the
sampler
include
the
trace
state
as
a
field
which,
if
that
is
a
basically,
if
that's
a
mandatory
requirement
on
the
sampling
result.
It
means
that,
rather
than
being
able
to
return
constant
values
for
sampling
results
like
yes,
no
or
yes,
with
a
with
a
probability,
know
the
probability.
H
We
actually
now
have
to
construct
a
new
object
for
every
single
one.
Wrapping
the
wrapping,
the
tray
state
that
is
required
to
be
passed
in,
which
is
fine
for
samplers,
which
need
to
actually
modify
the
tray
state.
All
of
the
built-in
samplers
don't
modify
the
trace
date.
How
we've
made
their
job
more
difficult,
made
it
harder
for
people
to
implement
simple
samplers,
because
now
they
have
to
figure
out
what
they're
supposed
to
do
around
trace
date.
H
H
B
You
try
to
come
up
with
cop
one
or
two
possibilities
that
you
believe
are
nice
or
are
desirable
and
and
we
can
kind
of
decide
which
one
looks
better.
H
Yeah
and
I
think
also
christian,
his
comment
was:
maybe
we
shouldn't
be
so
prescriptive
in
the
spec,
and
maybe
we
should
just
use
the
make
the
language
a
little
bit
more
open
to
pro
to
provide
the
facility
for
modifying
the
trade
state
rather
than
being
very
prescriptive
on
the
structure
of
the
sampling
result.
Yeah.
A
John
I'll
ping
them,
but
if
you
wouldn't
mind
roping
in
ludamilla
from
azure
and
oh
I
forget
his
name.
One
of
the
engineers
from
honeycomb
is
also
working
on
sampling
and
they
were
interested
in
this
trace
state
business.
I
don't
know
if
you've
talked
to
them
at
all,
or
anyone
from
those
two
places
are
on
the
call
or
anyone
else,
who's
been
using
the
sampling
plan,
but
I
know
they're
trying
to
use
it
so
trying
to
rope
them
into
this
thread.
To
make
sure
you
know
the
result.
H
Works
for
them,
but
if
I
get
my
your
request
straight,
it
was
lamilla
and
somebody
you
don't
remember
it's
hard
for
me
to
add.
A
And
honeycomb
so
I'll
ping
them
I'll
get
back
to
you,
but
just
don't
you
tag
them
on
the
issue.
Let's
see
them
on
the
issue.
They
should
follow
this.
I
just
want
to
flag
that,
let's
make
sure
someone
who's
building
one
of
these
samplers
chimes
in
before
we
yep.
D
Think
sorry,
ludmilla
is
not
at
microsoft
anymore,
but
ping
conwell,
deep
or
riley
riley's
on
the
call
here
it
would
be
conwell
deep
right,
yep.
C
Okay,
allow
for
j,
I
would
say,
allow
for
j.
C
C
G
Okay,
so
that
that
clears
it.
The
next
topic
I
believe
I
covered
just
an
fyi
of
allowed
for
ga
label.
G
G
massive
number
was
taken
off
because
we
scrubbed
through
with
the
p2
p3
issues,
we
started
the
triage
at
the
beginning
of
friday,
there
were
zero
p1
issues,
which
was
fantastic.
That
was
like
a
milestone,
so
we
went
through
the
p2
issues
and
moved
what
was
what
seemed
reasonable
over
to
allowed
for
ga
and
moved
whatever
else
over
to
after
ga
or
closed
them,
and
also
the
p3
issues
were
just
moved
to
after
ga.
So
that
is
how
this
number
was
able
to
come
down
so
quickly.
G
Ga
progress,
seven
went
down
sorry,
the
g
in
progress.
Let
me
see
we
have
this.
This
one,
I
believe,
covers
more
than
just
the
trace,
so
we
have
a
lot
of
issues
on.
G
16
of
them
were
added
to
the
done
column
of
the
ones
that
we're
trying
to
concentrate
on
for
the
p1
for
the
freeze
for
the
trace
spec,
we
have
two
and
to
do
and.
G
This
is,
I
believe,
what
the
main
concentration
should
be
in
order
to
be
able
to
freeze
the
trace
spec,
so
I've
added
that
to
the
agenda
in
order
to
talk
more
about
it
in
depth.
I
have
these
other
ones,
which
I
don't
know
where
there
are
as
necessary
in
order
to
in
order
to
be
able
to
achieve
freeze
for
the
trace
spec,
but
there
is
one
logistic
one
that
I'm
not
sure
whether
it
will
help
if
it
carries
on
for
the
next
week,
possibly
of
swapping
the
times
of
the
maintainers
meeting.
G
The
spec
sig
meeting
with
maintainers
mean
just
that
we
could
front
load
and
discuss
back
issues
at
the
beginning
of
the
week.
I
don't
know
if
that
will
be
helpful
or
a
possibility.
G
Any
case,
that's
all
I
have
on
the
status,
so
you
can
talk
about
the
next
issues.
If
you
like.
C
Perfect,
thank
you.
Yes,
we
will
need
a
time.
Okay,
sorry,
I
see
one
more
item
or
did
you
cover
it?
Compliance
matrix.
G
G
Yeah,
we
need
to
fill
out
the
some
of
the
tables,
but
the
second
point
that
you
brought
up
is,
I
think,
was
the
question
that
was
remaining
from
last
week's
meeting.
It's
like
which
of
the
tables
need
to
be
implemented.
So
that
way,
a
language
that
can
say
hey.
B
I'm
joking
we
need
to.
We
need
to
look
at
it.
B
I
will
let's:
when
do
we
need
this.
G
C
C
Okay!
Okay!
Thank
you.
The
next
item
is
still
yours,
andrew.
It's
about
swapping
times
with
maintainers.
G
Meeting
right-
and
this
was
just
an
idea
that
was
brought
up-
I
don't
know
if
this
is
helpful-
I-
whether
swapping
this
time
with
the
maintainer
screening,
would
help
with
discussion
at
the
beginning
of
the
week.
So
that
way
we
have
an
extra
day,
I'm
just
looking
at
ways
to
optimize
the
time
for
what
we
work
on
in
the
week.
I
B
A
I
Yeah
all
right
I'll
do
this
one.
H
C
G
C
You
can
help
me,
try
that
or
you
can
try
that
yourself,
but
yeah.
Okay.
Actually,
I
see
only
one
more
item,
although
I
know
that
we
have
two
more
but
okay.
Yes,
so
we
want
to
save
some
time
for
this
at
the.
G
C
C
Okay,
that's.
G
Okay,
we
can
go
to
these
p1
issues.
First,.
I
So
it
sounds
like
from
yesterday's
discussion.
This
is
fairly
popular.
I
guess
my
question
is
just
the
interesting
timing.
Like
is
someone
isn't
bogged
in
this?
Is
someone
working
on
actually
writing
a
spec
for
this,
so
we
can
review
it
and
get
it
merged
quickly.
C
Well,
since,
since
it's
about
mostly
removing
something
it,
I
think
it's
relatively
simple,
but
we
will
still
need
this
week
to
prototype
something:
okay,
okay,.
A
Yeah,
I
think,
there's
a
decision
about
how
to
centralize
it.
Do
we
want
to
have
basically
comes
down
to
the
active
span.
Nonsense
is
essentially
a
global,
and
do
we
want
to
have
something
like
a
global
tracer
that
people
can
grab
and
get
all
of
this
facing
stuff,
or
do
we
want
to
have
utility
methods
that
other
things
rely
upon
rather
than
having
just
tracer
instances
that
people
have
to
make
is
the
only
way
to
to
get
at
this
information?
H
I
just
wanted
to.
I
didn't
get
a
chance
to
get
a
my
comment
in
yesterday.
I
didn't
mention
this
in
the
in
the
thread
on
the
issue,
but
if
we
do
remove
the
methods
from
the
tracer,
then
the
tracer
will
have
one
method
left
on
it,
which
is
basically
just
to
create
a
new
span,
and
then
it's
like.
Is
it
a
tracer?
It's
just
a
span
factory
at
that
point
and
it
I
don't.
It
would
feel
very
strange.
H
H
H
B
Point,
I
I
think,
that's
so
I
think
I
think,
based
on
the
comments
here,
I
like
that
this
separation,
that
there
are
some
functionality
there
that
are
stateless
or
don't
require
any
state
and
yeah
in
java.
If,
if
that's
a
weird
thing,
we
can
put
them
on
the
tracer
as
static
methods
on
the
tracer
just
to
to
not
have
yet
another
class
which
which
I
like
the
that
option.
B
So
I
I
would
not
worry
that
much
if
the
tracer
does
not
have
too
many
methods
as
long
as
we
can
rename
it.
If
that's,
if
that's
the
problem,
if
the
problem
is
the
name
that
it
does
not
do
too
much
besides
a
factory,
we
can
just
name
it
trace.
A
K
Was
proposing
some
static
methods
yesterday
in
a
comment,
and
I
think
that's
definitely
an
approach,
but
I
think
for
the
most
part,
instrumentation
authors
are
already
gonna,
have
a
handle
on
a
tracer
to
sort
of
have
them,
as
instance,
methods
on
a
tracer
makes
sense
there.
It's
kind
of
the
the
situations
where
you
don't
where
you
don't
readily
have
a
handle
on
a
tracer,
but
if,
if
it's
easy
enough
to
get
a
handle
on
a
default
tracer
just
to
operate
on
these
things,
I
think
that's
as
good.
A
B
H
Yeah,
that's
fair!
So
just
as
a
data
point
again,
I'm
not
trying
to
argue
one
way
or
another
here,
but
we
did
just
get
a
question
in
the
open,
telemetry
java
instrumentation
getter
channel
about.
I
want
to
get
access
to
the
tracer
that
is
being
used
by
the
by
the
agent,
and
I
have
to
explain.
Well,
you
don't
need
to
because
it
doesn't
really
have
anything
except
a
name
on
it.
It's
not
really
anything
at
all.
H
So
I
think
there
definitely
is
some
user
confusion
about
what
it
means
to
have
access
to
a
tracer
in
general,
because
it
has
no
state
now
it
just
has
basically
just
as
a
handle
for
the
name
version
yeah.
So
anyway,
there
is
user
confusion
ongoing
that
we
should
think
about
how
to
mitigate
yeah.
A
I
I
know
it's
very
late
in
the
game,
but
this
is.
I
know
that
the
the
name
spacing
that
the
name
tracers
provides
is
potentially
useful.
We
haven't
made
use
of
it
yet,
and
it
really
does
seem
like
it.
It
adds
a
lot
of
complexity
into
this
particular
area.
If
you
didn't
have
to
name
those
tracers,
it
really
does
seem
like.
We
could
really
simplify
this
core
bit
of
functionality
right,
because
that's
the
only
reason
why
we
don't
have
a
effectively
global
tracer
is
to
deal
with
this
name
spacing
stuff.
A
I
don't
know
if
there's
a
different
way
to
do
that
name
spacing
stuff
that
could
get
us
out
of
having
to
make
these
tracer
handles
because
it
does
seem
like
they're
genuinely
confusing
to
people.
A
K
I
feel
like
that
could
be
pulled
off
using
kind
of
I
don't
know
some
sort
of
scope
with
your
with
context
and
you
could
wrap
that
up
into
kind
of
like
a
a
helper
of
sorts,
but
it
might
be
late
in
the
game.
B
But
that
that's
not
going
to
help,
because
then
you
have
to
wrap
the
scope,
the
context
you
do
an
extra
wrapping
every
time
when
you
enter
a
code
right
now,
this
this
scope
is
static,
so
that
that
would
be
a
runtime
scope
versus
a
static
scope.
We,
the
tracer
name,
is
more
like
a
static
scope,
because
it
it
wraps
at
compile
time
something
not
at
run
time.
A
I
don't
mean
to
imply
that
the
problem
is
trying
to
solve,
isn't
real,
but
but
that
this
does
seem
like
one
of
those
squiggles
where
it's
just
like.
Like
a
pinch
in
your
shoe,
you
know
it
just
doesn't
get
better.
As
time
goes
on.
We
keep
circling
back
to
this
particular
region
where
it
seems
overly
complicated.
B
A
It
just
seems
like
that.
That's
a
lot
simpler
right.
We
wouldn't
be
having
any
of
these
discussions
right
now,
because
you
would
have
a
global
tracer
that
you
just
grab,
but
we
have
a
global
trace
provider
global
trace
provider.
But
if
the
tracer
thing
all
it
does,
is
you
know,
make
spans
and
give
you
access
to
spans?
That's,
basically,
all
that
tracer
provider
does
right.
A
Which
seems
like
useful
information,
I'm
just
pointing
out,
we
don't
use
it
anywhere,
it
doesn't
show
up
in
otlp,
we
haven't
implemented
any
functionality
as
far
as
I'm
going
to
it.
A
F
F
If
you
look
at
the
traces,
you
will
see,
that's
something
that's
coming
from
the
auto
instrumentation
agent,
and
that
thing
looks
odd.
That's
something
I
messed
up
myself
with
my
instrumentation.
F
I
remember
that
we
we
discussed
disabling
malfunctioning
instrumentations
on
this
way,
so
that
they
would
only
get
like
north
spans
and
so
on,
but
this
was
something
that
we
said
we
can
also
implement
after
ga,
just
as
well
yeah.
A
A
Yeah,
but
if
it
does
end
up
only
having
the
ability
to
create
spans,
then
maybe
it's
just
renaming
it
something
instead
of
tracer,
it's
like
namespace.
Some
kind
of
I
think
one
thing
that
does
make
it
confusing
to
people
is
the
interface
is
get
tracer
and
you
give
it
a
key.
That's
not
what
we
mean.
We
say
like
create
a
namespace
with
this
name
and
version,
but
the
interface
looks
like
get
this
value
with
this
key
and
that
confuses
users,
because
they
never
set
a
tracer
with
that
value,
and
so
they
go.
Oh,
what?
A
B
B
A
Yeah,
if
all
these
methods
move
to
tracer
provider-
and
you
create
your
global
register,
your
global
tracer
provider
and
then
that's
the
only
thing
you
ever
used,
except
you
can
make
name
space
versions
of
it.
That
would
be
one
less
object.
We
call
that
the
tracer
and
name
spacing
the
tracer
might
make
more
sense.
I
don't
know
that
seems
like
that
would
solve
all
these
problems
and
we'd
end
up
with.
I
don't
think.
A
B
A
B
So
half
of
this
issue
is
how
do
you
interact
with
the
context
instance
and
importantly
here
there
was
a
discussion
about
propagators.
How
do
they
extract?
Because
the
propagator
interface
right
now
gets
a
context
and
returns
a
context,
but
needs
to
manipulate
this
context?
Somehow
and
right
now,
we
did
not
require
to
pass
a
tracer
to
these
propagators
or
anything.
B
B
L
L
B
So
I
think
I
think
ted
it's
another
problem
is
is
this?
Is
this
an
implementation
thing
like
the
who
who
owns
the
active
functionality,
the
an
active
context,
because
we
right
now
right
now?
Personally,
I
think
I
think
it's
a
problem
to
have,
for
example,
the
proposal
that
I
saw
if
you
scroll
up
here,
whoever
is
presenting
there
is
a
proposal
to
have
a
with.
I
think
math
proposed
that.
K
Called
tracer.currentspan
yeah.
B
So,
for
example,
tracer.com,
if
that's,
is
that
an
interface?
If
that's,
it
is
an
interface
okay,
I
think
our
api
is
wrong
for
two
reasons:
if
that's
an
interface-
and
there
is
another
interface
called
called
current
context,
I
think
now
we
have
a
problem.
B
B
Do
do
you
agree
that
car
get
spam
from
current
context,
so
there
is
a
current
context:
functionality
in
the
context,
okay,
and
if
I,
if
I
do
tracer.currentspan
from
currentcontext,
got
from
from
there
yeah,
it
may
return
a
different
object
than
tracer
that
current
context
without
passing
a
context
in
this
api.
A
B
K
B
K
Yeah
so,
like,
I
think,
a
lot
of
these
things
boil
down
to
otep
issue
68.
I
think
tristan
is
mentioning
this
in
in
the
chat,
and
that
is
a
proposal
to
remove
span,
I
think,
and
that
would
leave
tracer.
It
would
make
tracer
a
little
bit
more
defined
and
probably
smooth
over
a
lot
of
these
issues,
but
it's
probably
very
late
in
the
game
to
be
entertaining
this
but
yeah
like.
I
definitely
think
there
are
some
api
issues
that
need
to
be
solved.
C
Yeah,
there's
the
other
one,
the
one
about
moving
spam
context
into
spam.
It's
not
related
to
this,
but
we
still
needed
the
time
it
does
what
you
meant
yeah.
So
for
the
previous
one.
I
do
feel
that
we
need
people
to
actually
make
proposals
like
bogdan
made
one.
Maybe
we
can
mata
and
me
we
can
work
in
another
one
and
because
you
know
we
need
to
actually
test
out
with
codes.
A
C
A
bit
better
okay,
so
I
will
work
with
math
and
depending
on
his
time,
or
I
will
do
that
myself
inspired
by
what
he
proposed.
So
I
will
work
on
that
proposal
just
to
have
one
option,
so
we
can
probably
contrast
that
with
what
with
what
boxton
wants
and
we
can
decide,
but
I
guess
that
the
question
is
that
well,
there
are
two
questions.
First,
one
is
that
we
would
re.
We
would
need
at
least
this
week.
C
K
K
C
Accurate
that
sounds
good
to
me,
but
is
it
okay
for
the
rest
of
the
of
the
crew
here?
Does
that
sound
about.
I
C
A
It's
annoying,
but
I
think
this
one's
really
important.
I
think
if
we
end
up
with
something
clean
here,
this
is
so
central
to
being
a
bunch
of
very
repetitive
actions
that
we
have
to
explain
to
almost
every
user
and
almost
every
user
has
to
interact
with
so
any
amount
of
simplicity
that
we
can
and
clarity.
We
can
inject
into
this
part
of
the
api,
I
think,
would
would
be
very
beneficial.
G
C
This
is
the
one
that
tigran
will
be
driving
between
just
well
today,
but
figure
out.
Do
you
think
this
is
it's
important
to
talk
about
this
now?
He
he
is
not
in
this
meeting.
He
couldn't
make
it
okay
so,
but
I
think
I
got
impression
based
on
what
he
said
yesterday,
that
this
is
straightforward,
and
I
agree
with
that.
Yes,
I.
B
C
Let
me
find
it
seconds.
I.
D
So
we
brought
we
discussed
this
yesterday
in
the
maintainers
meeting
and
it
seemed
like
the
direction.
Instead
of
making
it
optional
was
either.
We
should
remove
it
for
everybody
or
not,
remove
it
at
all,
so
honorag
put
in
a
pr
basically
to
show
what
it
would
look
like.
Try
to
drive
the
discussion
on
what
it
would
look
like
to
remove
it
completely,
and
I
would
just
in
kind
of
in
quick
summary
the
it
seemed
to
me,
like
the
main
con
of
doing
that
was
sort
of
this
concept
of
span.
D
Identifiers
weren't,
quite
as
clear
like
there
was
sort
of
this
concept
of
span
context
as
this
grouping
of
attributes
that
are
critical.
A
B
A
B
Think
that
was
one
of
the
usually
the
other
use
case
was
what
I'm
trying
to
say
is,
for
example,
if
you
want
to
put
it
in
the
logs,
you
better
put
the
entire
span
context
in
every
log.
If
you
can,
then
than
putting
every
individual
field
or
or
anywhere
like
when
you
need
to
save
some
reference
to
a
specific
span,
you
save
the
span
context
and
that's
the
reference
to
that
specific
span,
which
is
everything
that
you
need
to
know
to
to
identify.
D
That
anurag
had
a
comment
about
that
sort
of
that.
The
cross-cutting
concerns
he
said
was
mentioning
are
defined
on
the
the
context
already
so
sort
of
you
know,
passing
things
around
to
say,
logging
and
I
think
you
brought
up
the
the
metrics.
The
exemplars
and
context
already
is
defined
by
spans.
D
So
it
feels
like
potentially
span
is
a
good
interface
for
for
exposing
that
data.
A
Yeah
bogdan's
last
use
case
around
logging
almost
seems
like
correctly
defining
what
the
tostring
method
on
a
span
should
return
or
something
along
those
lines.
Actually,
you
don't
necessarily
need
to
spam
context
anymore,
but
part
of
the
reason
I
think
we
can
get
away
with
it
now
is.
We
now
have
a
full
on
context,
which
is
a
thing
that
was
not
present
in
either
of
these
systems
before,
and
so
it's
really
less
important
as
a
as
a
concept
that
end
users
need
to
know
about
the.
B
Other
argument,
by
the
way
now
I
know
that
I
should
myself
in
the
food,
but
the
other
argument
against
my
my
theory
of
maintaining
of
keeping
it
is.
You
know
we
can
always
add
it
later.
If
we
really
find
out
that
we
need
it,
it's
much
easier
to
to
remove
now
and
add
later
then
remove
later.
C
B
No,
the
fields
the
fields
will
be
in
the
span
and
you
can
have
always
them
in
the
span
in
also
in
the
span
context,
because
the
span
has
always
a
span
context
right
now.
Correct,
like
getting
the
trace
id
right
now
is
span
that
get
context
that
get
trace
id
and
it
will
become
just
spam
that
get
recited.
It's.
A
B
Yeah,
the
only
concern
that
I
had
in
the
past
in
a
gc
language
and
that's
probably
my
main
concern
in
a
gc
language,
for
example.
If
I
have
to
store
these
ids
for
later,
let's
assume
I
have
some
async
framework
or
whatever
or
store
these
spam
contacts
for
every
every
log
record,
okay
and
people.
If
people
will
store
the
span
reference,
they
need
to
be
aware
that
they
will
hold
a
lot
more
memory
and
they
will
keep
a
lot
more
memory
around,
because
the
span
may
keep
memory
around
compared
with
with
spam.
E
E
Yeah,
we
would
have
to
keep
some
sort
of
expand
context
it
wouldn't.
We
could
obviously
make
it
a
different
name
and
opaque
and
everything,
but
we
would,
in
early
elixir,
still
be
using
some
sort
of
entity
that
it's
just
ban
id
and
trade
and
trace
id
because
we
have
to.
But
you
you
you
can
avoid
exposing
publicly
correct
right
yeah.
E
We
could
probably
well
I
mean
yeah
yeah,
I
mean,
but
we'd
still
probably
use
it
for
functions
that
are
like
get
the
trace
id
on
whatever
it's
returned
by
starting
a
trade
starting
a
span,
and
that
would
take
a
span
context,
but
it
I
mean
yeah.
I
don't
think
the
user
would
have
to
know
much
about
it.
D
And
but
then
the
honorable
did
address
the
specific
logging
mdc
issue
here
in
the
pr.
B
D
Okay
yeah,
so
all
the
md,
all
the
at
least
all
the
java
mdc
frameworks
only
take
strings,
so
you
have
to
store
strings
anyway.
So
that's
not
a.
F
C
C
Okay,
so
let's,
let's
make
it
since
nobody's,
raising
their
voice,
make
it
required
for
ga
and
we
decide
next
monday.
G
C
E
C
D
Honorable
has
the
prototype
in
java
already
the
pr
I
think
linked
here.
Can
we
get
some
commitment
from
some
another
language?
Is
that
what
I
mean?
What
what
do
you
want
specifically
for
next
monday.
C
C
I
also
well
worked
on
if
you
could
review
that
pr
as
well
would
be
nice.
I
will,
I
will
perfect
so
in
general
I
would
say
to
ask
that
I,
like,
I
think
it's
a
good
idea
to
have
more
eyes
like
really
paying
enough
attention
to
this.
D
Oh
yeah,
don't
I
don't
disagree,
I'm
just
trying
to
be
kind
of
specific
about.
K
C
Yeah,
so
I
could
say
prototypes
at
least
a
pair
of
different
languages
could
be
a
good
thing
and
overall,
more
attention.
I'm
just
saying
this
because
for
changes
from
previous
week,
we
had
enough
prototypes
for
some
new
features,
but
not
enough
people
review
them.
So
now
it's
like
we
need
both
of
them.
Prototypes
are
just
the
beginning.
C
D
Okay,
never
mind
there
were
a
couple
see
that's,
maybe
fixed
by
two
different
pr's.
I
think
the
other
pr
right
was,
if
you
scroll
yeah.
D
This
was
the
one
line,
change
of
just
saying
that
the
span
context
could
be
exposed
on
the
span
directly.
This
was
the
one
that
we
discussed
yesterday
that
the
decision
was.
We
should
do
it,
you
know,
remove
it
for
all
or
none.
K
I
don't
think
we
do
I'll
just
mention
that
people
should
take
a
look
at
this.
I
just
noticed
that
there
are
different
ways.
People
are
handling
b3s,
specifically
the
debug
flag
and
parent
span
id
tldr.
I
don't
think
we
can
propagate
parent
stat
id.
I
don't
think
we
probably
have
to
the
debug
flag.
We
probably
could,
but
not
a
lot
of
people
are.
K
B
B
K
L
B
L
Yeah,
I
think,
even
if
sipkin
implements
w3c
now
there
might
be
languages
where
lotteries
aren't
that
well
maintained,
which
still
rely
on
their
own
format,
and
I
think
it
should
be
so.
This
is
a
basic
feature
of
the
propagator
interface
that
it
can
propagate
something
through
from
one
end
to
the
other
that
isn't
in
w3z
right.