►
From YouTube: 2021-05-20 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
A
Cool
yeah
so,
as
usual,
add
any
topics
that
you
guys
want
to
talk
about
today
and
please
include
your
name
in
the
attendees
list.
A
We
have
a
couple
of
prs
and
issues
that
we
want
to
go
over.
A
A
Okay,
I
think
we
can
get
started
we'll
begin
with
the
some
of
the
topics
that
way
has
posted.
Oh,
let
me
show
my
screen.
A
B
Talk
over
this
a
little
bit
yeah,
I
tried
to
implement
this
in
one
of
my
open
prs,
but
I
removed
the
functionality.
There
was
some
debate
or
what
the
api
should
look
like.
So
I
thought
it's
better
to
discuss
it
in
the
sig
before
I
have
a
pr
sure
so
and
there's
another
pr
by
community
member
who
so
the
change
they
are
making
is
to
comply
with
the
spec.
They
are
they're
dropping
attributes.
A
Upon
span
creation,
if
any
of
the
limits
are
exceeded
right
now
we
throw
a
value
error
right.
A
His
change
makes
it
so
that
the
values
are
truncated
instead.
Okay,
right.
B
Yeah
yeah
exactly
so,
the
specs
suggest
that
if,
if
an
sdk
implements
that,
then
they
should
also
allow
setting
limits
to
address
the
provider.
So
this
this
would
satisfy
the
pr
as
well
the
requirements
for
the
pr.
B
So
the
main
question
is:
should
tracer
provider
accept
each
limit
as
an
individual
argument
or
should
limit
be
a
concept
like
sampler
or
id
generator,
and
then
we
pass
down
a
limits
instance
to
jessica.
B
So
I
I
personally
think
limit
as
a
concept
as
a
clause
is
more
flexible
down
the
line
and
but
but
happy
to
hear
other
thoughts.
A
So,
just
to
clarify
this
so
alongside
the
the
pr
that
this
other
random
guy
made
this
whole.
If
the
sda
implements
the
limits
above,
it
must
provide
a
way
to
change
these
limits
via
configuration
to
the
chase
provider.
Does
that
mean
that,
like
the
limits
can
be
changed
like
during
run
time,.
B
No,
I
don't
think
the
spec
recommends
that,
but
it
doesn't
prevent
us
from
implementing
that
either.
I
don't
think
we
should
implement
that
now.
A
B
A
B
Clear
about
that
yeah
yeah,
but
that's
one
of
the
points
I
I
raised
here
like
down
the
line.
If
you
want
to
implement
something
like
that,
a
class
would
be
very
easy
to
would
allow
us
to
do
that
very
easily.
But
it's
true,
but
using
individual
arguments
would
mean
you
need
to
create
new
instances
of
just
a
provider
or
maybe
have
another
methodological
way
that
then
gets
called
on.
The
change
looks.
C
A
B
C
B
But
I
removed
I
removed
so
what?
What?
What's
in
the
proposal,
I
removed
this
part
from
the
pr
so
so
that
we
could
discuss
it
before
before
having
it
in
another
yeah.
B
No,
no
just
just
the
description
discussion
I
started
so
if,
if
you
could
take
a
look
at
it,
maybe
we
could
have
this
next
week,
yeah
or
just
like
share
your
thoughts
below.
A
Diego,
what
was
your
initial
issue
with
this?
I
I
forgot.
C
This
a
few
issues
with
with
epr
one
of
them
was
that
we
were,
I
thought,
the
the
attributes
that
are
defined
in
the
limit
class,
we're
just
being
wrapped
into
something
extra
and
being
passed
into
these
spans
with
our
span
attributes.
C
But
mostly
my
sorry,
yeah
then
away
made
limits
private,
but
limits
were
still
being
exposed
in
a
public
method,
but
we
fixed
that
so
after
that.
A
A
A
Right
so
away
like,
is
this
discussion
still
needed,
or
are
we
just
going
through
what
we,
what
you
decided
in
the
pr.
B
It
is,
it
is
needed,
so
so
what
the
what
the
discussion,
what
this
proposal
is
proposing
was
part
of
the
pr,
but
later
I
removed
it
to
simplify
the
vr
so
now
now
I
want
to
get
like
everyone's
thoughts
on
how
I
should
proceed
with
this
okay,
so.
B
B
B
One
is
we
will
allow
users
to
set
a
limit
to
unlimited,
which
we
don't
right
now
so
right
now,
users
can
use
any
variables
to
change
the
defaults,
but
it
has
to
be
a
number,
but
this
pr
allows
them
to
set
it
to
a
string
called
unset
which
then
doesn't
set
the
limit,
and
it
just
goes
on
unlimited
and
it's
on
the
user
that,
if
like
they
can
have
out-of-memory
issues
or
things
things
like
that,
but
but
they
can
choose
to
do
that
and
another
thing
this
does
is
right
now,
whenever
the
configuration
values
are
red
on
globally
on
import.
B
So
whenever
you
import,
tracing
dot,
sdk
or
sorry,
open,
telemetry,
sdk
for
trace
these
values
are
red
and
then
they
can
never
be
changed.
So
this
pr
is
changing
it
to
read,
to
read
and
set
the
values
lazily.
So
the
values
are
read
only
when
you
create
a
tracer
provider.
Instance
right,
so
that
that
that
makes
it
easier
to
set
the
even
though
we
don't
allow
it
to
set
it
through
code,
but
it
makes
it
possible
to
like
use
os
dot.
Enron
to
set
the
values.
B
B
So
this
has
no
public
api
changes
by
the
way.
One
more
thing
that
I
didn't
enter
the
document
I
it
just
came
up.
I
just
remembered
so
I
had
added
a
argument
to
the
span.
Constructor
and
diego
pointed
out
that
it's
it's
public
which
it
technically
is
but
span,
is
kind
of
private
because,
like
no
one
is
supposed
to
use
it
directly,
in
fact,
we
don't
even
allow
it.
We
raise
an
error.
So
in
that
case,
do
we
consider
the
spam
class
part
of
the
public
api
or
is
it?
Is
it
private.
C
It
is
part
of
the
public
api
because
it's
not
preceded
by
an
underscore.
I
understand
that
there
is
some
additional
things
like
a
recent
error
or
something
like
that,
but
for
api
purposes
we
should
stick
to
the
definition,
which
is:
is
it
preceded
by
an
underscore
or
not.
C
D
C
A
B
All
right,
nice
now
this
one
this
was
a
this
is
the
old
one.
I
think
in
principle.
We
had
agreed
to
do
this,
but
it
involves
a
lot
of
work,
so
I
just
want
to
bring
it
up
again.
I
think
aaron
also
brought
something
similar
up
on
slack
this
week,
so
maybe
we
should
think
about
if
we
want
to
do
this
anytime
soon
and
maybe
create
issues.
E
Yeah,
I
just
wanted
to
call
out
that
right
now,
with
the
way
that
things
are
pinned,
it's
impossible
to
install
an
instrumentation
with
one
with
the
metrics
like
alpha
package,
because
all
the
instrumentations
have
a
specific
like
1.1
or
whatever
we're
at
right
now,
and
so,
since
those
packages
are
like
a
like
one,
dot,
one
zero,
a
zero
or
whatever
it
won't.
It'll
dip
will
complain
that
there's
a
dependency.
B
A
A
Yeah,
I
think
this
is
like,
like
we
just
have
to
do
this.
It's
just
a
lot
of
work,
so
not
much
else
to
say
right.
A
Yeah
like
whenever
we
update
a
new
release,
it
updates
all
of
the
stuff
right.
B
The
main
problem
here
is
now
that
we
have
actual
dependencies
instead
of
just
using
the
latest
version,
contributors
or
maintainers-
or
I
don't
know,
or
both
of
them
together
need
to
figure
out
the
dependencies
when
things
change.
So
if
I
implement
something
in
distro
that
needs
newer
version
of
sdk,
then
I
need.
I
need
to
be
sure
that
I
bump
the
sdk
dependency
in
distro
setup.cfg,
so
like
we
need,
we
need
some
sort
of
process
to
make
sure
that
happens.
I
guess
that's
the
biggest
issue
right.
A
Yo
alex
like
when
we,
when
we
release
a
new
version
of
the
api
or
sdk
like
we
change
all
of
the
dependencies
in
every
of
the
instrumentations
right
right
now.
Currently
we
bump
them
up,
but
with
this
change
right
like
if
we
want
to
have
this
happen,
then
only
if,
like
an
instrumentation,
has
a
change
within
that
release,
would
we
do
that
right?
F
I
mean
it,
wouldn't
I
I
think
those
two
are
different
issues
right.
I
think
I
think
one
thing
that
we
would
definitely
stop
doing
is
we
wouldn't
be
updating
each
package
to
just
update
the
versions
of
the
api
and
sdk
that
are
available
for
dependencies,
so
I
guess
yeah
in
theory
we
could.
We
could
stop
releasing
all
the
instrumentations
every
time
right.
E
So
sorry,
I
was
kind
of
missing.
That
is
the
problem
that
you
don't
want
to
release
the
instrumentations
with
every
contrib
repo
release.
F
E
F
No,
it's
more
like
you
know
ensuring
that
we
do
release
things
that
have
changed
because
right
now,
the
like
the
ci
is
pretty
dumb
it
just
it
doesn't.
Look
like
it
doesn't
look
at
individual
changes
to
determine
if
package
needs
to
be
updated.
It
just
does
like
a
sweeping
search
and
replace
right.
B
There's
another
issue
with
this,
so
the
this
affects
the
development
workflow,
because
today,
if
you
are
working
on
an
instrumentation
or
on
some
package
like
distro
in
local
development,
it
always
depends
on
the
latest
versions
of
other
components
like
api
and
sdk.
B
So
so,
once
we
change
this,
we
would
have
to
depend
on
the
least
compatible
version
right
to
do
to
make
sure
that
we
don't
depend
on
any
new,
newer
versions.
So
all
people
would
have
to
bump
those
versions
explicitly,
and
this
means
that
local
talks
or
each
disk
or
whatever
systems
are
used
to
resolve
dependencies,
would
have
to
be
aware
of
whether
they
want
to
install
the
package
from
the
main
branch
from
local
disk,
the
development
package
or
from
pipeline.
B
B
Yeah,
I
mean,
let's
say
you're
working
on-
let's
say:
django
instrumentation
right
so
general
instrumentation,
this
open
telemetry
api
as
a
dependency
and
the
version
that
lists
is
the
same
dev
version.
That's
in
that's
in
the
same
repo
right,
so
the
current
development
version
of
api.
But
if
we
do
this,
then
that
means,
if
we
test
with
the
development
version
that
means
django,
would
the
instrumentation
could
by
mistake,
use
some
features
that
are
newer.
Then.
F
B
What
the
package
would
depend
on
when
it's
published
right
right,
so
that
means
some
packages
would
by
default.
Most
packages
would
depend
on
api,
sdk
and
other
packages
for
and
download
them
from
pip,
but
sometimes
you'd
want
them
to
be
referring
to
the
local
ones.
If
you're
like
working
on
two
packages
that
depend
on
each
other,
oh.
A
A
B
I
think
by
default.
That
would
be
the
case,
but
but
there's
also
use
cases
where
we
would
want
that
to
happen.
So
if
I'm
building
a
feature
where
I'm
working
on
sdk,
but
it
needs
to
depend
on
some
other
word,
some
other
new
feature
in
api,
then
I
need
to
use
the
local
version
of
api
while
developing.
Otherwise.
The
implication
is
that
I
first
need
to
release
api
package
and
then
work
on
sdk
with
the
new
package,
which,
which
would
be
very
annoying.
F
E
B
E
Twice
I
forget
exactly
how,
like
our
tax
file
is,
but
be
great
if
we
could
do
both.
B
I'll
create
an
issue
for
this
and
just
try
to
try
to
create
a
few
pr's,
like
example,
beers
that
that
showcase
different
scenarios
and
just
try
to
figure
out
like
how
to
change
this
actually
needs
in
order.
Maybe
we
can
then
review
next
week.
A
Okay,
sure
is
there
a
way
to
do
this,
like
maybe
like
compartmentalize
this?
It's
not
that.
B
E
Yeah
one
other
thing
is
at
a
minimum.
I
think
if
we
just
change
the
script
instead
of
putting
equal
equal
and
then
the
full
version
that
we're
releasing,
if
we
change
it
to
just
put
like
tilde
equal
and
then
the
major
dot
minor,
I
think
that
would
like
it
would
still
increase
every
time
and
I
think,
with
the
script,
it
would
be
like
an
easy
change
and
then
that
would
at
least
allow
people
to
install
the
alpha
one
right
right.
A
E
Quick
question:
what's
the
alpha
version
so
like
say
you
release
like
1.4
tomorrow,
what
would
the
alpha
version
be?
Would
it
be
like
1.5,
a
zero.
B
E
A
A
B
A
All
right
we'll
go
right
into
piers,
then
I
think
we
talked
about
this
one
already
yeah
but
anyways
who
out
of
this?
A
B
Yeah
yeah
so
yeah
this,
the
pr
itself
looks
fine.
It's
just
that
according
to
spec,
this
depends
on
the
discussion
that
I
was
talking
about
earlier.
A
Right
so
I
guess
for
now
we
we
could
just
leave
this
until
we're
able
to
configure
it
get
the
tracer
for
better.
A
A
A
Okay,
cool
yeah,
well
I'll,
just
we'll
just
get
this
in.
Let
me
review
this.
Can
we
have
someone
else?
Also
take
a
look
at
this
too,
because
this
is
a
spec
related
issue.
A
A
Yeah,
I
think
it's
because,
like
maybe
I
add
this,
and
just
put
your
name
on
it,
because
you're
the
only
one
who
commented
on
it-
okay,
so
alex-
and
I
were
talking
about
this
right
and
then
the
original
issue
stems
from
so
fast.
A
Api
instruments
are
not
popular
attributes
right
so
basically
like
whenever
someone
makes
like
a
request
to
like
an
ascii
app
like
multiple
spans
are
generated
right
and
if
you
take
a
look
at
the
actual
logic
here,
like
there's
a
span,
that's
created
for,
like,
like
the
initial
channel,
that's
created,
and
then
there's
spans
for
this
like
the
individual.
A
What's
it
called
like
steps
within
the
when
the
actual
request?
This
is
all
encapsulated
within,
like
one
single
request,
so
without
actually
understanding
really
like
deep
diving
how
ascii
works
like
conceptually,
we
don't
know
what
to
do
in
terms
of
like,
like
does
it
make
sense
for
all
of
them
to
be
individual
spans
like
should
this
all
be
encapsulated
into
one
span,
just
like
any
other
like
http
instrumented
library,
if
not
like?
A
If,
if
we
leave
this
as
separate
spans
like
what
does
the
status
code
mean
right
like
what
is
the
status
of
the
entire
request
and
what,
if
like
one
of
them,
fails
individually
right
so
this
this
distribution
was
contributed
by
to
here
and
like
he's
no
longer
here
so
like
it's
difficult
for
us
to
gauge
what
to
actually
do
for
this.
So
I
was
kind
of
just
like
adding
this
and
like
kind
of
opening
up
the
floor
into
like
what
would
conceptually
make
sense
in
this
case
right.
A
The
initial
issue
is
that,
like
right
now,
this
the
parent
span
just
doesn't
have
a
status
right,
but
that
opens
up.
The
question
is
like:
do
we
even
need
a
parent
span
right?
Do
we
even
need
individual
spans
for
each?
Should
there
just
be
one
span?
A
I
don't
know
what
do
you
guys
think
take
it
in
like?
I
don't
really
know
much
about
ascii.
I
don't
know
why.
Each
of
these
bands
has
like
a
an
appended
like
dot,
receive
scope,
type
thing
right.
This
doesn't
seem
like
it
follows
semantic
conventions
either.
A
So
you
know-
and
I
don't
know
if,
like
other
instrumentations
are
like
that,
people
have
contributed
randomly
or
like
also
just
have
random
stuff
like
this,
but
that
just
goes
to
show
that,
like
we
kind
of,
have
to
now
be
a
bit
careful
about
what
is
implemented.
But
for
now
like
we
should
go
over
at
least
what
ascii
is
doing,
because
this
is
a
popular
instrumentation
library.
So.
B
Yeah,
can
you
assign
this
ticket
to
me
I'll,
try
to
deep
dive
and
figure
it
out.
A
Okay,
cool:
I
can
help
you
with
this
too,
because
I'm
I'm
actually
interested
in
what
what's
going
on
here.
Yeah.
F
Yeah,
I
guess
this:
let's
just
bring
out
the
the
the
problem
with
the
contemporary
poet
that
without
becoming
experts
in
each
one
of
those
libraries,
it's
going
to
be
very
difficult
to
know
what
the
right
thing
to
do
is-
and
I
don't
know
how
we're
going
to
scale
that,
with
this
group,
that's
very,
very
small
but
yeah.
A
Right
exactly
especially
because
we
already
have
a
lot
of
contributed
instrumentations
that
not
necessarily
everyone
here
has
context
about.
A
B
Maybe
we
can
have
something
like
a
like
a
test
bed
of
sorts
that
runs
every
instrumentation
and
then
at
least
verifies.
Let's
say
semantic
conventions
are
not
violated
or
something
I
know
it
doesn't
solve
the
problem
with.
If
the
library
is
correctly
instrumented,
but
at
least
it
would
get
some
issues,
I
guess.
A
Yeah,
and
also
we
talked
about
last
week
that,
like
like,
I
still
have
to
make
the
whole
like
the
checklist
of
stuff
that
people
have
to
go
through.
I
think
that
would
help
as
well.
I
just
need
to
make
more
barriers
for,
for
you
know,
in
order
to
make
a
correct,
correctly
implemented,
instrumentation
yeah,
I
still
have
to
get
on
that.
A
A
Awesome,
let
me
let
me
take
I'll,
take
a
look
at.
A
A
F
A
It's
okay,
I
think
pretty
straightforward.
A
B
B
Yeah
my
comment
was
that
probably
don't
put
it
under
bear
utils,
because
it's
hard
to
find
like
discover
code
and,
if
everything's,
bundled
in
our
details.
So
if
it's
so
these
functions
are
the
functions
are
directly
related
to
attributes,
so
maybe
add
an
attributes
package
or
maybe
a
sub
package
under
youtube.
It's
called
attributes
that
was
merely
a
code
structure.
A
You
guys
think
you
think
it's
do.
You
guys
think.
A
I
think
this
is
fine,
yeah
just
move
to
the
api
package
and
put
it
under
the
utils
attributes
namespace.
I
think
it's
fine
make
sense
everyone.
Any
objections.