►
From YouTube: 2022-03-17 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
Yeah,
I
feel,
like
everyone
fits
into
the
category
of
not
coming
today.
I
don't
know
where.
Normally
we
have
a
lot
more
people
at
this
point,
so
I
don't
know.
B
A
Yeah
it'll
be
a
short
meeting,
otherwise.
A
Anthony,
do
you
know
if
aaron's
gonna
be
able
to
make
it?
Should
we
wait
for
him?
I
haven't
heard
anything
from
him
one
way
or
the
other.
We
can
wait.
A
I
knew
that
okay.
A
Yeah,
that
is
the
if
I
were
putting
odds
on
it,
I
would
say
against
him
showing
up,
but
I
think
I
think
that
we
should
be
optimistic.
I
can
ping
him.
Actually,
let's
see,
if
he's
able
to
join.
A
Well,
I
doesn't
look
like
he's.
Notifications
are
disabled
for
him,
so
maybe
we
jump
into
this.
I
guess
we
can
kind
of
get
through
this
if
you
notice,
if
you
have
more
people,
but
I
don't
want
to
wait
too
much
longer
and
I
want
to
make
sure
we
respect
the
time
for
the
people
that
are
here.
So
let
me
pop
into
share
mode
cool
cool
yeah.
I
think
everyone's
already
added
the
social
attendees
list
for
agenda
items.
A
I
came
up
with
the
following:
anticipating
a
little
bit
larger
audience,
but
I
think
this
is
still
useful.
If
you
have
anything,
you
wanted
to
add
that
you
need
to
talk
about
or
questions.
Please
add
them
to
the
agenda,
we'll
open
it
up
at
the
floor
as
well.
At
the
end,
if
not
first
thing
was
just
some
pr's
that
needed
some
more
eyes
to
try
to
progress
certain
initiatives.
We
have
first
one
being
the
contrib
repo
needs.
I
think
one
more.
A
I
don't
know
if
it
technically
needs
one
more,
but
I
usually
try
to
wait
for
two
for
these
kinds
of
pr's,
but
I
think
this
qualifies
as
one
that
we
could
probably
merge
with
one.
But
if
you
have
eyes
in
time
I
guess
it's
really
more
for
disapprovers,
so
I
I
don't
know
if
that's
a
useful
callout,
but
the
other
two
are
pretty
good
callouts.
These
are
from
the
hotel
repository
and
I
think
we
would
definitely
love
some
eyes
on
these
here,
adding
the
metrics
as
a
global.
A
I
think
this
looks
good
sammy
came
up
with.
I
think
this
is
a
pretty
good
point
that
was
raised
that
doesn't
match
the
same
policy,
so
probably
need
to
address
that,
but
definitely
having
some
more
eyes
on
this.
This
is
some
good
code
as
well,
if
you're
interested
in
the
metrics
progression,
because
it
shows
an
implementation
of
the
metrics
sdk.
It's
a
you
know
at
the
root
level,
it's
a
no
op,
but
it
gives
you
guys
like
a
little
bit
of
understanding
like
callbacks,
that
kind
of
stuff.
A
So
if
you
are
looking
to
become
more
involved
in
the
project,
it's
a
good
one
to
review,
so
I
definitely
recommend
it.
I
think
it's
a
little
long,
but
it's
worth
it
anthony.
Can
this
comment
be
resolved,
or
should
I
just
let
it
be
for
now.
D
I
need
to
go
back
and
take
another
look
at
that.
I
think
it
can
probably
be
resolved,
but
I
haven't
validated
as
long
as
the
those
girl
routines
terminate
at
some
point,
though
yeah
we're
fine.
A
I
think
they
do
but
yeah
I'll
just
leave
it.
So
hey.
A
Hey
yeah
yeah.
I
was
just
kind
of
making
some
announcements
on
some
pr's
that
you
did
some
eyes
on
them.
One,
for
you
would
definitely
be
if
you
could
jump
in
to
the
contributing
po
and
look
at
this
one,
but
then
yeah.
I
was
trying
to
advertise
some
of
these
other
ones
aaron.
If
you
wanted
to
talk
a
little
about
this,
I
just
noticed
that
xam
posted
this
earlier
this
morning,
which
probably
needs
to
get
addressed.
Thoughts
on
that.
E
Yeah,
I
was
actually
not
sure
why
we
allow
a
panic
in
the
the
tracing
when
it
seems
like
there
is
a
convenient
way
to
not
panic
in
that
such
a
scenario.
A
Yeah,
so
this
was
something
that
josh
mcdonald
kind
of
came
up
with
back
in
the
day,
just
for
the
context
and
history
on
it
and
the
idea
being
that
you're
gonna
do
this
once
and
it's
gonna
be
at
the
start,
so
it's
gonna
be
early
in
the
execution
of
the
program.
Ideally,
and
what
could
happen
is
essentially,
you
could
have
two
separate
processes,
maybe
trying
to
reset
the
global,
the
global
tracer
provider,
and
so
what
you
don't
want
to
be
doing
is
essentially
recasting
the
exact
one.
A
Because
delegation,
I
think,
turns
into
an
infinite
loop,
and
so
I
think
that
you
wanted
to
communicate
that
by
panicking
originally,
and
so
I
think
josh
originally
came
up
that
with
that
that
logic
behind
it,
and
I
think
that,
given
it
was
so
early
in
the
execution,
it
seemed
reasonable
but
yeah
I
I
was
skeptical
as
well.
When
we
were
panicking
anytime,
I
see
a
panic
that
could
potentially
reach
the
user
space.
I
agree.
D
E
A
E
So
that's
what
that
line!
43
345
does
to
prevent
yeah.
A
And
that's
called
what
exam
is
saying
is
that
before,
instead
of
it
just
returning,
it
would
panic
and
tell
you
like?
No
that's
a
bad
idea,
but
to
anthony's
point.
He
is
entirely
right.
This
was
implemented
before
we
had
log
in
the
sdk.
Well,
yeah,
yeah
sdk
is
a
good
point
there,
because
this
is
still
in
the
api.
So
I
don't
know
if
we
want
to
be
do
we
have
a
logger.
I
guess.
E
Yeah
we
have
the
yeah
error.
A
A
A
I
think
that's
good.
I
would
recommend
doing
it
for
all
of
them,
though,
because
I
know
that
like
extends
pointing
out
here,
this
is
in
the
tracer
provider,
and
so,
if
we're
going
to
do
it,
I
would
want
to
do
it
for
all
of
them.
I
have
no
problem
getting
rid
of
a
panic
and
still
communicating
an
issue
to
a
user.
That
sounds
reasonable
to
me.
E
D
A
Sounds
good
to
me
yeah,
I
agree
cool
the
other
pr
I
wanted
to
kind
of
highlight.
Was
this
go
1.18,
another
good
one?
If
you're
new
to
the
project,
this
one's
a
lot
shorter
than
the
other
one
I
was
recommending
but
yeah
it
is.
A
I
think,
there's
some
questions
here.
They're
pretty,
I
don't
know
they
seem
superficial
in
many
ways
but
important.
I
don't
want
to
discredit
or
discount
any
of
that,
but
yeah.
So
it's
something
just
put
some
eyes
on.
It
also
will
help
you
understand
our
policies
around
versioning
for
the
go
system
in
the
project,
so.
D
A
D
One
to
the
contrib
list
that
could
use
reviews
the
x-ray
remote
sampler
implementation,
it's
on
the
opposite
end.
It
is
a
big
boy.
Unfortunately,
much
of
that
is
in
tests,
though
there's
there's
a
lot
of
like
test
documents.
D
A
Oh,
my
goodness,
okay,
I'm
trying
to
look
who
reviewed
this
maybe
make
a
recommendation
for
them
to
come.
Take
a
look
at
the
aws
one.
I
think.
A
All
right,
yeah,
all
right,
cool
yeah,
so
yeah,
perfect,
good
call
out.
I
I'm
not
gonna
lie.
That's
gonna
be
hard
for
me,
but
I
will
try
my
best,
but
yeah
definitely
for
people
on
the
call,
especially
people
new
to
the
project
like
this
is
a
really
great
way
to
get
involved
in
the
project
is
to
do.
Reviews
may
seem
like
adding
code
is
useful,
but
this
is
the
most
useful,
as
reviews.
A
Cool,
I
think
that's
it
for
top
level
pr's
that
needed
some
call-outs.
If
you
have
some
more,
please
add
them
and
we
can
kind
of
circle
back
on
them.
The
only
other
thing
that
I
had
as
an
agenda
item
was
talking
about
this
metrics
api.
I
see
josh's
on
the
call
which
is
probably
going
to
be
useful
in
this
discussion.
A
So
I
think
I
posted
a
recap
here.
It
sounded
like
bagman
was
really
interested
in
making
another
proposal
and
was
just
essentially
saying
that
he
was
trying
to
provide
some
feedback
here.
I
think
I
you
know.
A
And
maybe
that's
not
enough
context.
Sorry,
that's
a
very
continuation
of
people
who
have
contacts
so
maybe
for
people
on
the
call
that
haven't
seen
this.
Yet
one
of
the
things
is,
we
recently
put
out
a
new
metrics
api
and
it
has
a
little
bit
of
a
structural
difference.
A
One
of
the
structural
differences
is
that
we
try
to
group
instruments
and
not
necessarily
hide
them
but
put
more
structure
into
the
packaging
so
that
when
people
look
at
package
documentation,
it's
a
little
bit
easier
and
less
of
a
bloat
to
try
to
figure
out
what
they
need
to
be
doing.
That
was
a
lot
of
the
motivation.
A
lot
of
that
motivation
came
from
feedback
from
other
users
and
other
people
in
the
go
community.
A
A
So
in
this
situation,
situation
there's
an
option,
and
you
would
you
know,
prefer
that
to
be
in
a
single
package
and
one
of
the
things
we
came
to
a
conclusion
on
was
this
is
equivalent
to
what
we
just
moved
away
from,
and
that
was
this
flat
metrics
api
package,
maybe
with
some
changes
in
some
implementation
to
update
to
actually
meet
the
specification
in
many
ways.
A
But
I
think
that
this
structure
design
was
something
that
we
decided
we
didn't
want
to
do
and
after
seeing
that
there
was
a
lack
of
want
to
move
forward
and
make
a
proposal
for
an
alternate
api.
It
is,
I
think,
a
good
way
to
interpret
this
issue
as
just
saying
this
is
feedback
from
somebody
who's
using
it.
C
I
feel
obligated
to
speak.
I
feel
decision
fatigue
here
and
don't
have
enough
energy
to
mount
either
a
response
or
a
new
proposal.
C
A
Yeah-
and
I
appreciate
that
especially
coming
from
you-
josh
we've
been
in
this
conversation
for
years
now
so
yeah.
I
totally
understand
that
and
that's
kind
of
why
I
wanted
to
maybe
actually,
if
everyone's
okay
with
it,
I
think
I'm
going
to
reassign
this
to
myself
and
then
I
plan
to
just
respond
and
saying
that,
thank
you
for
the
feedback,
but
we're
going
to
keep
going
in
the
direction
that
we're
going.
A
I
think
that
there's
good
reason
to
do
that,
and
I
think
that
the
community
has
come
to
this
decision
and
there's
been
a
lot
of
voices
in
support
of
the
current
direction.
So
I
wanted
to
just
go
in
that
direction,
but
I
yeah,
I
also
don't
want
to
impose
on
people
who
have
already
put
in
a
lot
of
work
to
try
to
formulate
justification,
because
I
think
that
already
exists.
D
I
think
one
piece
of
meta
feedback
to
take
here
is
that
perhaps
we
did
not
well
document
the
decision
that
we
made.
I
know
that
the
issue
that
josh
created
that
outlines
the
packet
structure
options.
We
had
some
discussion
on
that
issue,
but
largely
we
discussed
it
in
this
sig
here
and
came
to
an
agreement
in
this
sig
and
and
then
went
off
and
implemented
it.
C
How
can
it
makes
me
feel
like
I'm
the
reason
that
we
have
this
because
out
of
two
choices
in
the
first
place,
I
just
chose
to
prototype
one
and
not
the
other,
mostly
because
it
was
different
than
what
we
had
already.
I
think
more
different,
the
one
bit
I
additionally
have
to
say
now
that
I've
thought
through
it
for
two
seconds:
it's
in
a
world
where
go
generics
exist.
C
A
Yeah
and
one
of
the
things
that
we
kind
of
talked
about
again
of
people
who
haven't
looked
at
the
global
package,
it's
worth
going
taking
a
look
is
there's
like
ways
to
abstract.
You
know
using
your
typing
system,
which
is
really
powerful
in
this
new
design,
where
aaron
was
essentially
able
to
take
an
existing
meter
provider
and
cast
it
or
a
meter,
I
think
and
cast
it
into
an
instrumentation
provider
or
an
instrument
provider
of
a
particular
type.
So
I
think
there's
a
lot
of
really
great
abstraction
that
comes
with
this.
A
This
design,
as
josh,
were
saying
that
is
not
included
in
the
southern
flat
design,
so
yeah,
I
I
think
yeah.
I
also
I
mean
I
hear
bogdan's
point
that,
like
this
isn't
yeah,
you
have
to
look
a
little
bit
more.
Maybe
I
I'm
not
exactly.
Maybe
I
don't
know.
I
think
that
maybe
this
is
just
coming
from
the
fact
that,
like
in
java,
this
is
not
how
they
structure
it,
but
I
I
I
don't
know.
E
So,
to
to
put
a
little
bit
of
burden
on
the
people
that
are
experienced
are
going
to
experience
churn
from
this,
because
this
is
making
changes
the
one.
The
thing
that
I
have
is
we
we
discussed
this
over
a
month
or
so
before
we
even
put
an
implementation
down.
E
It
seemed
like
what
is
our
expectation
as
people
contributing
this
code,
that
we
could
get
some
kind
of
approval
to
go
on
this,
like
if
I
heard
this
feedback
you
know
a
month
before
you
know
somewhere
at
the
very
beginning
of
this,
that
we
would
have
had
different
decisions
that
were
made
and
would
have
resulted
in
probably
a
different
api
layout.
E
But
you
know
there.
There
is
some
kind
of
timing
aspect
here
that
we
can't
get
around
right.
This
is
this
comes
from
the
fact
that
he's
going
to
see
a
bunch
of
change
that
happens
in
his
code
because
we
make
changes,
but
that's
a
little
late
in
the
feedback
cycle
to
to
make
considerable
changes
is
sort
of
what
I'm.
What
I
feel
like.
A
Yeah,
I
think
it's
late
in
the
feedback
cycle.
I
also
know
that
everyone's
kind
of
overloaded
and
most
so
probably
booked,
but
that
doesn't
necessarily
excuse
the
fact
that
it's
late,
I
I
think
that
it
it
more
so
comes
down
to
the
fact
that
our
communication
of
our
design
decisions
are.
They
exist.
A
They've
been
documented,
but
I
think
to
anthony's
point
like
they're
not
really
easy
to
find,
and
we
probably
could
have
done
a
better
job
at
that,
because
I
think
a
lot
of
the
issues
that
he
is
bringing
up
in
this
comments
like
we've
identified
and
we've
made
a
cohesive
decision
to
move
away
and,
like
you
know,
josh,
is
pointing
out
reasons
that
yeah.
I
was
pointing
out
reasons
like
structurally
why
we
want
to
go
into
different
directions.
So
I
I
think
it
would.
A
Probably
you
know,
as
anthony
was
saying
like
a
meta
feedback
and
something
that
especially,
I
feel
personally
as
a
maintainer
of
the
project,
to
try
to
do
better
in
the
future.
Is
communicating
these
things
or
documenting
them
and
making
sure
that
there's
a
record
that
we
can
have
pointed
to
you
know,
especially
when
somebody's
coming
back
with
a
criticism
or
a
feedback,
and
and
they
don't
know
that
we've
already
addressed
it
or
that
we've
already
identified
it
and
we've
come
to
a
decision
on
that.
A
Yeah,
so
I
think
that
that
being
said
like
we
do,
have
the
sdk
work
coming
up.
So
maybe
we
could
try
a
better
job
at
that
one.
It's
tough!
It's
an
open
source
project.
Sometimes
it's
not
even
people's
full-time
job,
so
you
know
like
we're
doing
our
best.
I
think
we
can
improve,
but
I
do
want
to
say,
like
we
are
doing
our
best.
A
Yeah
yeah,
I
agree,
I
don't
think
anybody's
trying
to
submit
something
that
would
make
it
worse.
So
that's
definitely
not
the
case
cool.
I
will
take
as
an
action
item
to
close
out
that
issue
and
to
try
to
follow
up
with
bogdan
and
communicate
this.
I
think
also
next
steps
forward
in
planning
out
the
sdk
work.
A
I
think
I'll
try
to
look
at
that
over
the
next
week
and
see
what
we
could
do
to
try
to
communicate
things
or
capture
these
things,
especially
kind
of
to
the
point
that
we
do
make
decisions
in
this
meeting
that
should
probably
be
captured
somewhere.
I
think
that's
something
we'd
be
better
off
with
that
addressed.
That's
the
end
of
the
agenda
items
that
we
had
listed.
I
want
to
open
it
up
in
case
anybody
else
had
agenda
items
they
wanted
to
talk
about
that
didn't
make
the
document.
A
Cool
no
big
deal
there.
I
think
this
is
probably
getting
close
to
wrapping
up.
I
know
that
there's
just
like
tons
of
work
to
do.
A
C
Oh
sure,
thank
you.
Well
there's
this
one
issue
open
that
was
about
multi-call,
back
multi-instrument
callbacks
and
to
me
it's
I
was.
I
wrote
it
to
kind
of
justify
the
work
being
done
here,
but
we
didn't
treat
it
as
a
blocking
issue
and
I
guess
that
leaves
us
in
a
little
bit
of
an
awkward
position.
So
I
know
you've
approved
it
already
so
tyler.
So
I
I
feel
like.
C
What
we
have
here
is
an
agreement,
perhaps
by
some
of
the
people
who
are
close
enough
and
interested
to
to
read
through
and
comment
that
what
we're
proposing
looks
like
a
nice
api
in
the
sense
that
you
end
up
having
the
same
interface
for
both
one
instrument
or
multi-instrument
callbacks
and.
C
The
priorities
like
saying
that
that's
confusing
to
have
two
different
kinds
of
thing,
and
I
don't
know
I'm
really
kind
of.
If
it's
not
blocking
it's
not
blocking,
I
don't.
I
don't
want
to
care
too
much
there,
but
that
we
could
presumably
resolve
that.
C
A
Cool
for
those
curious
in
the
pr
the
joshua
was
talking
about.
I
added
it
to
the
agenda
doc,
and
so
you
take
a
look
there
cool.
I
think,
with
that
we
can
move
on
if
there's
any
use
case
or
any
like
third-party
use
of
the
hotel.
Go
library
see
steve,
didn't
make
it
as
well
again.
D
A
That's
a
great
suggestion.
I
am
not
attending
the
eu
one,
I'm
looking
at
attending
the
us
one.
I
think
it's
in
detroit
or
something
like
that
in
october
right,
but
yeah,
the
eu
one
is
not
not
something
I'm
gonna
be
at.
A
D
How
that's
gonna
be
done,
I'm
not
positive!
How
that's
gonna
be
handled.
I
assume
it's
going
to
be
sort
of
simulcast
like
the
the
prior
ones
or
the
recent
ones
have
been,
but
I'm
not
positive.
A
That
being
said,
I
am
super
excited
well,
I'll,
be
honest,
like
the
only
reason
I
want
to
go
to
kubecon
in
the
us
is
to
hang
out
with
a
bunch
of
other
hotel
people
and
hopefully
end
users
as
well.
So
I
I
would
like
it
if
other
people
went,
you
know
not
to
just
you
know
twist
your
arm
or
anything
cool
awesome.
I
think,
with
that
we've
kind
of
touched
on
everything
we
want
to
talk
about.
A
I
want
to
again
be
respectful
people's
time
and
looks
like
we
get
a
half
hour
back,
which
I'm
excited
about.
There's
all
kinds
of
things
to
do
so,
yeah
thanks
again
for
joining,
really
appreciate
it,
and
thanks
again
for
all
the
work,
we'll
see
you
all
next
week
or
asynchronously
online.