►
From YouTube: 2021-04-01 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
B
B
B
We
got
a
number
of
people
here.
Alex
said
he's
gonna
be
a
few
minutes
late,
so
I
think
we
can
just
get
started.
B
B
Yeah
so
cool,
so
we
released
tracing
1.0
last
week,
good
job
everybody,
on
keeping
up
to
speed
with
that
you
could
take
a
look
at
the
medium
article
that
we
posted
this
weird
ass
amalgamation
of
python
and
open
telemetry
symbols.
So
take
a
look
at
that.
You
know
share
with
your
friends
and
stuff,
it's
pretty
awesome
cool
next
thing,
so
we
talked
about
the
whole
like
stale
issues,
kind
of
stuff.
B
We
have
like
a
lot
of
issues
in
our
backlog
right
now,
and
we
decided
that
you
know
we're
going
to
kind
of
adopt
with
what
the
specs
is
kind
of
doing
in
terms
of
like
marking
them
as
stale
and
closing
them
automatically.
If
no
one
comments
or
takes
any
interest
on
these,
so
we
added
some
prs
to
add
some
github
actions
that
pretty
much
marks
it
as
a
backlog
issue
after
30
days
of
inactivity
and
then
it's
60
days
until
it's
automatically
closed.
B
You
know
this.
We
just
kind
of
we're,
taking
the
stance
that,
like
we're,
not
saying
that
these
aren't
important.
It's
just
that
it's
not
important
enough
right
now
to
someone
or
to
whoever
opened
it
in
the
first
place
and
if
it
is
still
important,
we
expect
people
to
like
open
it
up
again
as
a
new
issue,
because
some
of
these
were
created
even
before
me
and
alex
were
maintainers.
So
we
we
don't
even
remember
a
lot
of
them,
so
it's
not
practical
to
leave
them
open
and
address
them.
D
Is
what
we're
going
to
be
doing
yeah?
This
is
just
our
way
of
trying
to
close
that
adding
windows
ci
that
issue
that
aaron
opened
like
in
june
of
2020
or
something,
and
we
wanted
to
be
very
passive,
aggressive
about
it.
B
B
All
right,
nice,
okay,
so
now
that
you
know
tracing
1.0
is
released
kind
of
what
is
the
focus
now,
for
you
know
like
our
sig
in
the
general
direction,
so
like
open,
telemetry
kind
of
like
is
trying
to
focus
a
lot
on
the
instrumentations
now,
mostly
specifically
the
semantic
conventions.
B
I
know
a
lot
of
customers
and,
like
vendors,
are
waiting
on
semantic
conventions
to
be
marked
as
stable,
so
we
can
actually
start
utilizing
this
in
our
instrumentations
and
possibly
marking
them
as
stables,
so
people
can
start
taking
dependencies
on
these.
It's
just
so
probably
be.
You
know
trying
to
be
more
active
in
the
contrib
repo
making
out
our
documentations
and,
like
our
api
surface,
pretty
sleek
and
intuitive
for
users.
So
that's
pretty
much
what
it
is
same
thing
metrics.
You
know.
B
As
you
know,
a
lot
of
effort
has
been
been
going
into
revamping
the
metrics
api.
I
believe
we're
trying
to
redo
the
entire
thing,
albeit
it's
going
to
be
fairly
similar
to
what
we
have
already
the
I
know
recently
in
the
specs,
a
new
counter.
B
Api
spec
has
been
merged
and
right
now
there
was
a
pr
that
was
opened
by
rally
nine
hours
ago
for
the
observer.
So
anyone
who
is
interested
please
take
a
look
at
that.
D
I
did
want
to
make
a
quick
mention
here,
while
we're
talking
about
the
metrics
api
changes
that
that
that
drove
us
to
closing
a
bunch
of
the
existing
metrics
issues
in
our
backlog,
just
because
they
were
all
very
specific
to
the
terminology
that
was
used
in
the
spec
before,
and
we
thought
it
would
be
very
confusing
to
have
like
a
bunch
of
issues
that
would
ask
users
to
or
someone
to
go
and
implement
the
old
spec
without
reviewing
the
new
specs.
D
So
we
just
close
them
for
now,
and
you
know
if
you
feel,
like
we've
closed
any
of
the
issues
accidentally
or
that
it
was
a
mistake
or
whatever
feel
free
to
reopen
them.
But
that's
why
we
closed
a
bunch
of
them.
This
morning,
yeah.
C
C
Sorry
yeah:
are
we
still
going
to
do
like
a
1.0.0
beta
release
of
the
metrics
that
we
have,
or
we
just
can
hold
that
off?
Yes,
we're
still
doing
that.
B
Like
an
experimental
release,
I
think
alex
will
be.
D
Yeah,
with
the
strong
caveat
that,
like
all
of
this,
will
very
likely
change
so
just
yeah
just
throwing
it
out
there
yeah.
B
Cool
we
did.
We
did
do
that
whole
branch
splitting
thing
for
a
reason,
so
I
don't
want
to
go
back
on
that
so
yeah
cool
yeah.
So
we
do
have
some
representatives
from
python
sig
that
I
see
in
the
metrics.
B
I
know
aaron
is
a
very
avid
attender,
so
it'd
be
too
good
to
keep
up
with
like
what's
going
on
in
that
world,
especially
if
you
guys
care
about
it
in
your
respective
companies
and
stuff,
because
they're
they're
moving
pretty
fast
now
like
compared
to
when,
like
I
guess
before,
riley
was
took,
took
charge
of
the
api
and
like
the
separation
between
the
otlp
data
model
group
and
the
api
group.
So
there's
a
lot
of
like
discussions
that
need
more
contributors
and
more
input.
B
B
Yep,
that's
pretty
much
it
for
that
convenience
api.
This
is
something
like
an
effort
that
ted
is
working
on
with
a
lot
of
the,
I
guess
other
tc
members,
and
we
have
a
representative
from
microsoft,
working
with
them
too.
This
is
like
kind
of
driven
by
like
for
our
side.
At
least
you
know
like
what
it
means
to
like
improve
like
adoption
of
a
product.
B
A
lot
of
the
discussion
is
trying
to
get
like
consensus
across
languages
for
certain
api
editions
that
will
make
it
convenient.
For
you
know,
new
users
to
adopt
our
libraries
and
obviously
like
the
pms,
would
be
interested
in
that
so
from
a
product
perspective.
If
you
guys
know,
people
are
interested
in
like
how
to
how
to
get
like
customers
hyped
about
this.
You
know
about
like
cool,
convenient
slick
stuff
that
they
can
use.
B
You
know
this
is
probably
a
good
time
to
contribute
and
like
talk
about
that
and
start
a
discussion
about
that
and
reach
out
to
ted
about
it,
so
they
have
active
development
or
designing
going
on
right
now
about
that
cool.
And,
lastly,
we
have
something
that
I
kind
of
took
notice.
It's
the
auto
instrumentations.
B
So
if
you
guys
notice
like
a
lot
of
the
issues
and
like
comments
that
we
get
in
the
slack
or
the
getter
before
or
the
github
issues
relate
to
people
trying
to
use
our
auto
instrumentation
libraries,
which
is
like
just
cool
things,
that
away
plus
others
have
added
and
contributed
to
these
are
never
actually
officially
spec'd
or
anything.
It's
just
like.
B
We
thought
that
it
was
a
great
feature
and
obviously
customers
think
so
too,
because
they're
mainly
using
this
a
lot,
and
I
don't
know
if
they're
coming
up
with
issues,
because
it's
just
not
specced
out
well
but
because
of
like
the
the
obvious
usage
of
it.
I
feel
like
it's
important
for
us
to,
even
though
we're
we're
not
officially
open,
telemetry,
isn't
officially
taking
the
stance
of
like
hey
we're,
we're
mark
we're
gonna
be
supporting
this.
This
can
be
stable.
B
So
we
have
been
kind
of
ignoring
all
of
that
for
a
bit
because
of
this
whole
tracing
stable
and
stuff,
but
I
think
it
is
a
good
time
to
like
at
least
make
sure
our
documentation
is
clean.
You
know
like
we're
very
consistent
with
our
messages
about
what
we
offer
and
you
know
and
how
to
do
it.
I
think
what
we
have
currently
is
pretty
great,
like
we
have
very
extensive
examples
and
documentations.
B
But
we
haven't
officially
like
went
through
like
a
process
or
anything
mostly
because
it's
not
specked
out,
so
it's
something
I
didn't
want
to
like
bring
to
everyone's
attention
that,
like
we're
gonna,
try
to
put
more
focus
to
make
this
like
a
fish
like
pseudo
official.
I
guess
so
instead
of
just
like
seems
like
a
hackathon
kind
of
thing,
so
yeah
any
questions
regarding
the
four
topics
we
talked
about.
B
Cool
nice,
so
next
thing
aaron
deleted
packages
had
some
impact.
Oh,
this
is
going
to
be
awesome.
C
Yeah,
so
look
so.
This
is
like
a
demo
project
that
that
some
folks
in
google
well,
they
use
it
for
like
for
like
showing
off
sort
of
like
all
of
our
operation
stuff.
C
I
don't
maintain
this
one,
but
they
added
they
added
open
telemetry
and
they
were
on
this
old
version
and
I
just
got
pinged
internally
when
the
packages
got
deleted
and
like
luckily
it
wasn't
a
big
deal
for
us
just
because
it
was
this
and
I
haven't
heard
anything
from
our
customers.
But
I
was
wondering
if
anybody
else
had
any
impact
and
then
just
wanted
to
confirm,
like
we
don't
have
any
plans
like
like
going
forward
to
rename
stuff.
D
I
think
so
to
answer
your
first
question.
D
I
I
haven't
heard
anything
from
any
of
our
customers
and
in
like
in
my
mind
now
that
these
packages
have
been
released
and
we
have
like
a
1.0
label
associated
with
a
with
a
bunch
of
these
like
I,
I
would
expect
that
we
would
want
to
do
the
the
same
thing
that
the
grpc
I
o
package
did
where
there's
like
a
basically
like
a
like
an
updated
last
release
of
like
any
old
packages
that
just
point
users
to
the
new
to
the
new
package
as
opposed
to
like
removing
them.
C
Yeah,
okay,
did
anybody
happen
to
see
a
graph
like
the
download
graph
like
the
usage
graph
before
we
did
it
like
it
was?
It
was
really
well
right.
B
Yeah,
it
was
quite
low.
However,
there
was
still
like
not
like
recently,
but
there
were.
There
were
like,
maybe
like
a
couple
downloads
like
before,
but
maybe
there
was
from
like
mirrored
sites,
I'm
not
sure,
but
yeah.
D
Yeah
yeah,
the
the
download
stats,
are
they're
kind
of
confusing,
because
if
you
look
at
like
the
download
size
for
the
api
package,
for
example,
like
the
0.4a
package,
version
of
the
api
package
is
still
being
downloaded
today
like-
and
this
is
like
you
know-
not
not
a
significant
amount.
But
if
you
look
at
the
stats
like
it,
it
seems
like
we
never
actually
reach
zero.
With
many
of
the
packages
that
we
have.
C
Yeah
yeah
yeah
as
long
as
yeah,
I
think
what
you
mention
alex
like
what
grpc
does,
where
we
create
like
a
final
release
that
just
points
people
to
the
other
one
or
that
downloads,
the
other
one
would
well
probably
pointing
people
together
would
be
better,
so
they
don't
have
it
in
their
requirements.
But,
okay
and
there's
no
hide
option
in
in
pi
pi.
It
was
like
there
was
something
called
yank
right
is
that
is
that
the
only
thing
that
we
saw
in
there
that's
another
option.
D
B
Actually
doesn't
solve,
like
the
issue
that
we
were
trying
to
address
was
that
we
were
trying
to
reduce
the
amount
of
manual
support.
We
have
to
do
for
customers
coming
to
us
and
being
confused
about
which
package
we
want
to
install.
C
Right,
but
I
think
the
thing
with
the
yanking
is
they
have
to
specify
exactly
the
package
version,
otherwise
it
won't
download
and
I
could
I
could
be
wrongly.
I
don't
know
what
happens
if
if
the
latest
version
is
the
yanked
one,
if
it
will
then
download
it
as
well
or
what
happens
but
okay,
that's
that's
fine.
I
think
I
think
I
accidentally
cut
alex
off
too.
B
B
C
Yeah
I'm
confused
because
I
talked
to
the
js
sig
like
yesterday
and
daniel
talked
to
the
tc
and
they,
I
think,
they've
sort
of
decided
that
they're
going
to
like
not
formally
require
this.
So
I'm
kind
of
confused
yeah.
B
Yeah,
the
message
was
like
it
was
optional
like
it's
something
that
would
improve
your
confidence
in,
like
the
stability
of
your
api
service,
but
nobody
expected
an
actual
like
you
have
to
submit
like
a
form
and
stuff,
but
I
think
this
is
just
for
like
visibility
purposes,
you
know
it's
like
hey.
These
are
the
issues
that
we
found.
B
I
think
this
is
pretty
valuable.
It's
not
too
bad
discussions.
B
D
B
B
Whatever
is
a
way
here
today:
hey
yeah,
hey,
what's
up
cool,
so
I
think
this
is
something
that
was
brought
up
due
to
some
issue
that
we
found
or
not.
We
found,
but
it's
like.
It's
also
part
of
the
whole
auto
instrumentation
effort
they're,
trying
to
make
it
better.
Do
you
wanna
just
kind
of
like
summarize
what
this
is
about.
G
Yeah,
so
so
the
main
issue
is
that
python
packaging
does
not
have
a
way
to
way
to
way
for
a
maintainer
to
say
that
this
package
is
compatible
with
a
specific
version
range
of
another
package,
but
not
have
that
package
as
a
dependency.
G
G
So
to
achieve
that,
we
are
we're
adding
the
target
libraries
as
dependencies,
but
there
are
downsides
with
it
because
so
there
have
listed
in
detail
some
limitations,
but
but
the
main
limitation
is
that
we
cannot
ship,
like
users
have
to
be
very
careful
about
which
instrumentations
they
install.
Otherwise,
if
they
let's
say,
install
everything
or
if
we
had
a
had
a
meta
package
like
instrumentations
all
on
instrumentation
country.
G
If
that
just
installs
everything,
then
it
would
also
pull
in
all
the
target
dependencies,
so
it
will
install
flask,
falcon
django
everything
and
that's
obviously
not
feasible,
so
to
do
a
work
around
that
we
have
the
bootstrap
command,
which
no
other
hotel
project
has.
So
the
bootstrap
command
detects
what
you
have
installed
and
just
installs
those
packages.
G
So
because
of
this
dependency
thing,
we
have
this
complicated
a
bit
of
friction
in
getting
started
with
hotel
and
there
are
some
use
cases
that
are
not
possible,
for
example,
with
lambda
or
with
some
serverless
environments,
it's
hard
to
figure
out
where
to
run
bootstrap
exactly
depending
on
what
system
you're
like
what
deployment
system
or
what
tools
you're
using
to
package
and
to
deploy
your
lambda.
So
it
would.
G
I
think
it
would
dramatically
simplify
everything
if
we
didn't
have
to
specify
target
libraries
as
dependencies,
so
they
didn't
get
installed
and
we
had
an
alternate
way
to
to
identify
compatible
packages.
So
node
does
this
and
java
does
this?
So
what
what?
What
they
do?
Is
they
don't
specify
this
as
dependencies,
but
they
at
runtime
check,
which
version
is
installed
like
each
instrumentation
when
it
runs
it
checks?
G
If
a
compatible
version
is
installed
and
then
applies
the
patches
and
if
it
doesn't
find
a
compatible
version,
then
just
like
no
op
skips
and
builds
up,
so
I
think
we
can
do
something
pretty
similar.
Most
python
libraries
do
ship
the
version
number
in
code,
so
you
can
import
double
underscore
version
from
most
libraries
that
I
know
so
that
would
be
one
way
to
identify
and
another
way
would
be
to
use
a
package
called
package
resource.
G
Could
you
scroll
down
a
bit
yeah
so
so
far,
I've
not
seen
any
issues
with
package
resource.
It
has
been
pretty
reliable,
but
I
have
not
used
it.
That's
really
that
that
much
so
I
don't
know
there
might
be
edge
cases
so
we'll
have
to
investigate
a
bit
deeper.
G
C
Away
the
goal
here
is
to
make
it
easy
to
install
like
the
like
a
meta
package
with
all
of
the
instrumentations
included
right.
G
Yeah,
I
think
that
would
be
that'd
be
one
of
the
major
reasons,
so
we
could
yeah.
We
could
ship
like
hotel
distro,
could
ship
meta
every
single
instrumentation
as
a
dependency
and
everything
gets
installed,
and
since
each
instrumentation
is
very
lightweight,
it's
just
a
few
kilobytes.
It
wouldn't
have
any
adverse
effect.
So
people
could
just
install
one
package
and
everything
would
just
work
automatically.
C
F
G
I
I
think,
that's
what
we
do
today
with
bootstrap,
so
we
detect
what's
in
the
virtual
environment
and
we
install
relevant
packages.
So
after
this
change,
what
would
be
possible?
We
can
still
people
can
still
use
the
bootstrap
command,
but
what
would
be
possible
is
they
can
install
something
like
instrumentations
all
and
then
forget
about
it,
then,
in
in
future
or
like
whatever
package
they
use?
G
They
don't
have
to
run
bootstrap
ever
again,
because
every
single
instrumentation
will
always
be
available
in
their
virtual
environment
and
it'll
just
get
activated
only
when
they
use
a
specific
library
and
it
since
instruments
are
very
small,
it
won't
have
any
like
it
won't
take
much
space
or
it
won't
pull
any
additional
dependencies.
So
it
should
be
relatively
free
to
have
just
every
single
instrumentation.
G
G
Yeah,
I
think,
if
you
do,
this
bootstrap
would
be
a
nice
to
have,
but
it
won't
be
required.
B
It's
not
a
huge
deal
yeah
now
that,
like
instrumentations,
are
so
lightweight
now
it's
just
like
extra
libraries.
I
guess
we
can
even
like
make
it
like
make
the
functionality
of
like
instrument,
auto
instrumentation,
install
all
to
be
configurable
too
right.
I
don't
even
think
we
need
bootstrap.
In
that
case,.
E
F
G
G
Like
I
said
in
general,
we
can,
like
all
instrumentations,
usually
have
very
common
functionality
like
they
mostly
use
rap
d
or
some
other
very
similar
package
or
whatever
other
common
functionality
they
use.
We
usually
take
it
out
in
the
uterus
package
like
the
returns.
Actually
I
I
think
this
shouldn't
be
a
problem,
but
yeah.
F
Yeah,
what
what
I
wonder
is
so
we
are
now
switching
from
installing
only
the
the
net,
the
instrumentations
for
the
libraries
that
are
present
in
the
virtual
environment
to
installing
them
all
right.
G
So
that
it
would
make
it
possible,
but
as
hotel
like
officially,
we
don't
have
to
do
that.
We
can
still
recommend
bootstrap
or
recommend
people
to
look
at
the
hotel
registry
and
install
what
they
want,
but
it
makes
it
possible
for
the
hotel
or
for
specific
vendor
distributions
to
do
one
thing
or
the
other,
so
people
can
still
recommend
using
bootstrap
or
have
an
install
all
meta
package.
B
B
G
Yeah
so
we'll
we'll
have
a
defensively,
import
and
then
check
for
versions,
so
everyone
had
suggested
something.
Could
you
scroll
up?
There's
we
don't
strictly
have
to
use
this.
We
need
to
investigate
if
it's
different,
but
it's
something
if
anyone's
familiar
with
one.
So
no
one
has
this
package
called
required
in
the
middle.
A
G
And
like
it
gets,
you
get
a
call
back
whenever
someone
inputs
a
specific
library.
So
if
someone
imports
requests
at
import
time,
you'll
get
a
call
back
and
then
you
can
patch
requests
and
the
person
will
check
version
and
stuff
right.
Next
version
of
request.
Yeah,
I
haven't
tried
it
out,
but
it's
something
worth
looking
into.
B
G
F
G
B
Hey
aaron,
could
you
can
you
kind
of
explain
this
comment
that
you
made
right
here?
I
didn't
really
read
the
thread.
C
Yeah
yeah,
so
basically
my
proposal
was
people
can
opt
into
the
dependency
checking
by
adding
an
extras
required
for
the
dependencies
of
that
instrumentation,
so
that
if
they
want
to
have
pip
complain
when
they
install
and
the
dependencies
aren't
all
met,
they
can
just
do
like.
In
that
comment,
there.
C
Oh
sorry,
sorry
yeah,
there's
there's
no
issue.
I
just
think
it
would
be
tricky
so
like
just
as
an
example.
If
you
had
like
you
were
instrumenting
some
library
where
the
first
two
parameters
are
strings
and
then
the
parameters
change
order
in
like
a
version
that
you're
not
expecting,
then
you
would
end
up
like
everything
would
work
code
wise,
but
then
the
span
attributes,
for
instance,
could
be
swapped,
so
you
could
end
up
putting
like
hostname
where
the
path
should
go
or
something
like
that
right.
B
G
Yeah
yeah
that's
a
bit
of
a
problem
with
autism
like
fractions
in
general
yeah,
but
but
I
think
that's
that's
the
problem
anyway.
Right
because.
G
G
So
so
I
think
this
this
recommendation
that
so
this
idea
is
to
so
aaron
was
sorry
I'll.
Try
I'll
speak
for
you,
and
so
I
think
aaron
was
trying
to
think
of
a
way
to
preserve
the
behavior
that
we
have
today,
where
let's
say,
floss,
instrumentation
flask,
also
it's
called
plus
library.
Just
so
just
so.
People
get
dependency
concepts.
G
So
if
someone
is
really
paranoid
and
they
about
breaking
their
system
by
by
updating
in
future-
and
they
can
use
this
strict
extras
and
this
would
install
the
specific
version
range
of
flask
and
so
if
in
future
they
install
flask,
2
pip
would
complain
very
loudly,
like
I
said
yeah,
so
it's
just
it's
just
a
way
of
providing
both
behaviors.
C
E
C
Oh
wait:
what's
if
you
hit
view
more,
oh,
I
left
a
comment
on
my
other
comment,
which
I
hadn't
seen.
Basically
in
the
the
comment
above
I
was
saying
like
for
that
other
issue.
You
can
use
this
python,
like
reflection,
basically
to
check
that
the
signature
is
compatible
with
what
you're
patching
which
would
solve
like
the
issue
that
oa
was
talking
about
where
even
in
minor
versions
or
patch
versions,
internals
can
change,
parameter
order.
There's
just
another
option
like
to
make
sure
that
the
patching
is
gonna
work.
C
Eh
yeah
yeah,
I
was
thinking
if
you
could
just
like
do
like
a
really
quick
equality
check
rather
than
checking
if
it's
compatible
exactly
it
would
be
pretty
simple.
Maybe.
E
B
Okay,
cool
any
other
comments
on
this
topic.
G
One
more
thing
somewhat
unrelated,
so
it's
it'll
be
nice
to
have
like
a
nightly
build
for
instrumentation,
so
it
can.
G
Detect
when
new
minor
weapons
can
can
possibly
break
instrumentation,
this
used
to
happen
very
commonly
with
some
single
effects
instrumentations,
especially
with
load
where
things
change
very
fast,
but
also
sometimes
you
fight
them.
So
you.
G
Yeah,
because
we
guys
the
internet
and
people
authors
can
maintainers
can
change
the
internals
without
changing
your
public
review
and
that
doesn't
make
break
anything
in
customers
apps.
But
it
does
go
great
from
time
to
time
right
right.
So
it
would
be
nice
to
have
some
like
a
nightly
build,
so
we
can
like
detect
it.
F
D
Yeah
I
mean
it
would
be
good
to
have,
I
guess
as
long
as
we
then
have
an
action
on.
You
know
how
how
to
go
about
fixing
incompatibility
issues
or
whatever
it
feels
like.
D
One
thing
that
I've
seen
happen
too
often
is
people
will
have
a
like
a
regular
build,
but
then,
when
the
failures
start
happening,
nobody
really
picks
up
the
fixes
or
whatever.
So
you
would
have
to
have
some
kind
of
an
action
there.
B
Yeah,
so
that
does
relate
to
the
whole,
like,
like
the
whole
maintainers
approvers
thing
that
we
kind
of
pushed
off
for
the
contrib
repo
as
well.
B
We
have
to
be
kind
of
defined
clearly
of
the
responsibilities
and
what
we
expect
from
people
who
contribute
to
the
repo
and
like
just
leave
so
yeah
and
also
like
the
some
of
the
tests
in
our
instrumentations,
are
not
as
robust.
B
So
even
if
we
have
a
nightly
build,
it
might
not
even
catch
anything.
To
be
honest,
so
well,
partly
because
we
haven't
been
monitoring
the
contrib
report
that
strictly
versus
the
core
repo,
so
yeah
there's
those
aspects
too.
B
Okay,
cool,
if
you
guys
have
any
other
comments
on
this,
just
feel
free
to
talk
about
it
in
the
discussion,
so
we
could
just
keep
moving
on
not
much
other
stuff
in
the
for
the
issues
like
it's
been
more
or
less
relatively
expected
and
quiet,
not
like
big
problems.
B
There
is
this
one
pr
that
away
opened
up
that
possibly
relates
to
that
other
pr
that
was
open
for
like
three
months
this
one!
So
oh
wait!
Is
this
like
a
like
a
a
replacement
for
this
or
is
is
no
one
working
on
the
other
old
one
or
what's
what's
going
on?
What's
the
status
of
this.
B
Okay,
cool
yeah.
I
don't
I
don't
mind,
it
seems
like
you
had
some
issues
with
the
whole
like
the
technologies,
he
was
using
anyways.
G
That
was
that
was
mostly
minor,
the
lru
cash
he
used,
but
that
was
okay,
I
mean,
but
the
main
issue
was
the
main
thing
for
me
was
that
that
he
was
fixing
this
in
a
convenience
method
and
not
not
not
in
the
internal
api.
So
it
would
only
fix
the
problem
for
people
who
would
who
try
to
get
a
tracer
from
it
from
the
convenience
method,
not
from
the
provider
so
like
all
the
instrumentations
wouldn't
would
still
not
work.
B
Okay,
cool
yeah,
once
you
mark
this
as
like
ready
to
review,
if
you
can
also
update
like
the
description
to
like,
explain
a
little
bit
about
what
you're
doing
for
the
people
who
don't
have
context
for
this
issue,.
B
Great
cool
any
comments
on
that.
B
G
So
there
was,
there
was
vr
created
today,
where
I
think
it's
worth.
People
take
a
look
at
it.
G
So
this
is
the
second
one.
The
current
default
current
context
right
yeah.
So
apparently
our
documentation
says
that
propagator.extract
method.
If
it
is
unable
to
extract
a
contacts
from
from
the
carrier,
then
it
would
return
the
global
currently
active
context,
but
it,
but
it
doesn't
do
that
in
all
cases,
so
this
pr
updates
it
to
make
sure
that
it
always
returns
the
global
active
context
whenever
it
cannot
successfully
extract
from
the
carrier.
G
I
think
that
that's
too
magical
it's
it
limits
some
use
cases
or
makes
them
hard
to
implement.
We
had
some
detail.
We
had
some
long
discussion
here.
So
if
you
guys
can
take
a
look
at
the
pr
and
the
discussion
and
we
would
like
to
know
what
everyone
thinks
about
it,
so
the
main
contention
I
hear
is
main
issue
I
have
is,
I
don't
think
we
should
be
returning
the
parent.
Sorry,
the
active
context
from
this.
G
It
feels
like
it's
too
much
hidden
magic,
going
on
so
extract,
extract,
passing
a
carrier
to
extract
and
expecting
expand
context
from.
If
you
look
at
the
api,
it
feels
like
it's
just
like
a
dc
realizes
like
json.,
lower
s
or
something
like
that,
and
if
getter
doesn't
have
a
span,
then
it
should
return
anywhere
span
or
none
or
something
it's
returning.
The
active
context,
kind
of
could
be
surprising
in
my
opinion,
would
like
to
hear
what
it
wants.
G
G
A
A
So,
in
which
case,
if
the
same
is
attached
to
the
global
context,
the
instrument
like
the
whole
proposition.
So
so
basically
he
doesn't
want
that
to
happen.
So
so
what
what
I
substitute
was
so,
if
the?
If,
if
we
cannot
extract
a
context,
span
countries
from
carriers,
we
will
just
written
in
value.
A
A
Current
this,
this
line
of
change,
it
doesn't
really
change
anything
because,
let's
say
if
this
doesn't,
this
is
not
added
to
the
so
there's
another
problem.
Even
if
we.
A
That
context
is
not
passed
to
this
one.
This
is
just
you
know,
calling
with
a
spam,
so
this
context
is
not
passed
down
so
that
that's
right.
A
B
E
B
Is
that
is
it?
That's
that's
for
the
overarching
effort
of
making
our
behavior
consistent
across
every
possible
outcome
right.
D
I
mean,
I
think,
the
I
think
the
the
problem.
I
think
the
bug
in
this
pr
is
at
that
propagator
that
context
variable
like
instead
of
being
instantiated
here
to
to
get
current.
It
should
just
be
passed
into
the
set
yeah
set
span
in
context
because,
right
now
it's
just
not
passed
through,
whereas
some
of
the
other
propagators
actually
do
do
this.
B
That
that
is
the
bug
for
this
pr.
But
what
is
the
bug
that
he's
trying
to
address
like?
What's
the
problem.
F
A
The
value
is
expected
to
be
a
constant
context,
but
it's
the
instrumentation
which
is
trying
to
you
know,
use
this.
This
context
for
application
phase.
A
A
B
B
B
Sorry,
oh
wait!
You
were
I
cut
you
off,
like
you
were
still
talking
about
this.
Like
did
you
want
reviewers?
Is
that
what
was
the
reason
or.
D
B
Yeah
yeah
true,
I
was
asleep
when
this
was
open.
Okay,
I
didn't
know
yeah
yeah
I'll,
take
a
look
too.
A
B
You
guys
love
adding
paragraphs
man,
jesus
christ,
okay,
anyways
I'll,
have
to
go
through
that
cool,
any
other
someone's
on
my
door.
Is
there
any
other
topics
anyone
wants
to
talk
about?