►
From YouTube: 2021-05-06 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
A
C
A
All
right,
I
guess
we
might
as
well,
might
as
well
get
started
here.
I
think
laden
said
he
was
out
today.
A
All
right
pretty
late
on
topics,
I
guess
we
can
pretty
much
dive
into
issues
almost
right
away
unless
someone
has
a
topic
that
they
want
to
bring
up.
That's
not
already
on
the
list
here,
but
just
wanted
to
call
out
that
the
next
release
is
going
to
be
out
on
tuesday.
So
we
decided
last
thing
that
we're
going
to
be
releasing
the
first
tuesday
of
every
month.
A
I'm
aware
that
next
tuesday
is
not
the
first
tuesday
of
may,
but
the
last
release
was
a
little
bit
too
close
to
the
first
tuesday
of
may.
So
we
decided
to
do
the
release
next
tuesday.
Instead,
all
right
does
anybody
else,
have
any
other
topics,
or
should
we
move
right
into
issues.
A
B
That
requires
lightning
yeah,
pretty
much.
That
was
an
issue
that
later
mentioned,
that
it
asked
me
just
to
open
the
issue
for
himself.
It
is
about.
B
Yeah,
of
course,
deciding
how
to
version
the.
B
Maybe
we
can
discuss
this.
I
can
think
later
on
that
issue
and
see
if
we
can
move
on
this
discussion,
because
I
don't
think
there's
much
to
say
right
now
without
his
input.
A
Okay
yeah,
I
guess
the
only
comment
I'll
make
here
is.
If
this
turns
out
to
be
better
for
a
discussion,
then
maybe
we
can
close
this
issue
and
open
up
a
github
discussion
or
whatever
it
doesn't.
Look
like
there's
a
lot
of
enough
context
in
here.
So.
B
Right,
yeah
I'll,
open
him
and
I'll
also
let
you
know
that
this
might
belong
into
the
discussion,
cool.
B
Oh
yeah,
that
was
fine.
Yes,
so
I've
been
working
on
this
code,
cleanup
that
was
included
in
fpr.
B
B
So
I
think
this
issue
and
this
pir
we
can
close
right
now,
because
they're
gonna
of
being
superseded
by
this
other
one.
B
Since
this
was
already
discussing
the
sign,
there's
not
much
enthusiasm,
breaking
everything.
A
A
A
B
Yeah,
well,
that
script
is
what
it
does
is
the
it
compares
the
actual
branch
against
the
main
branch
and
it
finds
any
public
symbol,
that's
being
added,
so
it
kind
of
tells
the
user
hey.
This
is
being
added
so
make
sure
that
it's
strictly
necessary
to
add
these
public
symbols,
if
not,
please
prefix
them
with
the
underscore
right,
so
that
we
can
keep
our
public
symbols
minimal
a
way.
B
Making
this
ci
action
that
includes
this
result
from
the
script
in
the
epr's
comments,
so
that
reviewers
can
easily
see
what's
being
added,
and
so
they
can
be
sure
that
we're
not
adding
anything,
that's
not
necessary.
So
I'm
already
working
on
that
learning
about.
D
B
I
don't
know
if
you
want
this
script
to
be
added
first
and
then
the
cia
integration
to
be
added
later.
What
did
I
say.
A
B
Yeah,
I
don't
think
it's
the
same,
because
there's
a
lot
of
value
into
adding
the
github
actions,
that's
pretty
much.
It.
A
D
Away
yeah,
so
this
is
about
the
b3
probability
implementation.
So
the
spec
suggests
that
hotel
propagators
anywhere
should
accept
b3
and
b3
multi,
and
so
they
work
slightly
differently.
B3
is
supposed
to
inject
a
single
header.
Very
much
like
jsw36,
trace
context
and
b3
is
supposed
to
inject
multiple
errors.
So,
basically,
what
we
have
today
is
b3
multi,
but
we
call
it
b3
and
we
don't
have
anything
from
for
b3
multi.
D
So
so
this
doesn't
comply
with
the
spec
and
it
would
be
a
breaking
change
to
fix
this.
But
I
think
this
is
it.
We
can
consider
this
as
a
bug
but
happy
to
hear
other
thoughts.
So
so
I
was
thinking
we
can
implement
two
new
classes,
b3
single
format
and
b3
multiformat,
and
then
the
current
b3
format
will
be
just
an
alias
to
b3
multi
format.
So
the
current
b3
format
class
won't
change
behavior
and
we
can
add
a
deprecation
notice
to
it.
D
A
I
feel
like
I'm,
I'm
personally,
okay
with
calling
this
a
bug
and
I'm
fixing
it
as
described
here.
That
seems
like
the
right
the
right
way
to
approach
it.
A
Guess
so
we
just
have
to
be
yeah.
I
guess
we
have
to
determine
if
this
is.
D
Yeah
in
terms
of
like
in
terms
of
looking
at
it
as
a
bug
in
code
bug
is
only
that,
like
it's
a
one-line
bug,
we
can
consider
them
online
bug
in
setup.cfg,
where
we
mentioned
the
entry
points.
So
instead
of
b3,
we
should
have
b3
multi
there.
So
that's
the
best
android
bug
we
have
like
technically.
C
A
And
yeah,
I
guess
it'll
be
just
good
to
call
out
the
changing
behavior
and
the
change
log.
I
don't
know
if
we
want
to
like
highlight
those
changing
behaviors
differently
and
a
change
log,
but
that
might
be
something
we.
A
A
D
So
I'm
not
sure
exactly
how
ascii
works,
but
I
think
that
the
issue
here
is
ascii
will
establish
a
single
connection,
much
like
grpc
streams
and
then
a
connection
will
receive
multiple
messages
from
clients
and
the
server
will
respond
with
multiple
responses,
so
so
so
the
so.
I
think
what
laden
was
asking
was
if
one
response
has
an
error-
let's
say
a
500
error
or
some
400
error
should
that
propagate
up
to
the
parent
span,
which
represents
the
connection.
D
My
instinct
is
that
it
should
not,
but
but
I'm
not,
I'm
not
sure.
I
understand
this
the
flow
here,
the
working
model
correctly,
so
I
don't
have
a
definite
answer,
but
but
as
far
as
I've
seen,
I
don't
think
individual
message
should
the
status
should
propagate
up
the
chain.
A
B
A
D
Yeah
we
wouldn't,
but
I
don't
think
this
really
maps
too,
but
yeah,
I
don't
think
maps
to
produce
a
consumer
in
that
sense,
yeah
it's
like
a
channel
is
established
and
then
a
client
sends
a
request
on
that.
Multiple
requests
on
that
channel
and
gets
multiple
responses
for
each
request.
So
some.
D
D
No
in
as
far
as
I've
seen
as
far
as
I've
looked
at
the
instrumentation,
it
seems
there's
a
single
parent
span
for
the
entire
channel,
the
connection
and
then
all
the
message
sent
to
and
fro
between
the
client
and.
B
A
D
Yeah,
that's
my
instinct
as
well
and
maybe
for
parent-child
relationship.
The
the
response
should
maybe
use
the
the
request
as
its
parent
instead
of
the
channel,
maybe
not
sure
yeah.
A
A
Okay,
I
guess
what
was
his
ask.
D
Here
maybe
we
should
move
this
to
next
week
when
dating
is
here
and
I'll.
Also
try
to
study
this
instrumentation
and
see
like
try
to
understand
how
it
works
exactly.
A
All
right,
moving
on
to
the
next
issue.
D
Yeah,
so
this
is
my
colleague
jaku:
he
wasn't
able
to
join
the
sig,
so
I'll
be
filling
in
for
him,
so
this
pr
basically
implements
a
context.
Propagation
for
lambda
invokes
using
the
boto
library
so
instead
of
invoking
lambda
through
http,
if
you
use
the
aws
sdk
it,
it
does
not
propagate
context
today
and
this
pr
is
implementing
that
so
one
one
weird
thing
about
this
is
that
the
aws
sdk
user
facing
function.
It
accepts
the
message
payload
as
a
json
string
like
a
formatted
json
string,
so
to
inject
contracts
into
that.
D
We
need
to
parse,
it
then
inject
and
then
like
dump
it
again.
So
that's
a
bit
strange
compared
to
other
instrumentations,
but
I
don't
see
a
way
around
it.
Yes,
yoko
tried
to
implement
some
custom
string
parsing
and
it
was
working,
but
the
code
was
quite
complex
and
the
performance
benefits
are
not
that
huge.
A
D
Yeah,
just
someone
someone
has
to
take
a
look.
D
Yes,
yeah
so
same
thing
here:
eliten
had
some
concerns
last
week,
but
he
approved
it
and
we
discussed
it
a
bit
on
slack.
So
just
need
another
reviewer.
If
we
can
get
that
before
the
release,
that'll
be.
A
C
Could
I
ask
you
a
real
quick
question
in
the
previous
one?
Sorry
I
was,
I
wasn't
paying
total
attention
before.
Oh
does
this
one
use
the
extra
requires,
or
is
it
using
different?
Is
it
just
not
doing
that
like?
Could
you
give
a
overview.
D
Yeah
so
this
uses
extra
requires
and
that
enables
what
you
had
requested,
that
people
can
mention
extra
requests
with
paper,
regardment.txt
and
then
they'll
get
install
time
checks,
but
in
addition
that
this
also
implements
runtime
checks.
So
if
you
don't
install
with
extra
requires,
then
this
will
check
at
runtime
like
confirm
the
versions
issue
awarding
if
you're
using
it
for
the
wrong
language.