►
From YouTube: 2020-12-03 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
B
Hi
all
right,
let's
just
give
alex
a
couple
of
minutes.
B
How's
everyone's
thanksgiving,
just
assuming
everyone's
from
the
us,
but
it's
like
clearly
not
the
case,
but
you
know.
B
D
I
got
a
kikron
2
keyboard.
Oh
nice
really
happy
about
I'm
all
about
the
wireless,
so
I
was
really.
D
B
Cool
cool
all
right,
if
you
guys,
can
fill
out
the
attendees
list,
that'd
be
great
honestly.
We
don't
really
use
this
for
anything.
It's
more
like
we
keep
people
accountable.
You
know
it's
like
hey.
You
were
in
this
meeting.
You
should
know
about
this
stuff
right.
B
All
right,
so
we
got
a
lot
of
stuff
in
the
agenda
today.
So
let's
try
to
go
through
these
really
quickly.
So
I'll.
Let
alex
talk
about
these
when
he's
when
he
gets
here
so
him
and
I
went
through
like
triage
a
bunch
of
issues
last
week
and
this
whole.
You
know
deprecation
of
packages
thing.
So
we
tried
this
whole
yanking
of
the
packages
and
what
we
found
out
is
like
people
are
still
downloading
the
old
versions
and
everything.
B
So
what
we're
discussing
last
week
was-
and
I
think
aaron
had
some
issues
with
this,
like
I
think,
if,
if
any
time,
if
there
was
any
time
for
us
to
delete
the
packages
like
it
would
be
now-
and
we
were
talking
about
like
the
repercussions
of
doing
each
of
them
and
like
it
would
be,
we
would
have
to
be
a
supportability
issue
for
either
case
because
right
now
like,
if
we
don't
delete
them,
there
are
still
people
coming
to
us
and
still
using
the
old
package
or
new
people
coming
to
us.
B
That
don't
know
which
package
to
use
and
they're
still
being
like
which
package
will
install
I'm
not
getting
any
of
these
features
that
you
guys
promised
us
on
like
the
readme
and
stuff,
and
then
we
still
have
to
direct
them
to
the
new
package,
as
opposed
to
if
we
delete
them
like
we'll.
Just
have
angry
customers,
but
it's
like
a
small
amount
of
people
that
are
using
our
beta
products.
B
That
is
coming
to
us
and
be
like
what's
wrong
with
this.
What
package
do
I
use
instead,
like
our
new
customers
that
come
they'll
just
be
like?
Okay,
there's
only
one
package
to
use
so
me
personally,
like
I'm,
I'm
willing
to
take
that
you
know
take
that
risk,
especially
because
we're
still
in
beta,
but
you
know,
I'm
leaning
towards
that
option
so,
especially
because
of
the
the
whole
like
people
are
still
using
our
old
packages.
So
I
don't
know
about
what
you
guys
think.
What
do
you
guys?
B
A
Yeah,
I
just
worry
that
we'll
like
break
somebody's
stuff-
and
I
know
it's
beta,
so
they
shouldn't
be
depending
on
it.
But
I
don't
know.
E
B
Well,
that's
the
thing,
though,
it's
like
it,
people
aren't
reading
these
messages
right,
they're,
not
looking
at
these
logs
they're
still
downloading
these
packages,
like
that's
the
whole
point.
What
like
we
wanted
to
get
that
sample
for
like
yanking
these
packages
right
and
we
left
it
out
there
for
two
to
three
weeks
and
we
still
have
just
about
the
same
amount
of
downloads.
D
E
Are
there
are
the
changes
here
just
for
most
cases,
just
just
that
we
have
renamed
the
packages
or
are
there
deeper
changes?
Could
we
somehow
release
a
release
updates
that
act
as
aliases
for
the
new
package.
B
B
And
not
only
that,
I
also
wanted
to
bring
up
like
this
point
afterwards
in
which
would
I
even
have
this
what
the
hell.
Oh,
this
package
releasing
and
versioning
thing.
I
could
talk
about
this
a
little
bit
afterward
if
you
go
to
this
link
like
the
tc,
the
in
the
maintainers
community,
like
we're
talking
about
like
perhaps
even
splitting
up
like
the
api
and
sdk
packages
into
tracing
and
metrics.
B
So
that's
gonna
be
like
even
more.
You
know,
packages
that
we
got
to
maintain
and
like
what,
if
the
case
where
it's
like
one
of
them
depends
on
each
other.
Now
we
need
some
like
overarching
generic
open,
telemetry
package
right.
So
every
time
we
do
this
kind
of
like
naming
thing,
it's
like
just
adding
much
more
waste.
B
So
I
don't
know,
maybe
we
could
perhaps
try
the
the
log
thing
and
see
if
like
it
helps
but
other
than
that,
we
have
to
accept
that
we
have
to
take
on
this
technical
supportability
debt
in
the
future
of
always
pointing
people
to
the
right
place.
A
Yeah,
I
agree
with
that.
I
think
updating
the
readme
would
be
cover
like
the
new
users
who
might
accidentally
find
these
old
packages
but
yeah,
like
I
don't
know
you
just
put
your
if
I
put
myself
in
like
the
shoes
of
somebody
who's
just
like
okay,
there's
some
package
on
pie
pie
like
I
don't
assume
it's
just
gonna
be
deleted,
even
if
it's
not
getting
updated,
but
I
don't
know
I
guess
they
could
get
their
stuff
better.
I
don't
know.
B
Well,
yeah,
I
think
the
even
if
we
update
the
stuff
on
readme,
it's
like
the
average
user,
doesn't
look
at
the.
Are
you
talking
about
the
readme
on
pie,
pie
like
the
package
description
and
stuff
yeah
yeah?
I
don't
think
people
look
at
that
people
just
pip
install
something
right
and
it's
like
if
it
works.
It
works.
B
D
I
would
say
that
sometimes
I
do
read
it,
but
honestly,
I
would
say
that
right
now,
like
I'm
more
inclined
to
agree
with
leighton
because
like
it
is
in
beta-
and
I
think
if,
if
I
am
a
new
user
and
I'm
using
it
like
I'd
rather
like
somehow
be
like
smacked
across
the
head
and
told
that,
like
there's
a
new
version
of
this,
go
use
it
instead
of
spending
all
this
time
on
this
package
that
isn't
going
to
get
supported.
A
Yeah
I
get
that
that
if
we
have
like
that's
what
I'm
saying
like,
we
add
it
to
the
logs
at
least
they'll
see
that
if
they
haven't
pinned
the
package
at
like
the
exact
version,
but
I'm
just
like,
like
we've
added
a
lot
of
stuff.
Since
I
don't
know
how
old
are
these
packages
now
like
before
yeah,
but
like
most
users,
they're,
probably
literally
just
like
collecting
a
few
traces
and
the
api
for
that
really
hasn't
changed
that
much
in
four
months,
so
they
probably
felt
no
need
to
upgrade
to
get
like
anything
any
features.
B
And
we
have
no
like
guarantee
to
the
customers
right
now
that
we
wouldn't
break
their
code
like
updating
from
one
version
to
another
version,
also
breaks
their
code
right,
so
not
all
the
time,
not
not
as
serious
as
like
a
package
being
missing,
but
still
like.
We
have
no
guarantee
that
your
your
tracer
provider
is
going
to
be
a
tracer
provider
tomorrow,
right
so.
E
What
do
you
mean
the
the
issue
with
that?
Is
that,
like
that's
an
explicit
decision,
someone
takes
to
upgrade
a
major
version
and
break
stuff,
but
if
someone
has
some
app
in
like
maintenance
mode
somewhere
running
for
weeks
or
months,
and
suddenly
it
just
breaks
because
we
deleted
the
package,
that
would
be
a
really
bad
experience.
I
think
for
actively
maintained
apps.
I
don't
think
it's
that
big
of
a
deal,
but
sometimes
people
build
something
and
just
deploy
it
and
people
keep
using
it
without
adding
features
every
day
and
it's
much
bigger
pain.
B
E
B
B
Anyways,
I
I
guess
we
don't
have
time
to
keep
talking
about
this
as
usual,
but
we
really
need
to
come
up
with
a
decision
for
this
because,
right
now,
it's
like
in
some
half-assed
interim
state,
so,
okay,
so
anyways
yeah.
I
just
want
to
bring
up
this.
You
know
this
document
link
the
community
right
now
is
talking
about
like
what
they
will
be
doing
in
terms
of
versioning
and
how
we're
releasing
like
tracing
and
metrics
and
whether
or
not
we're
doing
it
separately.
B
If
you
go
to
the
bottom
like
it
shows
you
what
each
of
the
languages
are
doing
and
how
the
package
structure
is
laid
out,
I
don't
think
this
is
final,
yet
everything
is
in
discussion
right
now.
So
what
what
the
approach
that
we're
going
to
be
doing
is
we're
kind
of
just
we're
kind
of
just
like
waiting
to
see
what
the
outcome
of
this
is,
and
you
know
we
would
have
to
adhere
to
that.
So
this
is
just
a
few
guys
are
curious,
yeah.
F
Yeah,
that's
that's
fine.
I
think
the
the
only
thing
I
wanted
to
talk
about
on
the
very
first
topic
is
that
there
is
a
project
if
folks
are
wondering,
what's
what's
left,
to
do
for
rc1
there's
this
github
project,
which
looks
better
on
a
higher
resolution
screen
where
you
don't
have
cards
that
take
like
a
quarter
of
the
screen
estate
but
anyway,
so
there's
a
there's,
a
few
items
in
here.
If
you,
if
you're
looking
for
something
to
pick
up,
you
know
any
anything
in
here
is
always
a
good
option.
F
It's
all
pretty.
I
think
it's
all
pretty
small
stuff,
some
of
these
issues
we're
going
to
talk
about
in
more
detail.
So
that's
that's
cool.
If
you
want
to
go
back
to
the
doc,
we
can
probably
move
on
to
the
next
topic.
Actually
I'll
I'll
talk
about
this
last
I
did.
I
did
want
to
talk
about
the
change
logs
for
a
quick
second,
so
we're.
Currently
we
currently
have
these
like
change
logs
that
are
per
package,
but
we're
not
we're
not
actually
making
use
of
these
change
logs
anywhere.
F
F
F
F
F
E
Think
about
this
I
think,
as
a
user
single
change
log
would
be
great
to
have.
I
guess
my
only
concern
is
if
at
some
point,
we'll
start
like
having
patch
releases.
It
is
for
for
small
packages
like
one-off
packages
and
then
how
would
it
work?
There
would
be
update
the
main
change
log
for
like
a
single
batch
release
for
one
specific
package
or.
F
Yeah,
that's
that's
kind
of
what
I
would
imagine
like.
I
would
imagine
all
the
changes
to
go
into
the
same
change
log,
even
even
for
things
that
aren't
like
like
major
releases
or
whatever
like.
I
would
expect
it
all
to
be
like
searchable
and
I'd
be
able
to
find
it
in
one
place.
B
Would
that
just
be
merging
the
change
logs
for
the
instrumentations
and
stuff.
F
B
Sorry,
like
would
that
be
two
change
logs
or
one.
H
I
am
for
this,
this
makes
sense,
but
are.
C
Yeah
I
mean
if,
if
we
decide
to
update
the
versions
of
the
packages
individually
every
time
when
there
is
a
change
in
the
packaging,
but
everywhere
right
in
that
case,
we
will
need
change
logs
in
every
package.
E
C
Yeah,
I
don't
know
if,
if
pipey
uses
the
changelog
file
for
for
something.
F
F
F
D
D
B
Like
supposedly
like
the
trace,
freeze
was
done
like
a
couple
days
ago
like
before
thanksgiving,
I
think,
and
that
was
supposed
to
be
rc
one,
but
there's
no
like
announcement
for
like
okay.
All
of
these
languages
should
be
rc1
right
now.
So
I.
B
Up
to
our
discretion,
the
problem
is
like.
We
still
have
outstanding
issues
for
se1
and,
like
we
can't.
B
C
B
F
Cool
all
right,
the
other
topic
is
a
little
bit
meteor.
I
only
have
seven
minutes
because
I
have
to
drop
off
at
9
30,
but
I
can
I
can
kind
of
start,
and
we
can
talk
a
little
bit
about
this.
I
know
nathan
and
diego
and
I
have
been
having
or
had
a
pretty
lengthy
conversation
last
week,
but
everybody
else
was
off
so
so
this
this
is
specifically
around.
F
Currently,
the
open,
telemetry
instrumentation
package
has
a
requirement
on
has
a
requirement
on
the
sdk
because
of
some
of
the
components
that
get
initialized
inside
this
initialized
components
code.
I
think
we
had
a
few
issues
that
we
had
talked
about
finding
ways
to
splitting
that
out
the
latest
greatest,
I
don't
know
if
you
have
the
pr
that
I'm
going
to
be
referencing
in
the
doc
or
not.
It's
the
one.
F
That's
in
draft
that
I
created
yeah
that
one
1420,
so
the
the
latest
greatest
current
kind
of
proposal
for
moving
this
forward
is
to
move
the
initialized
components
out
of
the
instrumentation
package
and
into
the
sdk
package
and
then
use
an
entry
point
that
we
would
be
calling
something
like
open,
telemetry,
configurator
or
open
telemetry
configure
or
something
that
the
sdk
could
then
register,
and
then
the
instrumentation
would
just
load
that
entry
point
and
do
the
initialization
of
components.
F
How
do
the
do
people
feel
okay
about
this?
Do
they
have
any
concerns?
There's
there's
this
kind
of
a
separate
topic
that
I
haven't
included
here
around
adding
one
more
and
one
more
entry
point
but
anyways.
I
just
wanted
to
bring
this
up.
First.
E
F
Yeah
yeah,
and
actually
that
was
the
other
thing
that
I
wanted
to
talk
about
around
adding
another
entry
point.
So
at
least
at
lightsaber-
and
I
know
there's
few
other
vendors
that
are
interested
in
this.
F
We
we
want
to
be
able
to
do
like
kind
of
some
configuration
ahead
of
time
for
a
user
so
that
they
don't
have
to
think
about
things
like
the
destination
of
where
their
otlp
exporter
traffic
should
go,
because
we
just
know
what
the
default
should
be,
and
I
was
I
was
going
to
propose
that
we
add
another
entry
point
called
like
distro
configuration
that
would
happen
before
the
initialization
of
components
so
that
any
any
kind
of
distro,
whether
it's
like
aws
or
lightsab,
or
you
know
other
folks.
F
They
would
be
able
to
include,
like
a
tiny
amount
of
kind
of
configuration
of
existing
components
ahead
of
the
call
to
initializing
those
components.
So
anyways,
that's
kind
of
the
other.
The
other
side
of
this
that
I
want
to
talk
about.
A
D
I
remember
I
really
like
this
solution
too.
I
think
the
only
thing
I
pointed
out
was
that,
like
just
the
way
it
sets
it
up
right
now,
if
you
have
multiple
of
the
same
thing,
it
it'll
try
to
initialize
multiple
tracer
providers
and
I
think,
alex
you
added
a
warning
there.
Now
that
checks
like
by
the
way
this
will
create
another.
D
F
Yeah,
I
you
know,
I
kind
of
I
kind
of
feel
like
we
could.
We
could
do
something
like
say
hey
if
you're,
if
you
have
more
than
one
like
open,
telemetry,
configure
entry
point,
we're
only
going
to
load
the
first
one
as
a
warning
or
something
just
just
as
a
hard
kind
of
limit.
Otherwise
we
end
up
in
like
kind
of
unknown
cases,
because
anybody
can
register
these
right.
I
think
that's
fair.
I
B
B
B
Sorry,
can
you
repeat
the
question
yeah
like
how
hot
like,
if
I
were
to
create
like
a
light
step
or
aws
specific
distro?
How
how
would
the
sdk
read
that.
F
Yeah,
so
you
would
just
set
up
the
inside
your
so
inside
your
setup.cfg
file.
You
would
have
an
entry
point
that
you
register
so
currently
the
the
lightsub
distro
that
we
have
registers
an
entry
point
for
an
instrumenter
which
we
currently
already
support
in
the
instrumentation
package.
But
so
this
would
just
be
like
to
like
an
additional
entry
point
that
we
would
call
something
else
like
the
stroke
configuration
or
something
like
that.
A
F
Yeah,
I
think
think
it
kind
of
depends
on
what
the
implications
are
like
if
you're,
if
you're
talking
about
distribution
like
this,
the
distro
configuration
for
example
and
all
you're
doing
is,
like
you
know,
setting
up
your
preferred
configuration
for
your
exporter
or
something
like
that.
Then
there
wouldn't
be
any
harm
in
running
multiple,
something
like
the
sdk
configuration
becomes
a
little
bit
trickier
because
we
are
dealing.
F
Provider
and
like
the
metric,
the
meter
provider,
which
we
can
only
instantiate
once
but
yeah,.
A
Yeah,
I'm
just
wondering
because,
like
even
if
it
wasn't
for
a
district
use
like
if
a
company,
for
instance
had
they
had
like
extensive
usable
telemetry,
and
they
just
wanted
to
have
a
package
that
did
the
initialization
they
could
register
their
own,
but
then
maybe
they're,
also
using
auto,
auto
instrumentation
or
something.
You
know
right.
A
B
Right,
hey
so
so
one
thing
I
kind
of
want
to
bring
up
alex
before
you
leave
it's
like
now
that
we're
like
adding
stuff
to
the
sdk
package,
we're
kind
of
going
to
the
area
where
it's
like.
B
Is
this
behavior
expected
across
all
languages?
You
know
like
I
was
fine
with
it
being
an
auto
instrumentation
right
now,
because
that,
like
I
think
I
said
this
before
it's
like
a
kind
of
a
feature
or
plug-in,
but
now
it's
like
because
we're
having
to
do
this
and
like
all
this
functionality
is
cool
and
everything
but
like
if
we
don't
have
the
same
functionality
across
all
languages.
It's
kind
of
like
not
as
robust
and
useful
anymore,
especially
if
like
people
want
to
use,
distributed
tracing
across
different
frameworks
right
right,.
F
And
even
if
you're
doing
something
like,
even
if
we
did
move
like
the
initialized
components,
for
example
inside
the
sdk
now
the
sdk
has
like
a
dependency
to
have
the
otlp
exporter
installed
right
right,
exactly
also,
if
it's.
If
we.
F
Maybe
maybe
you
all
can
continue
this
discussion.
Okay,
that
sounds
good
thanks,
alex.
D
It
can
be
nice
to
have
a
separate
meeting
about
it.
Yeah
I
think
that'd
be
a
good
idea
like
on
auto
instrumentation,
so
yeah.
I
don't.
D
B
Yeah,
I
could
take
a
look
into
that.
Maybe
we
want
to
have
a
internal
discussion
first
to
see
what
our
game
plan
is
and
then
we
can
move
it
to
the
rest
of
the
and
also
the
dot
net
sake
is
pretty
much
microsoft
people,
so
I
can
just.
C
B
Kind
of
abuse
that
yeah
but
yeah
like.
B
It
away
nathaniel
like
great
work
on
this
auto
instrumentation
stuff.
It's
gonna
be
really
useful
for
everyone.
It's
just
that
like
when
we
start
going
into.
B
Like
the
you
know,
sdk
related
stuff
yeah,
like
the
generic
generic
way
that
I
kind
of
do
things
is
like
you
know
I
kind
of
prototype
them
in
python
and
then
I
bring
them
up
to
the
specs
and
see
if
it's
like,
because,
like
oh
hey,
look
it's
working
in
python
now,
it's
like
you
have
a
better
story
to
tell
so
we
might
have
to
push
this
up
to
specs,
so
we'll
see
cool
thanks.
Yeah
no
worries.
B
G
D
This
is
my
latest
and
greatest
project.
I've
been
researching
so
this
week.
My
task
is
to
research,
how
we
can
run
performance
tests
and
check
and
validate
how
fast
things
are
going,
and
there
is
an
existing,
very
old
issue,
but
you're
scared
to
add
performances
using
this
library.
Specifically
so
I
went
through
and
I
actually
I
saw
how
java
did
it
with
jmh
and
they
follow
some
specifications.
D
I
added
the
link
in
the
readme
description,
but
there
are
specifications
on
how
to
performance
benchmark.
That's
the
very
first
one
underneath
the
issue
number
and
they
they
have.
It
clearly
outlined
like
if
you
start
a
span,
the
span
should
have
this
resource
and
should
have
this
attribute
and
should
start
and
end
immediately
with
one
event
things
like
that.
D
So
it's
it's
not
a
very
complicated
pr,
only
88
lines,
and
so
does
it
link
to
itself
well,
okay,
I
will
see
it
yeah,
just
yeah
update
it
links
links
to
itself,
but
I
guess
so.
The
things
I
want
to
highlight
is
that,
right
now,
it's
very
short
code.
So
I
appreciate
like
reviewers
to
tell
me
like
what
they
think
about
it.
Aaron
already
posted
like
a
comment.
That's
it's
a
very
comment
that
right
now,
the
way
I
have
it
set
up
is
set
up
as
a
separate
ci
workflow.
D
D
Just
show
like
how
performances
got
improved
or
maybe
regressed
and
yeah-
that's
pretty
much
it
and
my
other
question
was:
if
anyone
knows
a
good
memory
profiler
for
resources
like
cpu
io
and
things
like
that,
because
this
does
not
do
that.
It
just
benchmarks
them
unit
tests.
There's
some
issues
on
the
actual
pi
test
benchmark
framework
to
add
that,
but
we
could
investigate
what
they
did
there
and
some
hacks
that
people
did
but
yeah.
That's
it
as
if
everyone's
excited
about
this,
I
hope
so
because
I
am
too.
A
Yeah,
it's
pretty
lit
yeah.
This
is
cool.
I
was
also
planning
to
look
into
this
a
bit
so
be
cool
to
work
with
you
on
this,
and
maybe
I
would.
A
It
yeah
yeah.
I
was
thinking
so
one
of
the
things
that
we
wanted
like
if
we
want
to
recommend
this
to
our
customers
for
google
cloud
like
one
of
their
first
performance
right.
So
we
were,
we
were
thinking
like
the
best
way
to
do
this
across
optometry
would
be
to
have
it
really
like
signal
really
well,
maybe
even
like
a
comment
kind
of
like
what
you
get
for
codekov
in
the
pr
or
something
that
people
know
like
they're,
really
focused
on
performance,
because
I
mean
I'm
guessing.
This
detects
regressions
now
right.
D
It
doesn't
detect
regressions
automatically,
but
you
can
do
it
manually.
If
we
then
add
code
to
publish
it
like
to
the
folder
on
release,
then
we
could
like
manually,
run
like
pinch
char
pinch,
pi
test
benchmark,
compare
with
the
previous
file
and
it
would
detect
that.
But
it's
not
automatically
set
up
yet.
A
D
Yeah,
but
you
definitely
can
compare
it,
I
I
can
link
to
it
but
yeah
you
can.
A
Yeah
yeah.
Basically
it
would
be
great
if
this
was
like
blocking
essentially
because
if
somebody
you
know,
destroys
performance
by
accident,
it's
like
really
valuable
to
have
this.
D
A
Yeah,
I
was
also
thinking
we
need
like
more
load
tests.
These
are
like
micro
benchmarks,
right,
yep
yeah.
We
got.
A
D
I
think
ashford
and
shonik
were
on
the
call
and
they've
been
working
with
leighton
to
write
a
prometheus
right
exporter.
I
think
they're
thinking
about
adding
load
tests
too.
So
it's
kind
of
at
least
parallelized
that
work.
D
B
Hey
so
I'm
not
too
familiar
with
these
terms,
what
does
micro
benching
mean.
D
I
found
all
of
these
out
in
the
last
24
hours,
but
yeah
micro.
Benchmarking
is
like
very
specific
to
like
a
function
like
a
very
like
a
line
of
code
to
like
test
or
sorry,
not
a
line
like
a
function
of
code,
and
you
just
test
that
function
and
you
like
record
how
long
it
took
like
in
in
seconds
right.
But
I
think
what
aaron's
referring
to
correct
me.
D
If
I
run
low
test,
is
like
you,
you
run
it
either
like
like
multiple
times
over
and
over
and
like
you
get
and
calculate
throughput,
or
you
calculate
like
how
much
it
it
was
good
at
doing
what
it
does
over
like
12
hours
of
time
and
like
soak
it
really
like.
In
that
sense,
I
think
I
updated
the
link
now,
if
you
refresh
and
then
clicked
it,
so
you
could
see
that
that
spec,
it
defines
a
couple
of
things
that
you
need
to
do,
and
I
just
did
the
first
part.
D
B
So
I
was
wondering
how
like
how
does
this
like
solve
this
regression
thing
like
we
have
to
create
our
own
benchmarking
tests
right
that
are
separate
from
our
unit
tests.
D
Yeah
and
this
pr
adds
them,
it
adds
benchmarking
tests
for
the
start
as
current
span
and
start
expand
functions
of
the
specifically
open,
telemetry,
sdk
right
so
yeah
in
java.
They
actually
have
tests
for,
like
the
b3
propagator
the
year
propagator,
and
I
added
those-
I
just
didn't-
add
them
to
this
pr,
just
because
I
didn't
want
to
make
it
any
longer
than
it
needed
to
be
so
I'll,
follow
up
and
commit
those
ones
to
show
you
guys
what
I'm
talking
about
all.
B
Right
makes
sense,
nice
cool.
Sorry,
oh
sorry,
how
how
updated
is
this
like
is?
Are
people
like
actively
contributing
to
this?
I
think
it's.
A
B
I
haven't
seen
this
cool
nice.
It's
good
that
you're
looking
at
keeping
active
with
this
specs.
Sorry
aaron
were
you
gonna,
say
something.
A
B
A
I
did
also
want
to
say,
like
I
think,
I'm
not
I'm
not
sure
how
the
billing
set
up
with
github
with
open
telemetry,
but
I
think
there
is
like
a
quota
for
the
test
runs
right.
A
B
D
Yeah,
I
guess
the
other
question,
I
don't
know
if
anyone
knows
quickly
on
top
something
I
can
investigate
for
profiling
memory
in
python.
I
saw
that
it's
tricky.
Has
anyone
done
that
before.
D
D
Good
there's
a
couple
of
ideas,
but
depending
how
we
like
this
one,
I
can
investigate
what
they
have
answers
for
in
pi
tests
for
nice
benchmark.
B
A
A
B
A
Thing
right,
yeah,
yeah
and
I
think
yeah
this
one
had
six
eyes,
so
I
figured
six
eyes
yeah
so
anyway.
I
just
I
just
responded
this
morning,
but
I
I
think
that
we
could
do
better
with
like
making
it
easy
for
users
like
just
because
people
seem
to
be
more
confused
and
in
case
anybody
doesn't
know
the
problem.
A
It's
essentially
like,
if
you
have
the
open,
telemetry
api
imported
and
you
call
get
tracer
or
get
tracer
provider
from
a
module
before
the
global
one
is
set,
it
will
initialize
the
default
one
and
then,
if
you
accidentally,
if
you
call
set
tracer
provider
after
that,
it
will
throw
an
error
because
you're
like
overriding
the
one,
that's
already
been
set,
which
is
probably
an
accident.
That's
the
whole
reason
we
had
that.
So.
B
Yeah
and
also
the
rest
of
your
workflow
would
be
a
no
up
yeah
exactly
because
it's
the
default
tracer
provider
yeah.
I
don't
think
it's.
B
Yeah
but
the
issue,
the
issue
is
like
some:
some
people
like
have
the
get
tracer
provider
step
somewhere
previously
in
the
workflow
that
they
don't
have
control
of
yeah.
That's.
D
B
Exactly
and
then
in
your
code
and
now
your
application
code,
you
you
try
to
correctly
set
the
tracer
provider,
but
it
has
already
been
set
so
now
you're,
now
you're
stuck
working
with
the
default
tracer
provider
forever.
So
no,
I
agree
this.
D
A
Yeah,
so
one
thing
that
this
this
issue
brought
up:
you
scroll
up
a
little
bit
and
you
click
on
that
link
at
the
bottom
of
yeah
there.
So
there's
an
entry
point
for
the
default
tracer
provider
and
it's
set
by
the
sdk
to
like
the
actual
one
and
the
api
sets
it
to
the
no
op
one.
It's
called
like
default.
Sorry,
it's
called
default,
open
symmetry
tracer
provider
or
something
like
that.
A
But
you
see
online
45,
it's
it's
doing
next,
so
it's
just
taking
the
first
one
right,
it's
like
if
the
sdk
is
installed,
it's
still
going
to
go
to
the
default
one.
So
I
feel
like
I
don't
know
if
we
want
to
do
it
automatically
and
like
automatically
default
to
the
actual
one,
because
then
people
still
need
to
set
up
like
the
export
pipeline,
but
like
the
way.
This
is
right
now
is
kind
of
like
we're
not
even.
A
Entry
point,
as
always:
getting
the
default
no
op,
one
right.
A
B
Yeah,
that
is
a
good
point.
Does
anybody
have
any?
I
haven't
taken
a
look
at
this
yet
so
I
don't
have
much
context
or
opinion
right
now,
but
I'll
take
a
look
at
after
does
anybody
else
have
any
thoughts
about
this
issue
and
how
we
might
circumvent
it.
D
No
more
thoughts,
but
maybe
more
questions
is
even
even
if
we
do
set
it
to
the
sdk
one
as
opposed
to
the
api
one.
Then
I
mean
I
don't
think
we
can
guess
what
they're
trying
to
do
right
like
even
so.
You
still
have
to
set
like
if
you
want
to
use
a
console
exporter
versus
otp
exporter
and
in
like
our
case,
like
you,
have
to
say
id
generator
like
I
don't.
D
A
Yeah,
I
think
that's
the
intention,
but
I
guess
they
would
need
like
like
the
issue.
Is
we
don't
know
the
order
right
so
yeah.
A
D
So
if
we
have
like
sorry,
I
don't
know
right
now,
the
instrumenter
will
go
and
we'll
set
the
trace
provider
like
blanket
right,
but
it's
not
very
intuitive
that
it
does
that.
What
if
you
had
to
call
like
open,
telemetry
dot,
start
tracing
just
like
a
blanket
thing,
and
if
you
have
it
called
that,
then,
if
you
try
to
get
a
tracer
provider,
it's
like
wait.
A
D
D
D
B
A
B
A
Yeah,
I
did
also
want
to
say,
like
we
don't
have
a
way
to
say
if
you
didn't
want
to
use
like
the
sdk
provider,
but
with
this
entry
point
thing:
if
it
defaulted
to
it
to
like
a
the
actual
sdk
provider,
and
then
they
you
can
still
set
like
the
exporter
after
the
fact
in
the
span
processor.
After
the
fact,
you'll
just
lose
everything
until
you
set
a
spam
processor
right.
B
Yeah,
this
is
even
introducing
the
like
the
auto
instrumentation
stuff.
This
is
just
like
purely
manual
instrumentation
and
like
then,
we
have
to
define
like
okay
what
users,
what
do
users
have
to
do
with
the
auto
instrument
right
so.
A
Yeah
so,
like
I
do
think
an
entry
point
could
solve
it
like
if
you
had
like
a
an
init
entry
point
or
something
that
that
ran
sort
of
like
the
distro
we
were
talking
about.
But
the
problem
is
like
people,
don't
define
entry
points,
usually
for
their
own
code,
if
they're
not
gonna,
upload
it
to
pi
pi,
because
it
has
to
be
in
like
the
setup,
the
setup.cfg
or
whatever
right.
B
Hey
the
the
whole
limitation
of
like
tracer
providers
not
being
able
to
be
set
again.
Is
that
a
specs
thing?
I
totally
forgot.
A
Yeah,
so
so
it's
like,
if
all
of
your
code
ran
before
you
set
the
provider
and
then
you
overrode
the
default
provider
that
was
set,
then
all
those
like
pieces
of
code
that
ran
before
wouldn't
collect
any
telemetry,
even
though
you
actually
have
like
an
export
pipeline
and
everything
set
up.
So
this
way
at
least
like
it's
all
or
nothing
right.
A
B
Like
yeah
like,
if
we
like,
if
this
wasn't
part
of
the
specs
like
you,
cannot
set
multiple
providers,
it's
just
a
usability
thing.
It's
like,
instead
of
trying
to
work
around
this,
maybe
we
could
just
like
force
people
to
do
some
certain
things.
D
I
agree
we
have
to
force
him
to
do
it
somehow
like.
I
have
no
idea
how
he
would
do
that,
but
I
think,
like
like
aaron's
example,
is
good
and
the
other
example
I
would
think
of
is
like
say,
you're
trying
to
instrument
flask.
If
you
instrument
flask
and
then
set
the
tracer
provider,
then
it
will
go.
It'll
find
the
default
one
and
it
will
use
that
one.
But
then
you
set
it
to
the
global
one,
and
now
your
flash
one
is
still
using
the
old
default
one
right,
and
so
that's
the
big
problem.
G
A
Yeah,
we
could
just
change
that
warning
to
raise
an
exception,
and
then
it
would
fail
if,
if
like,
if
you
try
to
reset
the
providers
that
it's
either
like
default
or
it
fails
right
like
if
they
accidentally
have
the
import
order
wrong,
it
will
just
crash
their
app.
B
B
Pipeline
or
whatever,
right
and
then
like
in
a
previous,
also
traced,
like
you,
know,
section
like
they
already
set,
or
they
already
get
the
tracer
provider
and
they
they
can't
change
that
part
or
anything,
and
they
try
to
set
the
tracer
provider
in
their
application,
and
currently
it's
like
it
doesn't
crash
it
just
sets
it.
It
just
gives
us
a
warning
and
it
still
uses
the
default
trace
provider
but
like
if
we
make
it
crash
now,
it's
like.
Not
only
does
it
not
work,
it
also
crashes
their
application.
B
C
E
E
Right
so
the
order
of
execution
doesn't
matter
and,
like
you
can
install
instrument
all
the
package
first
and
then
set
the
provider,
and
you
just
have
to
know
that
until
you
set
the
provider,
we
don't
record
any
spend.
B
Yeah,
I
think
that's
a
safe
limitation
that
we
could
put
on
the
customer
because,
like
for
metrics
too
right
like
if
you
create
metrics
after
you
start
the
pipeline,
like
it,
won't
collect
those
metrics
right.
There
is
some
order
that
we
got
to
kind
of
force
to
do
things
so.
A
Yeah,
I
think
the
other
problem
with
the
proxy
approach
is
like.
I
mean
correct
me
if
I'm
wrong,
but
if
you
create
the
provider,
then
it
creates
the
tracer,
and
then
that
creates
spans
and
like
events
and
all
that
stuff
so
like
those
are
all
going
to
have
to
go
back
up
the
the
chain
right
like
because
it
gives
you
no
op
spins
right
and
they
don't
get
recorded
anywhere.
Is
that
right.
E
No
not
reading.
I
just.
F
E
Just
assumed
that
it
was
like
for
for
me,
it
was
a
safe.
It's
like
find
a
drop
yeah
find
find
a
drop
until
you
tell
us
what
to
do
with
them.
D
D
B
D
B
Yeah
all
right,
it
seems
like
this
is
a
bigger
issue
than
we
can
just.
I
actually
set
up
another
meeting
just
to
talk
about
like
the
big
issues
we
talked
about
today,
specifically
this
and
this
whole
removing
the
sdk
from
instrumentation
package.
So.
B
Just
just
look
at
getter
and
stuff
okay,
so
we
originally
had
a
bunch
of
like
prs
and
and
issues.
B
We
only
have
like
two
minutes
left,
but
the
generic
thing
is:
please
review
the
stuff
that
you
know
you
either
left
open
questions
to
or
like
you
requested
changes
or,
if
you're
just
assigned
to
them,
because
there
are
some
pr's
that
have
been
opened
for
a
long
time
and
we
really
want
to
get
them
in,
especially
the
rc1
ones.
So
yeah.