►
From YouTube: 2021-06-10 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
Time
no
hear
you
yeah
yeah,
I
kept
taking
like
the
end
of
the
week
off
and
then
I
always
miss
thursday
because
of
that
sorry
come
on,
oh
hold
on
a
sec.
Sorry,
sorry,
my
air
conditioner
was
on
I
kept
taking
like
like
thursday
off
and
then
I
kept
missing
the
meeting.
A
C
C
A
More
abstraction
I
mean
programming
is
so
crazy.
Like
you
you,
it
is.
C
Like
we,
we
just
move
in
up
and
down
multiverses,
where
multiverse
is
more
or
less
abstract
than
the
other
yeah
yeah.
That's
our
superpower
that
we
have
programmers.
We
can
travel
the
abstraction.
A
D
I
just
decided
so
yeah.
Why
not.
G
C
Oh,
we
have
someone
new,
we
know
the
video
welcome.
G
G
B
C
D
G
G
All
right,
so
shrikant
is
not
here
to
talk
about
the
blogs,
so
that's
I
will
put
that
down
below.
I'm
not
sure.
If
he's
gonna
attempt
it
or
not,
but
diego,
do
you
want
to
talk
about
the
ego
iron
app,
sorry
iron?
I
saved
you.
G
G
Here,
do
you
wanna,
do
you
wanna
take
over
all
right,
you
can
you
can
drive
my
screen.
C
I
guess
that
means
everybody
can
see.
My
screen.
C
All
right,
yes,
so
laden
asked
me
to
make
this
pr
something
that
will
be
merging
to
the
metrics
branch
instead
of
main,
which
makes
sense
right,
just
as
scant
is
doing
the
same
with
logs
branch
I
tried
doing
so,
but
I'm
not
sure
I
did
the
right
thing.
I
pretty
much
rebased
the
old
metrics
branch
against
name
fixes
like
two
or
three
conflicts
and
then
rebased
my
branch
against
that
newly
rebased
metric
branch.
C
Github
still
says
that
I
want
to
merge
commits
into
maine,
maybe
because
these
metrics
branch
is
now
based
on
me.
I
just
wanted
to
let
you
know
what's
going
on,
so
you
understand
why
I
have
like
92
changed
files
here
with
a
bunch
of
all
codes,
so
so
that
I'm
pretty
much
what
I'm
doing.
C
Is
actually
fixing
lint?
Of
course,
I
have
like
a
lot
of
errors
that
are
showing
up,
because
I
am
replacing
lots
of
instruments
with
the
new
version,
so
links
complaining
about
stuff
that
no
longer
exists
but
still
being
imported
everywhere.
C
Anyway,
I
have,
let's
see
if
it's
there
here,
grocery
yeah
the
plan
we
decided
last
six
was
to
do
the
opposite
of,
what's
usually
done
when
it
comes
to
software
development
and
start
developing
the
examples.
First
then,
the
sdk
and
finally
api.
So
I
try
doing
so.
I
have
this
grocery
example
that
that
attempts
to
be
an
implementation
of
one
of
the
scenarios
described
in
one
of
the
eltabs.
C
This
grocery
scenario
was
something
that
I
asked
riley
to
take
a
look
at
riley.
Put
this
comment
here.
C
I'm
not
sure
this
comment
to
related.
I
mean
it's
pretty
much
just
about
the
implementation
of
this
example,
not
much
information
here
anyway.
Here's
the
example
you'll
see
that
should
look
similar
to
what
we
had
before
instruments
now
have
our
names,
guess
that,
once
that
I
clean
up
all
the
mess
that
the
releasing
of
branches
will
also
go
back
into
implementing
things
to
make.
This
work
looks
pretty
straightforward,
but
you
know
how
things
that
look
straightforward.
C
D
C
B
Come
on
nice,
could
you
so
I
I've
been
following
like
the
actual
metrics
back
and
with
like
the
api?
Rework
I'm
curious
like
what's
what's
actually
different,
because
as
far
as
I
could
tell,
it
should
basically
just
be
a
few
instrument.
Names
are
different,
like
I
think
we
have.
The
async
versions
are
called
something
funk
instead
of
like.
B
C
The
previous
implementation
included
bound
instruments.
I
think
that
idea
of
bound
instruments
is
gone
now,
so
no
more
bound
instruments.
Something
else
that's
different
in
this
implementation
is
the
fact
that
we
are
using
multiple
inheritance
see
if
I
can
find.
I
If
they're
not
doing
bound
instruments
anymore,
is
there
a
new
mechanism
in
how
to
record
with
different
labels.
C
Not
sure
is
it
an
excellent
question?
Actually,
what's
gonna
replace
down
instrument
hello
later
by
the
way
hi?
How
are
you
yeah
so
good
question?
Now
I
I
guess
sooner
or
later
I'll
realize
the
web
is
supposed
to
replace
boundlessness
as
implementing
this,
because
yeah,
it's
a
legitimate
need
right
to
have.
C
B
Ahead
so
I
was
just
gonna
ask.
I
think
I
think
there
may
be
a
chance
that
the
found
instrument
thing
comes
back
just
based
on
what
I've
seen
in
like
the
chats
right
now
on
slack.
But
do
you
think
it'd
be
easy
to
like
add
that
back
in
based
on
this.
A
D
C
Yeah
yeah
sure,
that's
everything
that
leno
has
said
is
true,
also
if
the
bound
instruments
come
back
in
a
way
that
closely
at
least
closely
resembles
the
previous
bound
instruments,
and
with
that
I
mean
implemented
as
specific
classes
like
they
were
before
they
could
fit
the
the
hierarchy
of
classes
that
we
have
defined
now,
because
actually,
this
idea
of
classes
I
had
it
before
when
we
had
bound
instruments,
so
these
tables,
I
I
wrote
disabled
so
that
I
could
easily.
C
Understand
how
the
classes
were
related
right,
so
previously
we
had
bound
instruments
like
in
this
last
table
here,
so
what
we
can
do
is
create
a
class
named
bound
and
sorry
unbound,
another
bound
and
just
add
it
to
the
basis
class
of
these
counterbalance
counter
classes
that
may
show
up
later,
so
I
think
it'll
be
easy
to
integrate
them
if
they
follow
a
similar
implementation.
Like
this.
C
I
Yeah
so
great
stuff
that
you're
doing
by
the
way,
thanks
for
taking
up
all
this
work,
thank
you.
I
have
a
question
on
like.
Is
there
any
asks
from
us
as
a
python
community,
like
you're
kind
of
just
spearheading
this
and
like
being
the
bridge
with
like
the
metric
sig?
Is
there
some
sort
of,
I
guess
timeline
or,
like
you
know
what
what
is
like
the
criteria
for
success?
I
Really,
because
we're
not
really
going
to
review
this
right,
like
as
a
as
a
normal
pr
yeah
as
per
say,
like
we're
kind
of
just
waiting
on
like
whether
or
not
an
sdk
specs
is
gonna
come
out
right
so
is
there?
Is
there
any
asks
from
us
until
that
happens
or
like?
Are
you
working
closely
with
riley
to
push
an
sdk
spec
out?
What's
the
kind
of
status
on
that?
Do
you
think.
C
Well,
actually,.
C
That
much
contact
with
riley
in
the
past
few
days,
because
I've
been
pretty
much
just
trying
to
fix
this
mess
up
of
updating
this
with
the
metrics
branch
and
stuff.
But
I'll.
Take
that
as
as
homework
to
contact
riley
and
see
if
there
is
any
more
progress
or
definitions.
C
Already
in
the
summer
specification
so
that
we
know
about
that
and
we
can
driver
prototype
in
that
direction
right.
So
if
there's
something
else
I'll,
let
I'll
find
out
and
then
I'll
put
a
message
in
our
slack
channel
like
with
a
summary
of
what's
going
on
in
the
metrics
website,
so
that
you
guys
are
informed.
I
B
C
I
will
hate
you
or
anyone
for
reviews
right
now,
because
it's
a
complete
mess,
so
I
don't
want
to
waste
your
time.
Let
me
at
least
make
lint
pass
because
I
have
hundreds
of
linters,
so
this
pretty
much.
It's
not
worth
the
your
time
right
now
to
review
this
so,
but
once
it
is
I'll,
put
I'll
put
a
message
in
the
slack
channel,
I
guess
asking
for
reviews
once
that
I
think
it's
appropriate,
for
you
awesome.
Take
a
look.
C
Yeah,
I
think
you
may
have
missed
that
part
of
the
conversation
sincerely.
I
tried
to
do
so.
I
rebased
the
old
metrics
branch
against
maine
solve
the
conflicts.
Then
I
rebased
my
branch
against
that
new
metrics
branch.
C
This
github
still
says
that
I'm
trying
to
merge
into
main.
I
guess
because
this
is
on
top
of
a
branch
that
is
on
top
of
me.
C
C
Yeah
because
the
metrics
branch
was
like
70
commits
behind
maine
right
yeah,
so
I
didn't
want
to
use
this
the
matrix
branch
as
it
was
because
it
had
a
lot
of
different
stuff
like
that.
So
I
tried
to
first
reverse.
D
I
C
C
C
The
main
I
mean
all
these
non-metrics
stuff
related
things,
but
so
that's
why
I
rebased
it
against
me.
I
see
yeah.
Hopefully
that
was
a
good
idea,
yeah
cool,
so
so
yeah.
That's
that's
why
it
still
says
maine
but
but
yeah.
I
definitely
try
to
do
what
you
ask
later.
C
D
Move
on
sure,
let's
move
on
I'll,
stop
sharing
and
keep
this.
I
I
G
D
G
A
drop
for
another
another
pizza,
but
as
well
so
yeah
very.
I
Exciting
yeah,
if
you're
pretty
interested
in,
what's
it
called
like
the
prototyping
of
this
oh
yeah
this
this
so
the
the
idea
behind
this
is
to
like
it
was
asked
of
the
python
or
not
asked,
but
we
volunteered
as
like
you
know,
to
prototype
out
what
python
would
look
like
in
terms
of
the
logging
sdk.
So
this
is
like
we'll
be
sparking
discussion
and
driving
the
design
of
what
the
community
would
be
talking
about
similar
to
what
metrics
is
doing.
So
this
is
not
as
well
defined
as
tracing.
I
So
that's
keep
in
mind
that
that's
the
goal
right
now.
So,
if
you
guys
want
any
like
want
to
impact
it
in
any
way
like
now's
the
time
to
like
you
know,
put
your
two
cents
in
so
yeah
we're
we're
a
bunch
of
python
ears,
yeah
for
open
telemetry.
I
Also,
let
me
share
my
screen
real
quick.
Are
you
guys
have
you
guys
ever
seen
this
thing
right
here?
B
I'm
guessing
it's
for
like
examples
or
something
where
we
have
like
a
requirements
file
because
yeah
it's
for
that's
her
fast
api.
If
you.
G
B
G
I
G
I
G
Take
a
look
at
it
again,
yeah
because.
F
G
I
Get
all
of
this
in
I
have.
I
Yeah,
it's
it's
just
being
spec
compliant
pretty
much.
We
needed
a
createkey
function
for
our
context
classes
and
we
just
never
had
that.
So
it
was
a
point
of
contention
really
for
some
cases,
because
we
were
what
was
it
for
the
h2
was
the
suppress
instrumentation
uses,
the
you
know.
We
were
using.
E
I
Before
yeah,
so
it
would
have
been
breaking
so
we
had
to
kind
of
like
do
some
little
hacky
stuff
to
work
around
that
a
hacky
thing.
So.
I
Sorry
yeah
we're
we're
moving
we're
having
like
a
global
defined,
suppress,
instrumentation
key
and
putting
it
in.
I
believe
the
instrumentation
repo
for
now,
because
I
think
they're
still
deciding
on
how
in
the
specs
on
a
mechanism
and
to
do
suppressed
instrumentation
properly.
I
I
Easy
change
but
yeah
we
had
this
kind
of
breaking
api
contention.
So
that's
why
the
pr
has
been
open
for
a
bit.
So
then.
I
Get
that
constant,
okay,
yeah!
That
was
like
the
point
of
contention,
so
yeah,
but
as
long
as
we're
aware
of
it,
and
we
have
paths
to
migrate
away
from
it,
yeah
we're
good
yeah
cool
yeah.
I
I
opened
a
pr
yesterday,
there's
a
recent
change
in
the
specs
to
add
some
sort
of
priority
ordering
in
terms
of
setting
the
status.
It's
pretty
straightforward.
Basically,
like
you
know,
if,
if
if
the
span
status
is
set
to
okay,
any
proceeding
setting
to
unset
or
errors
would
be
ignored.
I
They
didn't
want
any
other
instrumentation
setting
it
back
to
error
or
something.
So
that's
pretty
much
addressing
that
issue.
I
already
have
an
approval
for
it.
If
someone
can
take
a
look
at
this,
that'd
be
great.
It's
very.
C
Later
I
took
a
look
at
that
looked
fine,
I
I
just
went
I'm
not
sure
if
this
is
an
issue
or
not,
because
I
didn't
check
that
logic
too
thoroughly,
but
is
this?
I
Oh
unset
is
always
ignored,
so
nothing
can
be
overwritten
with
unsaid,
okay,.
D
C
Yeah,
I
just
wanted
to
make
sure
that
these
changes
follow
that
ordering
right
yeah
that
we're
doing
the
including
error,
because
I
think
error
is
not
mentioned
in
this
pr.
But
maybe
the
logic
is
not
as
it
is
to
handle
things
as
expected,
but
yeah.
I
Yeah,
it's
it's
not
so
much
sorry,
maybe
maybe
this
this
kind
of
relation
is
kind
of
confusing.
It's
not
so
much
like
you
know.
Only
error
can
set.
Oh
sorry,
only
okay
can
sit
air
and
eric
can
set
on
set.
It's
just
two
things
once
someone
says
it
to
okay,
they
cannot
override
it
with
anything,
and
originally
there
was
always
the
thing
where
it's
nobody
can
actually
set
it
to
unset.
That's
that's
it.
It
just
so
happens
that
that's
that's
how
the
priority
looks
like
yeah.
I
Don't
don't
think
too
hard
about
that?
It's
if
you
look
at
the
logic,
you'll
be
very
straightforward.
All
right,
yeah,
there's
nothing
complicated
about
yeah
cool
yeah,
moving
right
along.
D
I
C
C
What
it
adds
is
a
mixing
class
that
can
be
used
to
transform
a
test
case
into
something
that
also
supports
a
context
for
to
make
sure
that
exceptions
are
not
being
raised.
I
have
seen
many
times
that
we
write
these
cases
where
we
just
right
at
this
case
and
put
some
code
in
it,
and
what
we're
trying
to
do
in
these
situations
is
to
make
sure
that
no
exceptions
are
raised
now.
C
The
right
way
of
doing
that
is
by
putting
all
the
code
inside
a
try,
accept
block,
as
it
is
here
scroll
down
a
little
bit.
Please
no,
no
scroll,
sorry,
scroll
up
to
implementation,
where
it
says
fail,
yeah,
rather
self
test
case
failure
line
30.
I
think
so.
C
The
the
unit
test
test
case
class
includes
this
method,
name
fail
that
fails
at
this
case,
so
when,
when
executed,
so
the
right
way
of
making
sure
that
no
exception
is
raised
is
by
yes,
I
was
only
putting
everything
to
a
tri-x
block
and
in
the
accept
catch
an
exception
and
and
call
cell
fail,
because
that
will
give
an
assertion
error
instead
of
any
other
error,
which
is
what
we're
trying
to
test
right.
When
we
try
to
do
something,
it
must
fail
with
an
instruction
error.
C
If
that
that
we
were
trying
to
test
it's
not
happening.
So.
To
avoid
that,
I
created
this
mixing
that
it's
to
use
it,
it's
very
easy
to
use.
You
can
scroll
down
release
this.
D
This
yes,
okay
in
line
scroll
up
a
little
bit,
yeah.
C
C
If
so,
I
want
to
explain
this
because
it
it
has
nothing
to
do
with
open
telemetry,
it's
just
a
utility
and
it
also
modifies
the
toxini
so
that
we
now
test
our
testing
utilities.
C
G
G
I'm
I'm
curious,
I
is
there
a
reason
why
you
didn't
add
changes
for
where
this
would
be
used
in
the
code
as
part
of
this
pr.
C
That's
a
great
question:
yes,
I
should
have
done
so.
Probably
I
should
have
where
I
could
go
through
all
the
test
cases
that
we
have
and
use
this
yeah.
I
I
forgot
to
do
it.
I
was
because
I
wrote
this
pr
to
test
some
stuff
that
I
was
writing
in
the
prototype,
so
I
was
expecting
to
use
it
in
the
prototype,
but
yeah,
that's
a
good!
That's
a
completely
valid
point.
I
could
be
using
this
already
yeah
yeah.
I
can.
I
can
add
those
changes
to
this
pr.
I
Yeah,
if
you
were
a
place
everywhere
where
we
actually
need
the
assert
not
raises,
then
that
would
be
like
the
ultimate
test.
Suite
right,
that'd
be
pretty
good.
B
C
I
And
maybe
you
can
like
point
out
an
example
of
a
test
case
that
you
would
replace
this
for
and
it'll
be
easier
to
compare.
C
Let
me
see
if
I
can
find
one
just
if
you
find
any
test
case
that
does
not
include
an
assert.
That's
the
test
case.
I'm
talking
about.
H
C
Oh
no
that'll
be
hard
to
find
right
now,
but,
okay,
what
I
mean
is
this:
the
a
test
case
should
always
include
an
assertion,
because
that's
what
tells
you
what
is
actually
being
tested
a
test
case
that
does
not
include
an
assertion
is
not
testing
anything.
C
So
it
is
not
the
same
thing
when
a
test
case
fails
because
an
assertion
error
was
raised
compared
to
a
test
case
that
fails
because
any
other
kind
of
assertion
was
raised
when
a
test
case
fails
because
an
assertion
error
was
raised.
That
means
that
this
case
did
its
job.
It
managed
to
test
what
you
wanted
to
test,
but
if
it's
raising
any
other
kind
of
exception
it
may
it
means
that
what
you
wanted
to
test
was
not.
C
You
were
not
able
to
test
what
you
wanted,
because
it
failed
before
for
some
other
reason.
So
that's
why
the
assertion
error
exception
exists
in
python,
it's
a
specific
exception.
That
tells
you
your
test
case
failed
and
ideally,
if
a
test
case
fails,
it
should
always
be
with
an
assertion
error.
If
it's
failing
with
any
other
exception,
then
you
need
to
test
run
fix
something
in
the
setup
of
the
test
case
and
run
that
test
case
again,
because
you
don't
have
certainty
that
you
were
able
to
test
what
you
wanted
to
test.
C
So
if
you
write
at
this
case-
and
you
don't
you
just
put
some
code
in
it
and.
C
What
you
are
trying
to
test
is
that
no
exception
is
being
raised,
then
by
not
putting
it
into
this.
Try
accept
and
self-fail
structure,
then
you're
not
making
it
possible
to
understand.
What
is
that
you
are
wanting
to
test
when
you
read
the
test
case,
because
it's
just
a
bunch
of
code,
nothing
is
being
tested.
So
that's
the
difference
and
that's
why
this
is
necessary
so
that
you
can
tell.
B
What
is
okay,
so
it's
mainly
like
a
semantic.
You
want
to
make
the
test
semantically
more
clear
and
then
the
test
output,
gotcha.
Okay,
then
I
I
guess,
I'm
like
I
understand.
Okay,
that
makes
sense
to
me.
I
think,
there's
also
already
in
like
the
testing
module
in,
like
a
test
case,
module
or
tesca's
class
assert
raises,
which
I
think
you
give
it
like
a
function
to
run.
B
So
it's
not
a
context
manager,
and
I
don't
know
if
it's
available
in
all
the
versions
of
python
we
support.
I
know
a
serratuses
is
a
contact.
B
C
Well,
what
happens?
Sorry,
I
was
mistaken
you're
right,
but
as
a
services
is
also
a
context
manager.
Can
you
please
show
yeah
this
link
that
I'm
sharing
in
the
chat?
A
third
phrases
works
both
ways.
It
is
a
context
manager
and
it
also
may
receive
a
call
okay,
but
there's
nothing.
C
C
B
All
right
well,
then,
one
more
quick
question
in
terms
of
like
the
implementation.
Could
it
is
there
a
reason
it
couldn't
just
be
like
a
mix
in
and
then
directly
on
the
mixing
class?
There's
you
have
that
context
manager
as
a
function
where,
where
it's
like
you
know,
you
can
use
the
context
manager
decorators
that
you
can
transform
like
a
try,
catch
or
try
accept
into
you
know,
I'm
talking
about
like
the
context
miniature
decorator.
B
No,
no,
I
just
mean
in
terms
of
the
implementation
like
it
looks,
a
little
complicated
and
I
think
I'm
missing
the
reason
why,
like
for
the
for
the
mix,
the
actual
actual
code
for
a
star
not
raise
this
mix
in
like
is
there
any
reason?
It
couldn't
just
be
like
a
self
method,
like
a
class
method
to
do
the
assertion.
C
Yeah
but
sorry
what
you
find
it
complicated
is
the
usage
of
a
mixer.
B
B
No,
I'm
at
the
implementation
of
the
nixon
so
like,
instead
of
like
here
on
20
having
this
class,
you
could
just
have
like
a
death
with
not
raises,
and
then
that
would
be
its
own
context
manager
function.
So
then,
when
you
use
the
mixing,
you
don't
have
to
have
like
this
in
it
and
all
that
stuff.
You
just
have
like
a
new
assertion
method,
essentially.
C
B
I
Cool
yup,
I
think
that's
all
the
topics
we
have
for
today
does
anyone
else
have
anything
else.
They
want
to
talk
about
a
ring
up.
I
All
right,
if
not
get
15,
minutes,
mac
I'll,
see
you
guys
next
week.
Thank
you.
E
I
well
no,
I
I
I
didn't
really
wanted
to
like
raise
the
pr
that
I
I
raised
up,
because
I
wasn't
really
sure
what
was
the
process
for
you
know,
raising
these
vrs
and
then
getting
them
reviewed.
But
it's
fine.
You
know
whenever
we
have
time,
hopefully
someone
could
take
a
look.
B
E
In
the
code
base
that
I'm
trying
to
instrument
with
this
instrument,
the
grpc
client
is
called
with
a
future.
In
order
to
like
you
know,
they
do
some
synchronous
things
and
then
there's
a
callback.
If
you
try
and
run
the
the
test
with
the
existing
instrumental
code,
it
would
just
fail
because
the
the
context
manager
is
used
twice.
E
The
context
manager
is
entered
during
the
synchronous
bit
and
then
during
the
callback
you'll
try
to
re-enter
the
exact
same
context
rather
than
recreate.
You
know
like
recreate
the
context
manager,
so
the
changes
I've
made
is
basically
just
to
use
things
like
start
span
and
use
span
and
just
like
re-enter
them
as
when
they
are
being
used.
E
G
Yeah,
I
think
so
sorry,
I'm
just
looking
at
this
pr.
For
the
first
time.
G
I
don't
know
if
any
of
our
resident
grpc
experts
have
any
any
thoughts
on
this
one,
maybe
aaron
or
or
diego.
B
I'm
a
grpc
expert,
it's
you
dude,
I
didn't
realize
yeah.
I
can
take
a
look
offline.
What
was
the
difference
between
the
use
span
and
just
the
wood
spin?
I
kind
of
missed
that.
E
The
span
in
width
span
so
yeah
I
mean,
if
you
use,
like
starters
current
span,
then
the
one
context
manager
has
been
created
and
that's
used.
But
then
during
the
callback.
If
you
try
to
reuse
that
same
re-enter
that
same
context,
it
would
fail
like,
for
you,
get
a
different
error.
If
you're
in
python,
three,
six
or
three
seven
or
something,
and
so
rather
than
returning.
B
E
Context
manager
that
is
used
with
once
you
just
return
the
span,
and
then
you
use
the
you
spend
twice
either
during
the
synchronous
bits
and
then
later
on
during
the
callback
you
use
the
u-span
again.
B
E
Yeah,
the
the
it's
it's
basically,
I
don't
think
the
the
stuff
with
the
guarded
span
in
the
imagination,
jrpc
actually
works
with
a
asynchronous
callback
yeah
it's
hard
to
trace,
because
then
I
went
back
and
it
all.
This
code
is
being
copied
from
open
senses
or
open
tracing
or
something
yeah.
B
E
I
know
it's
it's
the
bit
that
once
you
call
the
the
client
makes
a
grpc
call.
You
can
also
attach
some
callbacks
to
it
so
like
by
the
end
of
the
grpc
call.
You
would
do
something
else
and
in
the
past
they
would
just
attach
the
same
span
to
the
callback
and
then
reuse
that
context
in
the
callback
and
that's
where
the
problems
are.
B
Okay,
I
got
you
okay,
yeah.
I
can
review
this,
but
that
makes
sense
to
me.
G
Awesome
thanks
for
the
contribution
and
thanks
for
joining
this
meeting,
to
talk
about
it.
So
this
is
super
helpful.
E
I
did
not
know
what
was
like
the
standard
way
of
introducing
yourself
to
a
new
group
or
something-
and
I
thought
oh
I'll-
just
join
the
sig
meeting
and
show
my
face
and
let
people
know
I
have
like
some
bought
behind
this
whole
thing.
G
Alright
cool
anyone
else
have
any
other
topics.