►
From YouTube: 2020-05-21 Python SIG
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
B
B
C
B
C
A
A
Yeah
not
a
lot
of
a
lot
of
topics
today,
apparently
I
don't
know
if
that's
because
everything
is
going
so
well
or
people
are
just
too
busy
to
add
topics
here.
But
did
you
have
anything
you
want
to
bring
up
here?
I
think
I
only
had
one
which
was
around
the
next
release
and
whether
or
not
people
had
any
kind
of
idea
for
what
they
needed
release
and
one.
A
All
right
so
I
guess
for
me,
my
in
my
goal
for
the
next
release
is
to
just
have
it
soon,
which
would
likely
be
sometimes
next
week,
if
possible,
just
to
pay
down
some
of
the
pain
around
the
release
process.
I
think
that'll
be
a
forcing
function
for
me
to
actually
spend
time
digging
into
some
of
the
results
from
the
post-mortem
from
last
to
the
last
release.
So
if
no
one
has
any
objections,
I
would
say
like
next
week.
It's
a
good
time
for
another
release,
but
I'm
open
to
open
to
suggestions
here.
A
B
A
You
know
there
was
a
discussion
estimators
meeting
Monday,
but
there
was
a
discussion
around
what
the
release
cadence
will
be
for
open
23.
Once
we
had
GA
and
I
think
getting
getting
that
sorted
before
we
get
to.
J
is
probably
a
good
thing,
because
we
still
have
the
it's,
not
the
ability
to
kind
of
be
a
little
bit
more
lenient
in
case
things.
Don't
work.
B
C
Yeah
I
mean
so
yeah
I
introduced
myself.
I
was
planning
on
originally
planning
on
working
on
integrations
for
quite
a
while,
but
since
the
majority
of
the
important
ones
are
mostly
fleshed
out
I'm
going
to
move
towards
exemplars
in
the
next
few
weeks,
so
there's
a
lot
of
spec
work
that
needs
to
be
done
there
first,
so
I'm
going
to
be
focusing
on
that
and
then
I'll
yeah
we're
on
implementing
that
and
then
maybe
go
back
to
integrations
later
on
or
something
else.
Magic-Related
awesome
welcome.
B
D
B
Okay,
well
I
can
say
in
the
meantime
we
didn't
know
if
you
guys
can
tell
we
have
kind
of
a
interesting
organizational
problem
and
that
we
have
one
team
that
was
open,
telemetry
and
another
team
that
was
stackdriver
and
now
cloud
trace
and
cloud
monitoring.
And
so
these
guys
are
all
in
the
like
cloud
trace
cloud
monitoring
work,
so
they're
they're
gonna
be
working
on
the
entire
project,
but
they'll
have
like
a
particular
focus
on
making
like
stackdriver
work,
Wells
back-end.
So
hopefully
this
can
bring
some
some
more.
B
H
About
I
can
sorry
I
was
kind
of
setting
up
that
whole
PR.
Section
I
can
maybe
talk
through
some
of
these,
so
the
first
three
I'm
throwing
out
here.
All
of
these
have
an
approval
by
by
me
already.
They
actually
just
do
one
more
stamp.
When
we
can
merge
him
in
I
would
just
call
out.
You
know:
Alex's
first
PR
isolate
CI
cycle
heavily,
say
she
has
Stickley
improved
she's
found
it
like
I
mean
I
like
secret
I,
talk
about
it
more,
but
it'll
help
a
lot
with
yeah
yeah.
A
It
doesn't,
it
doesn't
cut
out
near
as
much
as
I
wanted
to,
unfortunately,
because
the
pip
install
upgrade
stove
needs
to
happen
and
a
bunch
of
different
old
problems
and
I
haven't
found
a
good
workaround
there.
If
someone
has
a
good
way
to
accelerate
that,
because
I
would
be
all
yours,
but
basically
a
lot
of
our
CI
spends
like
10
seconds
per
per
different
for
target
in
talks
installing
and
upgrading
pip
and
the
different
virtual
environments.
Are
we
running
because
we're
suspending
up
a
different
virtual
environment
for
every
test
target?
A
Basically
we're
doing
it
like
20
times
per
build,
so
we're
wasting
a
lot
of
seconds
and
in
fact,
if
you
take
that
out
of
the,
if
you
take
that
step
out
of
the
build
it,
these
are
basically
every
build
by
about
two
minutes
or
so
anyways
I.
Don't
have
a
good
workaround
for
that
I
think.
Ultimately,
the
real
solution
is
suggest
is
to
just
not
have
all
of
these
integrations
in
the
same
repo,
which
is
something
we
were
planning
on
doing
anyways.
A
H
I
H
H
I
just
want
to
call
this
one,
our
there's
a
lot
of
discussion
around
it
effectively.
It's
just
adding
an
adding
first
flush
method
to
the
I.
Think
like
the
yeah
one
of
the
propagators
I
forget
the
multi,
yeah
I
think
it's
the
multiple,
the
one
that
combines
multiple
exporters
or
processors
into
a
single
one.
So
there's
I've
been
lolly
conversation
around
it.
Just
would
love
someone
to
kind
of
give
it
a
final
review,
calling
this
one
on
particular,
because
it's
kind
of
one
of
the
oldest
ones
that
that
has
like
at
least
one
approval.
So.
H
Anyway,
it
I
think
it
requires
someone
to
actually
go,
give
it
a
little
bit
more
of
a
look,
but
that
would
love,
maybe
someone
that
just
kind
of
committed
reviewing
that
one
direction
or
another
and
I
think
like
at
this
point:
I,
don't
even
know
if
Mario
is
still
like
she's
still
in
this
room
or
working
on
it,
so
would
be
great
for
everyone's
sake.
Yeah
he's
not
here
today.
H
H
You
know
we
already
have
multiple
sort
of
thread
thread
executors,
and
so
you
might
find
that
you're
sort
of
nesting
thread
executions
together
by
having
yeah
that's
the
bad
spam
processor,
but
by
having
a
spam
processor
call
an
exporter
which
itself
spawns
a
thread
so
I
think
it's
it'll
be
easier
to
have
someone
kind
of
gain
context.
I
think
I'm,
just
asking
one
person
to
actually
take
a
look
and
kind
of
weigh
in
on
that
too.
H
J
B
Yeah
I
would
say,
wherever,
like
you
feel,
best
developing
it
wherever
its
fastest
like
feel
free
to
do
it
inside
or
outside
the
repo,
and
then
we
can.
We
can
try
and
help.
I
know
it's
like
pulling
teeth
already
to
get
reviews,
because
people
are
split
across
a
lot
of
different
work,
but
one
reason
to
keep
it
in
this
repo
for
a
while
may
be
that
it's
probably
gonna
be
even
harder
to
get
reviews
from
people
in
this
thing,
when
it's
not
in
this
repo,
certainly
yeah
I
mean.
H
You
know
on
that
point
right
only
reason
we're
even
discussing
moving
it
out
right
now
is
because
of
process.
I
mean
we're
having
trouble
getting
approvals,
so
I
mean
I'll.
Just
share
my
personal
perspective.
If
the
choice
is
to
kind
of
keep
the
the
technical
benefits
and
shook
the
process
a
little
bit
or
keep
the
process
and
like
lose,
the
technical
benefits
I
prefer
the
former.
H
So
you
know
I'm
kind
of
at
the
point
where,
like
you
know
here,
obviously
I
will
look
at
your
at
your
diff
okay,
but
as
long
as
there's
not
like
just
terrible
syntax
errors
or
anything
I
trust.
Your
ability
here,
I
will
just
immediately
approve
as
as
soon
as
you
pay
me,
oh
I
was
much
like
I
guess.
That's
my
that's
my
personal.
That's
my
personal
perspective.
All
in
that,
whatever
everyone
wants
to
do.
A
A
A
You
know
during
a
thorough
review
and
and
more
about
getting
the
approval
to
get
an
on
blog
for
a
particular
either
vendor.
Or
you
know,
library,
integration
or
something
like
that,
whereas,
like
the
the
main
repo
should
really
be
like
all
about
the
API,
is
in
the
SDK
ISM
and
all
that
stuff
and
I
think
yeah.
H
H
Mean
I
think
if
we
do
go
that
route
right,
the
only
thing
stopping
us
from
doing
that
today
is
the
lack
of
people's
in
like
time
to
invest
in
tooling
yeah,
so
I
guess
I
would
maybe
call
out
like
I.
Don't
I
know
that
everyone
kind
of
has
their
own
priorities
but
at
the
same
time,
I
think
if
anyone's
looking
to
maybe
shift
focus
a
little
bit
and
make
a
significant
contribution
to
our
velocity
long
term.
I
think
helping
us
build
the
tooling
necessary
to
have
both
the
contraband.
H
The
main
repo
would
be
very
beneficial,
so
I
guess
I'll.
You
know
a
call
to
everyone
in
this
room
and
maybe
like
for
the
for
the
interns
like
Andrea
counter
and
stuff
I,
don't
know
how
much
control
you
have
over
what
you
choose
to
work
on,
but
from
the
open,
telemetry
standpoint,
I
use
them
the
Python
site.
I
think
it
would
be
a
huge
win
if
someone
wanted
to
actually
focus
a
little
bit
more
on
that
I.
Think
Alex
can
give
a
lot
of
context
on
what
is
necessary
to
make
that
happen.
I.
A
Would
also
like
to
call
out
that
we
don't
have
a
second
approver
for
the
contributor
at
this
point.
So
I
don't
know
if
it
makes
sense.
I
just
have
the
same,
the
same
list
of
approvers
that
we
have
here
and
the
same
maintainer.
Maybe
it
does
I
think
maybe
that's
something
that
we
should
change,
because
right
now,
I
think
it's
a
separate,
a
separate
list
of
approvers
and
maintainers
I.
Don't
know
if
it
makes
sense
to
have
a
separate
list
like
that.
Pretty.
H
Sure
it
doesn't
yeah
I
mean
it's
I
mean
we
could
all
keep.
We
could
keep
everything
in
the
same
repo,
too
and
kind
of
do.
A
Chris
is
suggesting,
but
I
think
regardless
right,
we're
gonna
we're
gonna
end
up
in
a
situation
where,
at
some
point
someone
is
going
to
build
a
package,
that's
compatible
with
open
telemetry,
but
not
in
the
core,
open,
telemetry
repo.
So
whether
we
use
that
tooling
in
a
single
repo
use
that
tooling
in
multiple
repos
I
know
it's.
We
need
that
tooling.
H
H
A
H
K
K
I
K
H
A
A
K
H
Yeah
so
I
I
kind
of
want
to
go
through
these
two
sections,
maybe
before
the
new
PR
is
just
because
you
know
one
one
go
like
I
kind
of
have
in
mind
is:
let's
remove
all
the
PRS
from
truth
in
nineteen,
make
one
decision
or
another,
so
one
is
I,
see
that
there's
a
new
cloud
trace,
sorry
I'm,
putting
that
name
cloud
trace
exporter
that
you're
the
Andrews
working
on.
If
that's
the
case,
can
we
just
kind
of
aggressively
close
the
other
one
previously
like
this
deck
driver?
One.
B
H
J
H
H
Right
so
great,
so
if
we
can
get
those
so
that'll
clean
up
duplicates
and
that
will
clean
up
to
PRS
that
I've
been
open
for
over
two
months
and
then
right
here
is
there's
just
a
bunch
of
them
that
are
kind
of
left
here
and
I
think
it
might
be
good
and
we
just
talked
through
each
one
and
decide
on
what
the
action
plan
is
yeah.
This
one.
B
I
can
close
this
one
I
mean
I
would
love
to
have
this
work
done.
The
problem
is
the
way
violent
works
as
long
as
we
have
any
module
name
that
matches
a
built
in
module
name
is
going
to
give
us
a
bunch
of
false
positive
one
tears
so
either
we
have
to
go
fix
pilot
or
we
have
to
rename
all
of
our
modules.
So
I
think
this
one
is
just
a
non-starter
until
pilot
fixes,
their
bugs
and
I
mean
how
it's
like.
B
H
B
H
Sorry
yeah,
so
it
is
a
so
there's
two
parts
of
this
PR.
Actually
I
haven't
looked
at
the
code,
but
no
I'm
from
the
title.
There's
two
parts
pr1
is
yeah
the
requirement
of
low
cardinality
span
names
and
for
the
whisky
implementation
I
believe
today
we're
actually
using
the
yeah
the
actual
path,
which
is
not
correct,
because
that's
gonna
leave
an
extremely
high
cardinality
span,
name
because
every
single
span
is
going
to
have.
You
know,
if
has
a
unique
ID
inside
of
it.
H
So,
on
the
SGI
side,
the
PR
that
to
here's
kind
of
picking
out
that
already
contains
that
callback
and
I
think
this
is
part
of
the
convert.
This
was
the
conversation
that
spawned
from
the
other,
a
SGI
conversation
to
include
a
similar
mechanism
in
whisky,
by
which
then
we
could
actually
probably
potentially
simplify
or
eliminate
a
lot
of
the
custom
and
instrumentation
code
in
favor
of
just
wrapping.
The
app
via
whiskey
and
then
passing
in
the
appropriate
callback
to
set
the
span
name.
H
So
this
is
I,
guess
my
point
as
a
submarine.
This
is
valuable
work
that
needs
to
be
done.
I
do
think
this
is
probably
just
one
of
the
situations
where
we,
if
someone
could
pick
it
up
and
clean
it
up
and
we
could
probably
get
it
merged
in
pretty
quick,
but
I.
Think
yes,
kinas
is
on
to
other
things
right
now,.
H
H
J
Okay,
all
I
mean
I
can
being
that
I
just
took
of
any
other
PR
I
could
finish
this
because
I
think
it's
it's
similar
ideas
right.
So
I
can
look
at
this
next
awesome.
A
This
one
is
around
the
testbed
for
Oh
tell
shrim
yeah.
This
has
been
kind
of
sitting
around
for
a
long
time
and
I
know.
Mauricio
is
not
gonna
do
any
work
on
it.
I
guess
I
could
speak
to
a
little
bit.
So
there's
there's
a
general
test
that
that
was
used
in
open
tracing
and
I.
Think
the
the
goal
here
was
to
reuse
the
same
test,
but
for
open,
telemetry
and
I.
Don't
know
how
out
of
date
this
work
is
I
know
feels
like
it's
probably
way
out
of
date.
A
H
B
H
H
B
F
H
Like
for
years
now,
so
I
guess,
if
I
aggressively
arrived
at
the
appropriate
specification,
haven't
really
done
a
lot
of
work
since
so,
oh
no
I
think
I
do
agree
with
your
point
Chris
that
if
we
are
gonna
do
this,
it
would
be
nice
to
pull
in
the
code
rather
than
check
in
the
source
code.
So
I
guess,
should
we
I
guess
I
mean?
Maybe
let's
do
the
reverse
here
right
if
we
close
this
or
probably
fairly
likely
to
never
cannot
revisit
this
for
the
foreseeable
future.
B
It
might
be
better
to
merge
it
as
us
than
to
wait
until
it's
perfect,
because
this
this
I
think
is
pretty
useful.
Even
if
we
don't
expect
the
open
tracing
spec
to
change
at
all.
It
would
be
great
to
prove
that,
like
changes
in
our
API,
don't
break
the
shim
in
ways
that
violate
the
open
tracing
spike.
H
A
A
B
H
B
B
B
The
stricter
rules
to
everything
you
have
runtime,
so
we
find
is
that,
like
a
lot
of
our
tests,
you
know
types
are
nana
cated
and
so
they
get
passed
through
as
like
any
or
object
or
where
we
have
annotations
we're
getting
them
from
like
we're
getting
them
from
Chora
library
files,
and
so
it
it
infers
the
type
shuttles
the
type
through
the
test
and
then
finds
out
that
it's
not
restrictive
an
appetite
yeah.
So
these
are
things
that
we
just
like.
We
could
never
catch
statically
right.
H
H
B
Super
competent
based
on
our
interns
productivity.
So
far,
maybe
one
of
them
could
do
it
in
two
days,
but
I
I
think
this.
This
one
has
the
potential
to
be
kind
of
a
tar
pit
like
it's
it's
hard
enough
working
with
my
bike
and
there
are
like
enough
weird
edge
cases
with
types
that
they
think
this
is
gonna
end
up
being
like
pretty
slow,
pretty
tedious
work.
H
H
B
A
H
True,
although
I
you
know
also
feel
like
well
yeah,
maybe
in
the
sense
that
it
partitions
the
work,
but
you
know
the
work
itself.
I
think
still
needs
to
be
done,
and
hopefully
we
can
provide
the
same
tool
and
validation
set
to
contribute
packages,
as
we
do
to
the
course
we're
gonna
just
enable
type
growth.
H
B
Yeah
I
decided
I
just
check
this
out.
It
looks
like,
besides
being
like
pretty
badly
out
of
sync
with
master
there's.
No
there's
no.
Like
current
reason.
This
couldn't
work
just
failing
on
some
unrelated
lint
problems
before
I
may
be
able
to
get
this
one.
Let
me
spend
like
15
minutes,
just
resolving
merge
conflicts
and
it
looks
like
I
can
get
this
a
chip.
I'll
just
put
a
book
here
today.
H
Okay,
I
think
that's
I'm,
sorry
I
didn't
get
through
that
whole
list.
There's
actually
a
couple
more.
If
we
have
more
time
the
last
ones
version
number
normalization
test,
255,
254
and
I
guess
what
I
was
gonna
say:
Chris
here
is
I
I
have
a
branch
that
I
guess.
You
know
I'm
sure.
We've
heard
the
story
allied
and
have
enough
time
to
actually
get
to
finish,
but
it's
basically
using
the
newer
version
of
pip.
That's
in
beta
right
now
and
I
work
and
I
have
gotten
it
to
work
with
tools.
H
B
H
A
B
A
G
H
I'm
hitting
I'm
having
an
issue
with
sorry
nuts,
a
little
bit
of
destruction
back
there
yeah
was,
he
gonna,
say
I'm,
pretty
close
to
this
one.
What
happened
here
is
that
the
docs
started
breaking
I,
think
because
of
its
inability
to
resolve
the
import
path
of
some
of
the
modules
or
some
of
the
art
classes,
when
I,
when
I'm
with
everything
around
so
I,
do
need
to
actually
get
that
done.
Once
that's
done,
this
build
will
pass
so
I,
just
I
have
been
starting
to
dig
in,
but
it's
a
pretty
deep
Sphinx
issue.
H
A
C
A
A
E
B
H
B
There
are
assumption
going
into
this,
isn't
like
the
majority
of
spans,
especially
if
people
aren't
doing
any
like
attribute.
Lunging
themselves
are
just
not
gonna
have
attributes
or
events.
So
that's
it's
a
shame
to
have
like
all
of
these
extra
allocations,
where
we're
not
actually
doing
anything
right.
H
H
B
A
A
A
A
A
H
Think
maybe
one
call-out
is
even
if
you're
not
an
approver
today
it
would
be
nice
to
kind
of
get
more
review
on
these
PRS
and
I.
Think
one
thing
to
call
out
is
that
like,
if
we
make
people
approvers
based
on
the
number
of
I,
think
PR
that
they've
actually
been
reviewing.
So
if
anyone
wants
to,
like
you
know,
become
an
approver,
it's
actually
not
super
hard.
You
just
have
to
go
review
a
lot
of
PRS
and
yeah,
give
it
a
nice
a
full
feedback.
H
C
B
H
What's
the
word
compliant
with
that
or
decide
what
we're
gonna
do
there
so
anyway
good
opportunity
there
for
those
who,
if
you
review
a
PR,
you
see
something
that's
kind
of
weird
they
say
well.
This
is
in
this
might
be
fun
to
have
a
spec
discussion
too,
especially
I
might
suggest
that
for
the
for
all
the
interns
who
I
think
you
have
a
little
bit
more
leeway
with
what
you
can
spend
your
time
on.
So
you
know,
I
would
suggest,
take
the
opportunity
right.