►
From YouTube: 2021-04-27 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
B
C
C
Okay,
you'll
see
we
can
start.
Thank
you
for
joining
as
usual.
C
Yes,
so,
let's
start
with
the
gender
items,
the
first
one
is
something
that
riley
and
me
discussed
in
the
past
three
hours
session
on
friday
regarding
bringing
back
the
triaging
time
slot
that
we
used
to
have
with
andrew
riley.
Did
you
want
to
talk
about
that.
D
Yeah
so
previously
we
started
a
friday
triage
meeting
just
to
like
pay
the
debts
we
had,
and
at
that
time
we
were
looking
at
like
30
or
40
issues
each
week,
but
now
it
seems
the
like.
The
the
incoming
issue
like
started
to
become
very
stable,
like
on
average
I've
I've
seen
between
three
or
seven.
So
I
I
think
if
we
can
take
seven
minutes
in
this
meeting
just
to
quickly
go
through
the
issue,
we
should
be
able
to
give
people
better
visibility
and
also
help
to
save
the
friday
time.
D
So
the
proposal
here
is
we
we
put
seven
minutes
buffer
here,
just
quickly
go
through
the
spike
issues
that
were
open
since
last
week,
that
had
haven't
been
tried
by
any
tc
members
and
if
it
turned
out,
we
can
finish
that.
Then
we
don't
need
a
special
friday
meeting.
If
we
have
more
issues
or
some
issue
will
require
more
discussion,
we
can
figure
out
whether
we
push
a
specific
sick,
for
example.
A
C
Okay,
next
point:
yeah
I
put
this
one
in
this
is
regarding
whether
and
it's
about
context
context
propagation,
about
the
context
layer
that
we
have
in
some
languages,
and
so
at
this
moment
we
are
using
it
to
store
spam
or
spam
context
and
baggage
mostly,
and
the
idea
is
to
allow
users
to
also
be
able
to
put
their
own
concern
there.
C
One
interesting
thing
while
I
was
doing
the
javascript
review,
is
that
they
also
have
this
suppress
instrumentation
concern
there
out
of
the
box
as
part
of
the
api,
and
this
is
not.
This
is
not
in
the
in
this
specification,
but
I
do
think
it's
very
useful,
of
course,
and
I
was
wondering
whether
this
can
be
considered
as
a
user,
whether
it
can
be
yeah,
consider
something
we
can
still
allow
six
to
have.
You
know
I
don't
know
whether
daniel
or
any
of
the
javascript
maintainers
is
in
the
call.
B
Yeah,
I'm
on
the
call
I
mean
I
can.
I
can
talk
about
somewhat
my
motivation
here
for
adding
this.
We
had.
You
know
you
have
an
exporter
that
uses
http
to
send
spans
to
some
back
end
right
and
we
have
an
automatic
http
instrumentation
that
instruments
all
the
spans.
If
you
instrument
the
export,
you
end
up,
you
have
to
export
that.
Also
you
end
up
in
an
infinite
loop
very
quickly,
so
we
needed
a
general
way
to
ignore
spans.
B
Our
first
approach
was
a
magic
header.
We
just
put
like
open
telemetry
span
and
the
value
was
one
and
everybody
agreed
that
that
was
it
worked,
but
it
was,
it
was
ugly
and
it
had
potential
side
effects,
and
things
like
that,
so
this
was
what
we
did.
B
I
I
feel
like
it's
a
good
solution,
but
I
understand
that
that's
not
really
what's
at
issue
here.
What
is
that
issue?
I
guess
is:
can
we
add
methods
to
the
api
and
from
what
I
understand,
the
guidance
here
has
been
yes,
as
long
as
those
methods
use
pre-existing
api
primitives
in
this
case
it
does.
It
uses
the
context
mechanism,
it
uses
the
context,
create
key
to
create
a
key
for
itself.
B
You
know
a
unique
key
and
it's
it's
just
a
convenience
method.
It
has
to
be
the
reason
it
has
to
be
in
the
api
and
we
couldn't
just
remove
it
and
have
the
same
functionality
in
the
sdk
only
is
because
that
key
needs
to
be
shared
through
potentially
multiple
copies
of
the
sdk.
B
B
So
there's
some
a
little
bit
of
my
defense
for
doing
it
and
honestly,
I
think
that
this
is
something
that
should
be
in
the
spec
at
the
time
we
did
this.
I
had
originally
meant
to
bring
it
up
to
the
spec,
but
I
was
busy
and
just
never
got
around
to
it
yeah.
For
for
me,
I
think
you
know
cigs
should
move
forward
solving
their
problems.
B
It's
more
that
we
should
be
bubbling
up
when
we're
adding
functionality
just
bubbling
up
and
making
the
other
cigs
aware
of
it,
just
because
there's
more
than
one
way
to
to
solve
these
problems,
and
ideally,
if
things
end
up
being
some
kind
of
problem
that
needs
to
get
solved
across
the
languages
that
other
cigs
are
like
aware
of
how
it
solves
somewhere
or
otherwise,
just
bubbled
up,
so
that
you
know
we
could
have
like
self-similarity,
where,
where
possible,
that's
yeah.
B
I
believe
other
cigs
are
also
doing
this.
I
think
python
at
least
had
a
similar
mechanism
of
storing
like
a
suppressed
instrumentation
flag.
In
the
context,
I
could
be
wrong.
It
might
be
removed
now,
but
at
the
time
I
believe
it
was
there,
and
the
second
thing
is
now
we're
having
actually
a
similar
question
the
when
it
comes
time
to
actually
create
suppressed
spans.
B
Are
we
yeah
this
thought's
not
fully
formed
I'll,
bring
it
up
at
another
time
next
week?
So
so
java
solves
this
in
the
at
the
by
the
agent.
The
agent
itself
has
code
internally
to
do
to
deal
with
this,
and
I
do
agree
that
having
sig
solve
the
problems
they
have
is
great,
but
this
makes
me
really
nervous
because
we're
adding
a
public
api
to
that
you
will
be
have
to
live
with
forever
in
their
javascript
implementation.
B
Well,
if
other,
if
we
decide
to
at
a
later
date,
add
this
to
a
public
api.
The
name
hasn't
been
talked
about
the
like
what
it's
supposed
to
do
hasn't
been
talked
about
like
this
is
a
public
api.
That's
been
added
ad
hoc
without
any
kind
of
discussion
about
naming
or
anything
like
that
that
we
normally
want
to
do
to
make
sure
that
there's
the
language
implementations
are
consistent
yeah.
So
that
was
my
primary
complaint
both
with
this
when
we
implemented
it
at
the
time
and
with
the
convenience
methods
that
have
been
talked
about
recently.
B
You
know
we've
been
sort
of
encouraged
to
add
these
like
span
creation,
convenience
methods,
but
they're
not
specified
what
the
name
should
be
or
how
exactly
they
should
behave.
So
I've
had
similar
concerns
for
what
it's
worth.
I
do
understand
that,
yes,
once
we
go
to
1.0,
we
are
stuck
with
this,
at
least
until
we
go
to
2.0,
which
could
be
a
long
time.
B
So
I
do
understand
that
yeah.
I.
C
C
B
The
sdk
api
split
is
very
strict
and
right
now
our
instrumentations
only
use
the
api,
so
they
can
be
used
with
third-party
sdks
and
stuff
like
that.
So
if,
if
some
vendor
wanted
to
implement
an
sdk,
they
the
instrumentation,
that's
trying
to
potentially
suppress
a
span
would
also
need
to
be
able
to
do
this
and
we
do
have
instrumentations
that
use
this
functionality.
So
your
original
use
case
was
an
exporter
which
has
access
to
the
sdk
right.
B
So
can't
the
exporter
sends
a
signal
to
the
sdk
that
this
is
hey,
don't
track
stuff,
that's
going
on
inside
me,
yeah
yeah,
and
that's
if
they
do
right
now,
but
they
should
just
the
instrumentation
api
to
do
that
right.
They
should
be
able
to
talk
to
the
some
sdk
api.
B
I
mean
I
don't
know
javascript,
but
it
seems
to
me
like
if
the
if
the
issue
is
the
exporter
that
has
access
to
sdk
apis
that
are
not
in
the
public
instrumentation
api
yeah
I
mean
the
exporter
is
one
use
case.
Another
use
case
is
potentially,
if
you
have
some
http
library,
that's
wrapped,
but
it
uses
the
standard
http.
B
You
know
standard
library
sort
of
under
the
covers,
then
you
would
end
up
with
two
spans.
So
if
your
high
level
library
wants
to
suppress
that
lower
span,
it
can
yeah
that's
something
that
the
agent
code
in
java
handles
with
a
special
set
of
agent
apis
that
are
not
regular,
instrumentation
apis
just
for
info,
don't
know
how
plausible
that
is.
F
I
think
I
think
my
two
sense
here
is,
if
possible,
to
not
have
in
the
main
api,
but
maybe
an
extension
similar
with
what
the
the
instrumentation
john
points,
because
that's
kind
of
an
extension
ap,
an
extension
artifact
to
the
api
will
be
a
more
feasible
thing.
So
if,
if
this
is
a
separate
package
because
it
can
be
a
separate
package
that
depends
only
on
the
api,
but
instrumentation
can
depend
on
them.
F
The
the
advantage
of
that
is
even
if
we
got
it
wrong,
we
don't
have
to
bump
to
zero
to
the
entire
api
we
bump
to
zero.
Only
to
this
extension,
instrumentation
helper
or
whatever
we
call
it
artifact
daniel
does
it
make
sense.
B
Yeah
so
then
I
I
need
clear
guidance
on
what
makes
this
different
than
the
helper
api
methods
that
we
were
talking
about.
You
know
in
the
last
few
weeks,
so
so
I
think
the
main
difference
here
is
this
is
actual
functionality
right
like
like
you're
putting
something
in
that
the
sd
that's
going
to
actually
control
the
sdk
that,
as
opposed
to
something
that's
that's
purely
higher
level
functionality
right,
if
I'm
correct
like
this,
isn't
something
that
just
it
doesn't
just
wrap
up.
Other
api
calls.
B
It
seems
like
it
puts
something
into
the
context
that
then
the
sdk
looks
at
when
it's
trying
to
decide
whether
or
not
to
report
instrumentation
right
well,
one
of
the
api
calls
is
to
create
a
key
and
another
one
is
to
set
a
value
using
a
key.
So
it's
just
wrapping
those
two
calls
right.
F
Nah
it
it
is
a
bit
different.
So
so,
if
you
think
about
the
contract
between
the
api
and
sdk,
this
adds
another
contract
between
the
8k
and
the
sdk
that
the
presence
of
this
value
inside
the
context
has
some
side
effects.
The
the
the
extra
or
helper
api
that
we
are
discussing
in
the
past
couple
of
weeks
are
not
adding
new
contracts
between
api
and
sdk
correct.
F
It's
just
like,
instead
of
user
starting
a
spam
which
they
already
were
able
to
do
and
then
doing
activate
or
whatever
is
called
set
into
the
context,
as
second
call
they
do
it
in
one
call
okay,
so
so
the
contract
between
the
api
and
sdk
is
still
the
same.
There.
There
is
the
functionality
of
starting
a
span
and
and
setting
it
to
the
context.
F
F
E
In
my
opinion,
okay,
so
I'm
I'm
happy
to
remove
it.
If
you
guys
think
that's
what
I
should
do
like
john
said,
I
can
put
it
in
the
sdk
and
then
it
will
be
available
for
at
least
the
exporters
so
so
make
it
make
it
make.
F
It
a
separate
package
called
extension
or
whatever
api
api,
instrumentation
helper
or
whatever
you
call
it,
but
that
that
way
you
don't
have
to
put
it
in
the
sdk.
So
you
don't
force
all
the
instrumentation
to
depend
on
the
sdk.
They
depend
only
on
this
helper
package.
That
helper
package
depends
only
on
the
api.
So
you
stick.
You
stick
with
the
dependencies
to
not
force
everyone
to
depend
on
the
sdk,
but
you
have
the
freedom.
If
we
get
this
wrong
to
move
to
this
package
easier
to
zero,
compare
with
the
main
api.
E
C
C
Then,
probably
in
the
because
I
I
was,
I
was
checking
the
separation,
probably
in
the
core
package,
which
is
like
the
the
core
of
the
implementation.
Probably
it
could
be
good
good
spot
yeah.
B
Okay,
yeah,
but
I
think
also
we
need
to
just
make
sure
it's
feasible
to
be
raising
these
things
in
a
cross-language
fashion,
because
I
assume
you
know
different,
like
cigs-
are
going
to
continue
to
encounter
production
issues
like
this
right,
where
it's
like,
I
need
to
add
some
functionality
and
in
some
cases,
that's
going
to
be
like
clearly
language
specific
functionality,
but
you
know
in
other
cases
it's
gonna
be
like
you
know.
B
This
is
like
a
cross-language
issue
or
probably
is
and
just
figuring
out
a
middle
ground
where
we're
not
blocking
every
change
a
cig
wants
to
make
on.
You
know,
pushing
it
through
a
big
committee,
but
making
sure
that
the
the
stuff
doesn't
get
lost
along
the
way
so
that
we
don't
end
up
replicating
like
the
same
solution
like
solving
the
same
problem
like
eight
different
ways.
B
F
Yeah,
okay,
absolutely
thumbs
up
also
yeah,
definitely
definitely
so
so
the
options
in
my
mind
for
for
library,
maintainers
and
language
maintainers,
you
either
put
it
in
an
extension
api
which
extension
package,
which,
if
we
get
it
wrong,
we
can
throw
it
away.
We
can
move
to
2-0
or
whatever,
or
we
do
a
spec.
G
I
do
have
a
question:
what
happens
if
some
other
like
language
implements
something
similar
and
you
get
a
context
across
the
wire
that
has
that
same
key,
like
different
type
of.
E
B
B
Generally
speaking,
you
can't
add
much
in
the
way
of
functionality
there,
because
we
have
to
support
older
propagation
headers
like
b3,
for
example,
that
don't
have
room
for
for
like
additional
state,
so
that
that's
very
tricky.
I
think
what
he's
talking
about
is
baggage,
which
used
to
be
called
correlation
context.
I
think
it's
just
the
naming
mix.
F
F
But
but
if
it
comes
to
cross
languages,
we
have
to
discuss
with
everyone,
because
in
order
to
make
it
successfully
working,
we
need
support
from
other
languages.
So
there
is
zero
zero
benefit
of
implementing
something
like
this
only
in
one
language,
because
it
will
not
work
with
java,
for
example,
or
with
other
languages.
B
Yeah,
and
by
the
way,
this
is
also
a
good
example
of
something
that
you
know
that
we
run
into
certain
things.
We
try
to
spec
out
that
do
end
up
working
in
a
genuinely
different
manner
in
different
languages,
and
so
the
spec
has
to
be
a
little
soft
like,
for
example,
it
sounds
like
in
javascript
it's
it's
really
helpful
for
this
to
be
part
of
the
public
api,
but
I
could
see
in
other
languages
like
it's
not
necessary
for
it
to
be
part
of
the
public
api.
B
It
just
sounds
like
in
javascript
that
it
happens
to
be
helpful,
but
I
can
see
other
languages
being
like
well.
This
is
really
just
the
whole
point
of
this,
or
the
motivating
issue
is
is
to
not
have
to
not
accidentally
instrument
our
own
spans
and
you've
got
languages
like
so
it
wouldn't
have
to
be
public,
and
you
have
languages
like
java,
where
they're
doing
it
entirely
through
byte
code
manipulation.
B
So
it's
going
to
work
a
little
bit
different
there,
but
but
there
often
is
some
some
core
of
like
stuff
that
that
is
similar,
or
at
least
like,
if
you're
going
to
implement
this
and
have
to
talk
about
it
with
your
users
like
try
to
use
the
same
names,
use
the
same
configuration
options
like
that
kind
of
stuff.
So.
B
Just
want
to
point
out:
that's
why
it
is
helpful
to
to
put
this
stuff
in
the
spec,
even
if
each
language
does
have
like
a
different
way.
It
goes
about
implementing
it.
F
It's
also,
I
think,
if
I
understood
correctly,
it's
also
a
contract
between
two
different
instrumentations,
like
the
http
case
that
daniel
said,
like
you,
have
a
library
that
wraps
the
the
core
http
library,
which
is
already
instrumented,
and
somebody
instruments,
this
high
level
library
and
you
don't
duplicate
spans
or
or
something
like
that.
F
So
it's
also
a
contract
between
instrumentations.
So
then
it
has
to
somewhere
be
public,
because
because
these
two
instrumentation
have
to
communicate
via
that
public
api,
that
hey
I'm
doing
this,
you
don't
do
that
or
something
like
that.
B
So,
to
be
clear
and
again
correct
me
if
I'm
wrong
daniel,
I
think
there's
there's
two
issues.
There's
a
motivating
issue
which
is
hey.
We
don't
want
the
sdk
to
instrument
itself,
because
that
just
creates
a
loop
and
that's
obnoxious.
However,
we
instrument
the
sdk
is
got
to
be
done
separately
and
then,
when
you
have
auto
instrumentation,
that's
potentially
binding
to
local
stuff
we're
using.
B
How
do
you
prevent
that
from
happening
and
in
some
languages
like
java,
they
just
have
a
way
of
getting
that
out
of
the
way
for
the
sdk
without
exposing
a
feature,
but
on
the
other
hand,
the
features
like
on
its
own
kind
of
useful,
which
is
like
you
can
see
end
users
being
like.
I
want
to
suppress
some
instrumentation.
This
actually
comes
up
with
http
all
the
time
around
things
like
heartbeats
and
health
checks
and
and
other
stuff,
like
it's
pretty
common
requests
to
be
like
hey.
B
I
don't
care
about
this
thing
and
how
we
end
up
solving
that
problem
may
or
may
not
be
the
same
same
mechanism
here,
like
maybe
that's
like
configuration
that
you
put
in
for
http
libraries.
That's
required
not
that
this
feature
has
to
go
away
in
javascript
to
do
that,
but
just
just
pointing
out
that,
like
it's,
if
you
tease
this
apart,
there's
there's
two
separate
issues
just
for
information,
not
recommendation
for
any
other
language,
but
the
way
the
java
agent
does
this.
Is
it
actually
takes
the
entire
sdk
relocates
it
package
wise?
B
B
Right,
but
this
is
definitely
relates
to
figuring
out
what
kind
of
configuration
people
want
for
instrumentation,
which
is
an
area
where,
broadly
speaking,
we
need
to
put
some
effort,
because
it's
not
just
gonna,
be
this
particular
issue
like
this
was
motivated
because
there
was
an
internal
need
for
it,
but
our
end
users
in
general,
want
to
configure
their
instrumentation
to
a
certain
degree,
and
we
actually
don't
have
any
specs
right
now
on
like
what
should
those
configuration
options
be?
B
In
other
words,
our
semantic
conventions,
describe
like
what
data
you
should
generate,
but
they
don't.
We
don't
provide
guidance
for
what
configuration
options
you
should
be
supplying,
along
with
this
instrumentation,
to
change
things
like
the
operation
name
or
how
to
suppress.
B
You
know
http
patterns
and
things
like
that,
so
that
that's
just
a
general
area
where
I
think
we
need
to
improve
our
conventions
so
that
that's
why
I
was
mentioning
that.
B
And
that's
also
an
area
where,
if
we
don't
have
standardization,
I
know
from
from
experiences
like
every
instrumentation
library
starts
to
just
get
configuration
options
kind
of
like
packed
onto
it,
because
what
end
users
do
is
they
just
open
an
issue
on
that
particular
piece
of
instruction
they're
using
and
be
like?
Hey?
Can
you
like
tack
this
thing
on,
and
this
happened
at
open
tracing,
since
all
the
instrumentation
was
kind
of
maintained
separately?
B
And
so
what
you
end
up
is
this
kind
of
like
nest
of
of
configuration
options
that
ended
up
making
like
configuration
in
general
kind
of
more
difficult,
because
you
have
to
go
look
up
a
whole
bunch
of
stuff
in
a
whole
bunch
of
different
places
to
figure
out
how
how
to
configure
your
stuff.
So
so
it
would
be
helpful
if
we,
if
we
figured
out
a
way
to
standardize
at
least
some
instrumentation
configuration
options
like
the
common
common
stuff
that
we're
putting
into
the
semantic
conventions.
C
B
C
B
Yeah,
well,
it's
just
it's.
What
naturally
happens,
I
think
in
an
ecosystem,
if
you
don't
provide
guidance
and
then
tooling,
to
help
people
write
this
stuff,
so
we're
we're
really
heads
down
just
trying
to
get
1.0
shipped,
but
but
sorting
out
this
instrumentation
ecosystem
once
people
start
having
time
to
do
that,
that's
that's
going
to
be
longer
term
like.
I
think
we
need
to
put
a
lot
of
our
effort.
B
It's
just
right
now.
It
seems
like
we're
the
core
maintainers.
You
know
we're
in
this
spec
committee,
we're
just
kind
of
spread
a
little
too
thin
to
be
to
be
dealing
with
that.
It's
like
a
full
force
effort,
but
if.
B
To
do
that,
please,
let
me
know,
because
that's
a
thing
we'd
like
to
solve
in
parallel.
B
Okay,
but
for
this
specific
issue,
I'm
going
to
create
a
spec
pr
and
we're
all
we're
all
agreed
on
that
right.
Okay,
well,
have
you?
Is
this
gone
into
a
1.0?
Yet
I
can't
remember
it's
rc,
okay
yeah,
right,
which
the
whole
point
of
rc's
is
to
be
able
to
remove
things
before
you
release,
so
it
is
changeable,
yeah
yeah.
I
think
it
would
be
helpful
to
get
this
get
this
into
the
spec.
B
It
seems
it
does
seem
to
me
like
a
reasonable
general
purpose
mechanism,
but
if
it
is
something
if
it's
something
that
instrumentation
doesn't
have
to
deal
with,
if
it's
something
that
end
users,
configuring
and
the
sdk
is-
is
dealing
with
as
just
a
general
purpose.
I
don't
want
that.
I've
got
this
package
over
here
or
this
thing
over
there,
and
I
just
want
that
off.
It's
like,
regardless
of
how
I'm
configuring
instrumentation
just
a
general
purpose.
B
Turn
things
off
can
be
helpful.
That's
partially
why
we
had
like
the
name
tracers.
I
believe
that
was
like
a
motivating
force
for
the
the
whole
name.
Tracer
business
is
like
that's
one
way
to
to
disable
instrumentation,
but
you're
talking
about
like
a
a
way.
That's
like
a
little
bit
different,
it's
not
the
whole
instrumentation
source,
but
a
particular
application
of
that
source,
and
so
you
know
how
do
you
deal
with
that?.
H
I'm
just
going
to
throw
out
there
that
ruby
has
a
similar
method.
It's
in
this
common
utilities,
gem
we
actually
kind
of
ship
it
separate
from
the
api,
but
it's
called
untraced
and
it
takes
like
a
block
and
basically
it
it
does
the
same
thing,
but
it
works
differently.
It
will
make
the
active
span
a
no-op
span
and
then
execute
the
block,
thereby
discarding
those
children's
fans.
H
F
Fyi
in
open
senses,
we
had
what
we
call
the
blank
span
and
we
were
asking
users
when
they
want
to
do
untrace
just
to
swap
the
current
active
span.
With
that
blank
span
or
knob
span
and
no
span,
you
don't
have
to
create.
Always
you
can
have
only
one
instance
to
avoid
allocations
and
stuff
and
and
have
this
blank
span
concept
that
can
can
can
do
the
same
thing
as
as
matt
pointed
in
in
ruby.
H
H
Suppress
instrumentation
concept
and
kind
of
the
implementation
where
this
works
through
the
concept
or
the
context
would
technically
allow
you
to
stop
recording
multiple
signals
if
you
wanted
to.
Whereas
this
thing
is
like
totally
kind
of
only
going
to
affect
tracing
yeah.
B
Yeah,
I
do
have
a
related
question
that
I
have
already
taken
up
a
half
hour,
so
I
suppose
I
may
as
well
take
a
little
bit
more
when
you
create
when,
when
you
do
suppress
instrumentation,
regardless
of
how
you
do
it,
if
you
create
a
no
op
span
right
now
in
the
api
specification
is
no
specified
way
to
create
a
no
ops
fan
or
a
non-recording
span.
B
How
is
everybody
else
handling
this?
Have
you
re-implemented
a
no
opera
non-recording
in
the
sdk?
It
already
has
to
exist
in
the
api
in
order
for
the
api
to
work,
or
are
you
guys
just
exporting
it
from
the
api
and
using
it?
Even
though
this
api
is
or
that
the
specification
is
technically
not
there,
it's
you
know
related.
What
can
we
export
from
the
api?
That's
not
in
the
spec.
I
So
opinion
that
particular
use
case
you
can
solve
the
current
spec
because
there
are
two
parts:
one
you
must
be
able
to
create
the
span
context
with
the
api
and
the
other
is
you
must
be
able
to
wrap
this
bank
context
in
a
non-recording
span.
So
these
two
features
are
in
the
api
spec.
I
think,
if
you
combine
them,
you
can
create
the
release,
pin.
F
That's
true,
but
also
also,
there
has
to
be
an
op
span
somewhere.
Maybe
it's
hidden
in
the
api,
because
the
specs
also
says
that
from
the
context
we
should
not
return
null
span.
We
should
return
an
op
when
the
implement
is
so
the
reason
of
somewhere,
maybe
is
not
exposed
publicly,
but
the
concept
or
the
functionality
should
be
there.
B
Yeah,
no,
I
know
it's
there,
but
when
you're
in
the
sdk
and
you're
trying
to
create
a
no
op
or
non-recording
span,
and
if
it's,
if
that
functionality
itself
is
not
exported
from
the
from
the
api
than
what
you
do
yeah
or
do
you
export
it
from
the
api?
I'm
just
wondering
how
other
cigs
have
handled
this
problem.
B
F
B
Where
I'm
curious
about
the
trickiness
here,
I'm
curious.
What
people
do
we've
been?
The
use
case
we've
been
talking
about
is
client
spans
right,
like
the
last
fan
on
the
way
out,
we're
saying
we
don't
care
about
that.
But
what
happens?
If
someone
does
this
with
a
span
that
ends
up
having
a
lot
of
children
like
a
server
span
or
something
like
that?
I'm
curious
what
the
current
implementations
do
with
the
context:
implementation.
B
B
So
if
we
have,
for
instance,
the
http
instrumentation
is
properly
non-recorded
or
whatever,
but
then
you
have
like
the
dns
call
as
a
part
of
that
and
that
one
is
instrumented,
then
you
end
up
in
the
same
infinite
loop
and
you
end
up
not
only
in
an
infinite
loop
but
with
infinitely
creating
orphan
disbands
that
don't
make
any
sense,
which
is
in
some
ways
worse
right,
yeah
it
that
does
seem
like
the
thing
you
would
want.
Is
it
just
you're
just
stopping
the
whole
context
from
propagating
from
that
point
onwards?
B
So
it's
just
curious
if,
if
that
was
how
you
went
about
doing
it
but
yeah
that
seems
like
the
right
solution,
it
sounds
like
now
we're
talking
about
potentially
two
specification
extensions
though
the
one
is
the
not
the
the
suppress
instrumentation
context,
and
the
second
is
exporting
a
no-op
tracer
singleton
of
some
kind
or
something
like
that.
Or
is
that
idea
too
half-baked
to
make
a
pr4?
Yet.
B
F
Yeah,
I
would
say
one:
it
wouldn't
hurt.
Sorry,
then,
yes,
exactly
you,
you
will
benefit,
you
will
benefit
to
have
it
documented.
So
as
long
as
somebody
has
time.
B
And
with
that,
I
think
I'm
done
taking
up
everybody's
time,
I
dominated
the
meeting
kind
of
no,
it
was
really
helpful.
I
mean
and
again
I
think
that
the
major
takeaway
is,
let's
you
know,
for
sig
maintainers.
Let's
just
make
sure
we're
we
get
so
heads
down
in
our
individual
implementations,
because
we
got
a
ship.
We've
got.
You
know,
pressure
to
ship
but
making
sure
it's
it's
not
painful
to
to
raise
issues
with
the
larger
community.
B
When
we're
encountering
problems
or
not
problems,
I
say
we're
encountering
things
where
we're
we're,
adding
things
that
that's
outside
of
the
spec
making
sure
we're
just
making
the
rest
of
the
community
aware
that
that's
going
on,
I
think
that's
like
a
best
practice.
We
just
want
to
get
in
the
habit
of
doing
so
that
we're
not
surprising
ourselves
later,
even
if
it
ends
up
being
something
where
we're
just
adding
it
like
an
extension
like
like
bug,
been
saying,
it's
just
helpful
to
know
when
these
issues
are
popping
up.
B
K
Accessor
on
the
span
interface
itself,
it
does
what
christian
was
saying.
It
basically
just
wraps
a
propagated
spam
with
an
invalid
context,
but
we
do
use
the
tracer.
I
I
will
show
you.
We
do
use
the
diff
node
tracer
in
a
couple
of
places,
yeah
there's
a
couple
of
places,
but
there's
this
specific
one
we
can
implement
just
for
the
essentially
what
christians
said.
B
C
See
you,
okay,
are
we
grab
with
this
point,
or
somebody
has
something
else
to
add.
C
I
think
we're
good
yeah
is,
I
don't
know
we
have
17
minutes.
I
don't
know
whether
the
metrics
group
wants
to
give
an
update.
If
there's
not
anything
important
to
report,
we
can
just
call
it
away.