►
From YouTube: 2021-06-24 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
Pretty
good
excellent,
I
see
that
you're
a
new
pr
for
my
processor's
implementation.
I
I
have
been.
I
just
was
reading
your
pr
few
comments,
but
I
still
have
to
review
the
rest
of
it.
A
A
B
D
D
A
All
right,
well,
let
me
know:
let's:
let's
wait
for
the
alex
religion
to
join.
A
Okay,
all
right,
I
guess
we
can
start
now
welcome
everybody,
as
always.
Please
add
yourselves
to
the
yet
in
this
list,
just
a
heads
up,
the
format
of
this
document
has
changed.
A
little
bit.
E
A
We
go.
Thank
you.
Thank
you
for
letting
me
know.
Okay,
we
have
our
way
and
yes,
please
add
yourselves
to
the
atom
this
list.
So
today's
topics,
I
guess
we
can
start
with
mathematics
topic.
How
should
we
handle
version
bumps
four
packages?
We
have
instrumentation,
four,
all
right.
Nathaniel.
Do
you
wanna,
explain
your
topic
here.
Please.
D
Yeah
so
this
happened
to
me,
I
was
trying
to
auto
instrument
a
flask
cap
and
I
was
very
confused.
It
wasn't
working,
and
so
I
went
to
I
started
debugging
everything
and
I
realized
that
sorry.
The
reason
why
that
happened
was
because
our
instrumentation
package
that
we
have
in
contrib
says
that
it
only
supports
flask
version
one,
but
if
you
force
it
to
say
that
it
thinks
it
instruments,
flashback
version
two,
it
works.
So
it's
just
a
matter
of
telling
the
instrumentation
package
that
it
works
for
both
version
one
and
version
two.
D
I
put
a
pr
there
in
five
four
five
and
got
some
good
comments
from
both
alex
and
striketh
that
we
should
add
tests.
But
the
more
important
thing
was:
how
are
we
gonna
handle
this?
You
know
if
we
got
lucky
this
time.
Flask
got
bumped
to
version
two
and
it
didn't
break
our
instrumentation
package,
but
what
if,
in
version
three,
it
does
break
it.
So
I
mentioned
how
java
does
it
in
their
repo?
D
What
they
do
is
they
actually
just
take
advantage
that
it
doesn't
break
and
as
soon
as
it
does
break
they
release?
Like
version
two
of
flask
instrumentation
or
version
three
of
last
instrumentation,
it
works
well
for
them
and
the
tests.
Then
you
know
all
stay
in
the
same
packages,
but
it
warrants
a
discussion
with
you
guys.
What
do
you
guys
think
and
hey
leighton
hi
to
you
too?
A
Yeah
yeah,
I
look
good.
E
All
right,
I'm
curious,
so
you
mentioned
that
they
release
a
new
version
once
it
it
breaks,
or
do
they
release
a
new
version
for
like
to
associate
with
a
particular
version.
So,
for
example
like
if
were
releasing
support
for
flask
2,
we
would
create
a
flask
to
instrumentation
package
or,
like
our
diversion
or
diversion
coupled
in
this
case,.
D
I
didn't
look
into
that
deeply,
but
I
actually
think
that
they
might
be
coupled
because
if
you
look
again
at
the
java
packages,
they
skipped
over,
like
version
three,
for
example,
for
apache
http
like
they
have
instrumentation
for
apache
http
two.
They
don't
have
one
over
three
and
they
have
one
four
and
five.
So
I
don't
know
if
that's
because
it's
coupled
to
the
packages-
or
maybe
they
just
re-release
the
package
with
the
same
code
for
the
next
version
and
maybe
separate
the
tests
out
that
way,
but
yeah,
that's
the
only
thing
that
I
noticed.
A
Well,
I'm
not
sure
that
we
should
couple
the
versions
of
instrumentation
library,
because
the
meaning
of
our
version
numbers
is
to
indicate
if
our
api
is
has
now
a
breaking
change
right
because
we're
following
semantic
versioning.
A
D
Yeah,
that
sounds
right
because
the
way
our
auto
instrumentation
works
right
now
is
the
same.
How
javas
works?
We
look
at
your
current
system
and
we
see
everything
that
you
have
installed
and
based
on
that,
we
compare
that
to
our
list
of
instrumentation
packages.
We
have
so
if
you
have
an
app
and
you
have
flask
2
installed,
then
right
now
I
look
through
the
list
and
it
doesn't
match
anything.
But
if
we
release
instrumentation
flask
v2,
then
we
would
say:
oh
it
does
match
and
we
would
download
that
one
at
1.0.
F
The
flip
side
would
be
to
put
everything
into
one
package
except
have
a
bunch
of
like
logic,
branches
in
which
we
actually
have
to
check
the
flask
version
yeah,
if
there's
any
like
breaking
changes
for
that,
that's
the
that's
the
alternative
to
nathaniel's
suggestion.
D
F
So
if
we
take
a
look
at
the
pros
and
cons
for
this,
having
separate
packages
obviously
makes
it
easier
for
us
in
terms
of
like
the
logic,
it
adds
overhead
for
the
build
a
little
bit
for
the
release.
The
main
the
main
issues
would
be
that,
like
like,
we
would
have
to
maintain
consistency
for
features
across
multiple
package
versions.
Right,
oh
sorry,
multiple
packages
for
the
same
library.
F
We
would
have
to
change
our
auto
instrumentation
logic
to
auto,
detect
that
and
we
would
have
the
problem
of
like
what,
if
they
don't
use,
auto
instrumentation
right.
It's
not
a
problem,
it's
more
like
it's
just
confusing
for
the
users
at
that
point,
because
they're
like
what
the
hell
is
v2
right
for
flask
versus,
like
they
just
expect
to
install
one
package
and
it
just
works.
F
So
those
are
the
issues
for
the
first
solution.
Obviously,
for
the
second
solution,
it's
it
just
sucks
right
like
just
to
have
a
version
comparison
for
each
piece
of
logic.
That
might
be
a
point
of
contention
and
we
would
have
to
change
the
test
structure
in.
I
think
I
believe
nathaniel
tried
doing
that
already
and
it's
quite
difficult
keeping
everything
in
the
same
package.
D
F
Maybe
a
like
a
a
small
mitigator,
for
that
would
be
to
like
abstract,
common
flask
things
to
like
a
like
a
utility
package
or
a
comments
package
that
would
solve
will
not
solve.
It
would
mitigate
that
issue
a
little
bit
because,
like
the
bugs
that
we'll
be
fixing,
hopefully
pertain
to
all
versions
of
flask
or
the
features
that
we're
adding
will
pertain
to
all
versions
of
flask.
So
they
should
exist
in
a
common
place.
D
B
D
It's
I
don't
know,
I
guess
the
the
reason
why
we
should
discuss
is
because
it
probably
won't
be
just
a
flask
issue.
I
noticed
like
it's
good,
we're
having
discussion
about
it.
We
already
do
this
for
salary,
for,
for
example,
in
our
auto
instrumentation,
we
say
that
our
package
works
for
celery's
version,
four,
five
and
six,
but
you
know
maybe
one
day
celery
will
break
it,
so
abstraction
might
be
might
be
a
good
way
to
do
it,
but
I'm
not
sure
either.
D
A
Well,
even
better,
I
think,
would
be
a
of
course
a
discussion
about
this,
because
I
guess
this
is
a
something
that
will
happen.
Probably.
A
E
Yeah,
I
do
agree
with
nathaniel
that
I
I
don't
know
that
that
discussion
should
necessarily
block
the
pr,
though
yeah
there's
no
there's
no
breaking
changes.
I'm
not
super
concerned
about
merging
this.
This
prn.
D
D
F
E
G
I
was
going
to
say:
don't
a
lot
of
the
instrumentations
sort
of
depend
on
non-public
api
stuff
like
since
they're
doing
monkey
patching,
I
don't
necessarily
feel
super
confident,
even
in
minor
versions
like
not
all
of
them,
of
course,
but
some
of
them,
I
think,
are
right.
D
G
Like
I
think
some
of
them
may
rely
on
internals,
and
I
don't
know
it
just
like.
I
guess
what
I'm
trying
to
say
is
it'd
be
nice.
If
we
could
test
minor
versions
and
and
major
versions
too,
like
I
don't
know,
I
just
I'm
not
too
familiar
with
all
the
instrumentations,
but
I
think
it
might
like
just
since
we're
monkey
patching,
it
might
be
a
little
brittle.
F
D
D
I
think
that's
I
don't
know
from
for
me.
That
sounds
like
it's
kind
of
impractical
to
to
find
out
like
prematurely.
It
almost
feels
like
that's
something
that,
like
some
poor
soul,
needs
to
go
through
and
suffer
and
then
file
an
issue,
and
then
we
can
say:
oh
yeah,
you're
right
it
doesn't
work.
We
either
update
our
instrumentation
or
we
take
the
plan
that
we
come
up
with
with
you
know
like
releasing
a
thing
for
that
specific
version,
but
we
have
to
have
a
plan
in
place.
I
guess
first
for
that.
E
Yep,
it
would
be,
it
would
be
cool
if
we
had
like
a
strategy
ahead
of
time,
though,
so
that
we
can
at
least
when
someone
comes
in
with
a
minor
version
or
even
a
major
version
that
doesn't
work.
We
can
say:
okay,
like
just
follow
the
same
process
that
we
have
for
adding
support
for
it.
So
having
this
discussion
ahead
of
time
is
good.
F
But
that
that
only
will
happen
if
it's
not
like
backwards
compatible
right
like
if
someone
comes
in
with
the
minor
version
problem
like
they
upgrade
to
a
minor
version
of
an
instrumented
library
and
it
breaks
our
stuff.
It's
like
it's,
usually
just
a
bug
fix
right.
It's
not
like
previous
stuff
will
not
work
anymore
right.
D
F
Okay,
yeah
might
be
a
bigger
discussion
that
we
could
probably
just
bring
to
the
issue.
A
Yes,
please
out
all
your
ideas
in
that
issue.
Nothing
in
can
you.
B
A
It
yes
I'll
do
that
yeah!
Thank
you
all
right.
I
guess
we
can
move
to
the
next
topic.
Also
nathaniel.
It's
the
intention
of
the
european
union
that
users
only
have
one
disk
installed.
D
Hey
so
this
was
one
of
the
things
that
one
of
the
awesome
things
that
you
guys
got
through
and
got
pushed
and
merged
into
the
repos,
and
I
was
investigating
it
for
our
team
and
seeing
how
we
can
make
use
of
it.
The
thing
that
does
confuse
me
is
this,
though,
that
you
can
only
have
one
distro
installed
and
one
configurator
installed,
because
it
will
go
through
the
entry
points
and
the
first
one
it
finds.
D
It
will
configure
that
one
immediately
that
I
I
can
see
why
you
guys
did
it
like
that,
but
it
makes
me
think
if
I
make
a
new
distro
like
for
my
team,
if
I
say
open,
telemetry
dash
dash
aws,
does
that
mean
then
that
they
can't
have
the
other
distro
installed,
because
it
will
take
either
theirs
or
it'll
take
mine?
But
that
means
that
there
are
many
things
that
are
really
awesome
about.
D
The
the
basic
open
sounds
you're
just
showing
right
now,
which
it
does
all
the
methods
to
instantiate
the
tracer
provider
with
an
exporter
and
an
id
generator.
But
if
we
go
this
path-
and
you
can
only
have
one
distro,
then
I
would
have
to
copy
and
paste
all
the
code
from
that
one
and
just
put
it
into
my
distro
and
then
they
would
have
to
they
could
use
that.
But
then
you
know
they
could
get
out
of
sync,
the
other
one
could
get
updated.
So
I
was
just.
D
Oh,
hey,
sorry,
go
ahead,
oh
no!
No!
You
can
go
ahead.
Just
to
finish
the
discussion
enough.
I
was
thinking
it'd
be
really
cool
if
we
had
an
environment
variable
that
had
like
hotel
python,
selected
distro,
for
example,
and
then
just
like,
we
do
in
pretty
much
every
other
place
it.
If
you
have
the
environment
variable
set,
it
will
use
that
one.
If
not,
it
will
go
through
the
default
and
use
this
one
instead.
Would
that
be
something
that
you
guys
would
be
open
to?
Having
that's
the
thing
I
was
thinking
about.
F
Wait,
sir,
I
thought
you
were
going
somewhere
else
with
this,
that
that
still
doesn't
address
the
issue
of
like
having
a
distro
needing
to
be
a
superset
of
all
the
districts
that
you
want
right
like.
Yes,
you
can
for
your
environment.
Variable
solution
like
you
can
choose
which
district
you
want.
F
Yes,
which
is
great,
but
your
earlier
point
was
that,
like
okay,
my
aws
digital,
it
has
all
the
cool
stuff
away.
S
has
but
like
it,
I
also
want
the
stuff
that
the
bass
distro
has
right,
but
without
copying
and
pasting
all
the
bass
digital
features
in
the
aws
one,
like
I'm
gonna,
miss
out
on
all
that
stuff
right.
Well,.
D
Well
yeah,
but
I
think
if
the
environments
variable
solution
was
a
thing,
then
then
that
allows
me
to
have
two
distros
installed,
which
is
the
big
thing
because
then,
as
aws,
I
can
require
the
default
one
as
a
dependency.
And
then
I
can
just
subclass.
It
then,
and
I
wouldn't
have
any
issue
about
people
using
aws
distro,
because
now
you
can
have
two
distros
installed.
F
E
But
I
think
I
think
the
so
maybe
we're
talking
in
circles,
because
it
feels
like
we're
we're
maybe
talking
about
the
same
thing
but
yeah.
So
my
understanding
is
that
with
the
ability
to
set
which
distro
you
want
rather
than
iterating
through
the
entry
points
here,
it
would
allow
someone
to
install
like
n
distros
but
then
specifically
request
that
only
one
distro
is
loaded,
whereas
this
thing
would
just
currently
pick
like
it
would
iterate
through
the
entry
points
and
pick
whichever
one
it
finds
first
and
then
discard
all
the
other
ones.
Right.
F
H
D
C
B
C
E
E
F
Just
there
there's
just
been
a
lot
of
activity
in
auto
instrumentation.
There
was
kind
of
a
mess
to
move
it,
but
we
could.
A
Yeah
in
general,
I
think
we
should
be
aware
that
a
four
that
is
raised
through
entry
points
and
a
return.
It's
not
gonna
work,
because
the
the
order
in
entry
points.
I
think
it's
not
something
that
you
can
rely
on.
A
So
exactly
so,
this
is
something
we
should
keep
an
eye
on
the
next
time.
C
Should
we
should
we
be
more
explicit
about
this
and,
like
take
all
the
destroys,
we
get
from
the
iter
function
and,
if
there's
more
than
one
install
then
raise
an
exception
that
we
don't
support,
having
to
destroy
some
stones.
A
D
Was
gonna
say
actually
that
then
that
would
cause
a
problem
to
the
situation
that
I
mentioned.
I
get
that
you
said
you
don't
want
to
disrespect,
but
yeah.
C
I
mean
I
was
assuming
I
was
assuming
if
we
go
with
the
solution
to
move
the
useful
functions
out
of
this
package,.
D
I
want
to
hook
into
those
functions
then,
right
now,
my
my
plan
would
be
to
just
subclass
that
class,
but
is
that
against
what
you
guys
had
envisioned
for
this?
Would
I
not
be
subclassing
and
if
then,
what
would
be
the
expectation?
Would
it
be
for
me
to
write
my
own
way
of
instantiating
the
tracer
provider
and
that
stuff.
A
Well,
everything
that
you
said
makes
sense,
I
mean
if
you
don't
want
to
copy
and
paste
code,
you
use
subclassing.
If
you
want
to
tell
the
entry
point
iterator
or
which
iterator
you
want
to
use
an
environment
variable
I
mean
so
probably.
F
C
Yeah
yeah,
so
my
point
of
view
is
that
a
distro
is
a
user
facing
thing
and
I
find
it
very
hard
to
imagine
where
a
user
might
want
to
install
multiple
distros
and
then
on.
The
fly
choose
one
right.
But
but
there
is
a
very
valid
use
case
where
someone
might
want
to
build
a
distro
on
top
of
an
existing.
C
Yeah,
so
if
if
we
can
identify
that
such
functionality,
maybe
look
at
a
couple
of
maybe
light
steps
blank
and
it
will
just
drop
and
see
what
what's
the
most
common
things
that
they
use.
Maybe
we
can
take
that
code
out
into
yeah.
F
E
E
If
that's
the
easiest
place
to
have
it,
but
but
I
agree
with
always
take
care
that
I
mean
I
I
ideally
any
of
the
functions
that
are
usable
like
reusable
for
multiple
distros
should
be
available
somewhere
in
a
common
base
package
or
in
the
sap,
or
something
like
that.
But
then,
like
the
the
distro
itself,
should
be
very
light
like
in
in
the
case
of
the
default.
Distro
like
I
suspect,
all
it
should
be
doing
is
setting
up
a
couple
of
environment
variables,
and
that's
that's
really.
It.
A
Yeah,
but
how
is
separating
this
into
different
functions,
more
convenient
than
having
this
in
a
class,
because
if
you
want
to
use
all
that
with
classic,
you
just
need
subclass
from
it
and
on
the
other
hand,
you
need
to
import
a
bunch
of
different
things.
A
So
I
think
the
class
approach
is,
I
mean
the
the
cleanest
one.
C
F
Wait
isn't
isn't
base
distro
already
like
the
thing
that
we
build
other
distros
on.
G
F
E
E
F
F
Of
code,
yeah,
yeah,
hey
question
any
preference
or
any
thoughts
on
why
it
needs
to
be
in
the
sdk
or
it
doesn't
need
to
be
I'm
kind
of
reluctant
on
adding
stuff
to
the
sdk.
I'm.
A
F
Is
there
is
there
a
situation
where
the
user
doesn't
take
a
dependency
on
the
sdk,
but
still
wants
functionality
to
be
able
to
build
a
distro.
B
F
A
Yeah,
but
do
you
mean
when
you,
when
you
say
sdk
you
mean
our
sdk.
F
A
Correct,
yes,
what
I
mean
is
the
the
concepts
of
this
through
it.
Correct
me
from
wrong.
Is
it's
something
that
something
that's
just
exclusive
to
python
right
for
now?
Okay,
so
I
think
it
will
be
wiser
to
keep
it
outside.
Yes,
okay,
the
case
or
at
least
that
the
part
is
just
this,
if
possible,
to
separate.
G
Interesting
yeah,
I'm
a
little
confusing
that
too,
it
looks
like
there's
a
there's
open,
telemetry
distro
in
the
main
repo
and
then
in
the
contrib
repo
there's
open,
telemetry
instrumentation
relies
on
right,
distro
and
then
there's
like
other
distros
in
other
people's,
like
contribs
or
in
in
the
main
contributor.
F
G
Yeah
but
if
you're
say
I'm
just
like
sam,
I
don't
know,
I'm
like
a
light
step,
customer
or
whatever
I
just
want
to
automatically
set
it
up,
and
I'm
not
using
the
auto
instrumentation
agent.
I
just
want
to
you,
know,
use
the
light
step
one
and
not
have
to
configure
the
exporters
and
everything
does
that
wouldn't
work
right,
because
it
you
have
to
have
that.
E
I
mean
the
only
thing
you
can
get
is
so
like
the
the
light
stuff
instrumentation.
The
lace-up
distro
has
a
convenience
function
in
it
to
do
the
configuration
for
you
if
you're
doing
manual
instrumentation,
I
see
right,
so
there
should
probably
be
some
something
like
it
as
a
like
as
a
abstract
method
for
all
gestures.
G
F
G
F
Hey
where's,
the
excerpt
in
the
specs
that
says
the
sdk
should
be
responsible
for
all
environment
variables.
F
H
A
Yeah,
what
what
I
think
it
may
not
be
specified
here
is.
A
A
A
All
right
is
there
anything
else
nathaniel.
You
all
would
like
to
discuss
about
this
issue.
D
No
nothing
else
from
my
side,
but
I
guess
do
we
have
a
way
forward.
Do
we
want
to
move
things
into
the
sdk?
Do
you
want
to
use
the
environment
variable
or
suggestions.
F
Okay,
actually
yeah,
looking
at
the
specs
now
I
think,
putting
in
the
sdk
makes
a
little
bit
more
sense,
because
these
are
strictly
like
our
default
sdks
environment
variables.
Right
so
like
it
would
be
nice
to
have
functions
where
it's
like.
Oh,
like
set
ot
log
level
or
something
right
and
then
and
then
the
various
distributors
can
can
utilize
that
that
would
be
quite
cool.
I
would
think
I.
B
F
That'd
be
pretty
sick.
Okay,
I
think
just
to
move
this
forward,
just
create
the
issue
and
then
we'll
just
you
know
kind
of
copy
paste.
What
we
wrote
talked
about
today
and
then
we'll
just
add.
You
know
the
pros
and
cons
of
you
know,
moving
moving
things
and
having
them
in
certain
packages
and
then
we'll
probably
come
up
with
the
decision.
Then,
in
the
issues.
F
F
D
A
Yeah
all
right,
so
let's
move
the
vrs
second
temporary,
for
reviews
on
spr.
Let's
take
a
look
okay,
this
weekend
for
a
headless.
C
A
F
Yeah
the
link
doesn't
work,
you
just
have
to
copy
and
paste
it.
I
mean
just
go
to
the
417.
E
Yeah,
oh
yeah,
it
just
needs
a
it.
Just
needs
a
thumbs
up
from
away
it's
just
a
pr
picture.
F
C
A
All
right,
nice,
okay,
next
vr,
this
one
up
here.
A
A
We
are
already
commented
here,
I
think
some
content
myself
questions,
but
they
have
not
yet
you
know
the
rest
cli
cla
students.
Well,
I
guess
we'll
have
to
wait
for.
A
A
F
G
Yeah,
I
think
if
somebody
else
could
take
a
look
too.
I
like
it,
looks
overall
good
and
it
looks
like
all
the
tests
are
covering
everything,
but.
A
All
right,
nice,
nice.
Finally,
you
have
an
issue
issue.
Four,
four:
five:
oh
yeah!
I
was
looking
at
this.
A
F
Yeah,
so
we
were
taking
a
look
at
the
the
pr
for
this
kind
of
wanted,
like
a
refresher
on
what
this
was
hoping
away.
Was
here
and
the
meeting
oh
wait,
do
you
think
you
can
just
give
like
a
tl.
C
F
Of
what
this
was
again.
C
Yeah
I
haven't
looked
at
the
pr.
Do
you
have?
Could
you
please
say
this
to
me
or
administrator?
So
I
don't
forget
thanks
so
yeah.
The
issue
was:
if,
if
people
install
multiple
server-side
instrumentations
like
whiskey
and
then
flask
and
the
request
comes
in
through
whiskey
and
then
goes
to
flask,
then
we
end
up
with
two
server
spans.
So
it
creates
one
service
pen
and
then
flask
creates
another
one
which
is
strange.
C
So
the
the
proposal
was
for
the
flash
span
to
flask
instrumentation,
taking
it
as
an
example
to
check
if
there
is
an
existing
span
in
the
current
context
and
use
that
as
the
parent
instead
of
extracting
spam
context
from
from
the
propagation
headers.
F
Is
this
it's
related
to
the
issue
where
instrumentations
share
like
the
same
code,
path
and
stuff.
D
C
G
F
Yeah
we
had
an
internal
discussion
about
this
in
azure.
Other
languages
are
like
java
is
doing
something
where,
like
they
have
a
like.
A
current
client
span
context
or
something
like
that,
and
then
they
use
that
as
like
a
check
and
other
languages
are
doing
something
different.
F
There
was
a
solution
that
was
proposed
that,
like
like
check
the
current
span,
sorry
check
the
current
headers
right
and
if
it's
already
has
like
the
whole,
if
the
headers
exist
already,
then
we
can
assume
that
it
has
already
been
processed
or
whatever
but
anyways.
That's
a
that's.
A
separate
discussion,
yeah.
C
F
F
Right,
yeah,
but
cool
if.
F
F
A
Right
away,
take
a
look
at
this
vr
that
hopefully
addresses
the
issue
and
I
think
that's
the
last
issue
than
somebody
else.
That's.
G
No,
no,
the
one
that
you
just
approved
the
this
one
yeah.
So
I
think.
Oh
I
raised
this
discussion.
It's
basically,
I
was
just
reminded
from
the
discussion
nathaniel
brought
up,
because
the
exact
api
version
is
pinned
still
in
all
the
instrumentations,
which
I
don't
think
is
quite
right,
because
right
yeah,
specifically
there's
no
way
to
install
any
instrumentations
along
with
the
1.1080
release
which
has
metrics.
So
if
people
just
want
to
try
it
out
in
their
app
where
they're
already
using
open
telemetry
with
instrumentations,
it's
kind
of
impossible
right
now,.
G
I
don't
know
if
there's
not
a
lot
of
discussion
on
here.
I
think
people
generally
agree
and
I
think
we
said
we
might
look
into
like
how
to
most
easily
do
this
with
the
release
process
right,
because
currently,
the
release
always
like
updates
the
pin
version
right.
G
F
G
B
G
To
me,
okay,
so
then,
like
action
items,
what
should
we
do
is
the
issue
like
the
script
like
what's
blocking
this.
C
Yeah
yeah,
that's,
I
think,
that's
another
issue
so,
but
once
we
do
this
normally
we'll
have
specific
versions
pinned
instead
of
dev.
So
when
we
run
talks,
we'll
just
pull
those
specific
dependencies
from
from
wi-fi,
but
then
in
some
cases
we
might
have
like
a
package
might
depend
on
another
package
that
has
not
been
released
yet
and
is
is
in
dev.
So
in
that
case,
so
we
have
we'll
have
the
current
behavior,
the
one
we
have
today
so
so
so
like
we
conditionally
need
talks
to
work
with
both
cases.
C
G
Yeah,
I
think
I'm
sorry,
oh
I
was
just
gonna
say
I
think
that
should
be
doable
like
in
a
number
of
possible
ways,
and-
and
maybe
we
only
need
to
do
that
right
before
release
like
we
don't
need
to
test
out
on
every
pr,
because
I
think
our
ci
suite
is
already
taking
quite
a
while.
So
what
we're
gonna
say,
layton.
F
Oh
sorry,
did
you
say
that
we
won't
be
testing
against
the
dev
versions
of
packages
anymore.
C
C
I
think
so
yeah,
so
I
I
think
if
let's
say
there's
a
flask
instrumentation
and
it
depends
on
the
instrumentation
package
1.1
and
the
latest
instrumentation
packages
on
wi-fi
is
1.5
and
it
doesn't
need
any
feature
from
1.2
to
1.5.
C
So
it's
it's
been
its
dependency
on
instrumentation
package
to
1.1,
so
we
should
always
test
with
1.1
right.
We
could
test
with
dev
1.5,
but
but
but
it
would
be
better
to,
I
think,
more
robust
to
test
with
the
same.
F
C
C
E
Yeah,
I
guess
if
we
changed
all
the
dependencies
and
the
in
the
packages
to
using
like
a
whatever
a
1.0
compatible
version,
then
I
guess,
if
someone
was
to
make
a
change
in
an
instrumentation
that
depended
on
the
dev
version,
it
would
fail
the
build
which
would
be
good
for
us
to
know
and
then
they
would
have
to
go
and
change
the
dependency
to
like
the
dev.
The
current
dev
package
right.
C
Yeah
yeah
true,
I
just
I
just
brought
it
up
because
like
we
might
need
some
changes
to
talks
to
support
the
use
cases,
I'm
not
sure
maybe
yeah
yeah.
E
I
I
agree.
I
I
think
I
do
think
that
that
would
like.
Basically
that
would
just
add
a
little
bit
of
complexity
to
creating
prs,
but
I
think
that's
fine,
because
then,
like
the
users
would
know
that
they're
relying
on
the
future.
That's
not
it's
not
released
yet
so
then
it
would
at
least
signal
like
the
maintainers
that
they
would
have
to
to
remember
to
update
the
dependency
or
whatever,
to
like
a
newer
version
of
the
api
or.
E
F
G
So
if
it
relies
on
like
a
new
version
of
the
api
or
sdk
yeah,
hopefully
they'd
see
the
test
would
break
or
they
would
do
it
manually
and
update
the
like
the
minimum
requirement
that
they
need.
E
Right
and
then
the
the
release
process
would
have
to
check
that
there's.
No,
so
so
you
know
you're
writing
instrumentation
for
fast
right
now
you
have
a
1.0
dependency.
Your
tests
are
succeeding
until
you
make
a
change
that
depends
on
1.6,
yes
without
six
version
of
the
api.
So
now
you
you
publish
a
change,
it
fails
the
ci.
E
F
E
F
E
F
You
can
add
a
step
in
the
contributing,
as
well
like
just
yeah,.
F
G
A
F
We're
not
that
advanced.
Okay,
any
other
discussion
points
for
this.
F
Minutes
left
diego.
C
Discussion
points
but
yeah.
F
F
Oh
yes,
also
speaking
of
metrics,
diego.
Are
there
any
updates
on
the
on
the
metric.
A
Side,
yes,
so
I've
pretty
much
integrated
this
with
these
that
we
had,
and
I'm
now
I
think,
implementing,
hopefully
the
last
logic
layer
of
this
wd
aggregators.
So
once
that's
done,
I
I
hope
that
I
can
go
straight
to
the
prototype,
we'll
let
you
know
so.
We
should
hopefully
stop
shortly
so
that
I
can
finally
show
you
also.
F
Speaking,
I
see,
do
you
anything,
do
you
need
anything
from
us
until
that's
finished.
A
A
G
One,
I
think
so
josh
my
colleague,
google
is
working
on
it.
I
think
he's
done
the
api
and
I
think,
he's
done
a
lot
of
the
sdk
and
found
some
issues
which
were
raised
in
like
the
last
cig
and
we
haven't
completely
decided
on
but
yeah.
I
think
the
api
prototype
should
be
pretty
good.
I
don't
know
if
it's
like
published
anywhere
but
yeah.
E
F
Yeah
aaron:
do
you
know
if,
like
josh,
it
just
exists
in
a
pr
or
something
or
it's
like
an.
F
F
But
yeah
all
good
okay
cool,
we'll
just
we'll
just
wait
for
diego's
update,
then.