►
From YouTube: 2020-09-23 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
C
C
Eunice
and
kelvin
are
you,
would
you
like
to
introduce.
D
Yourselves
or
were
you
here
last
week,
hello,
I'm
sorry
I
was.
I
was
on
me
I'll
just
introduce
myself.
I
guess
myself
and
your
niece
we're
we're
both
aws
interns
for
amazon,
for
myself
I'll
be
taking
over.
I
think
the
previous
interim
kung
kong
dao's.
D
I
think
he
implemented
some
some
parts,
such
as
the
id
generator,
the
propagators
and
some
of
the
resources.
I've
just
been
looking
over
that
and
hope
hoping
to
take
over
in
the
coming
weeks,
with
the
help
of
anurag.
As
my
mentor.
C
All
right
yeah,
he
also-
I
actually
have
one
of
his
prs
on
the
agenda
today
for
the
ecs
plug-in
resource
detector.
So
I
don't
know
if
that's
something
that
you'll
be
taking
over
also,
but
I
think
that
that
will
actually
be
merged
pretty
soon.
So,
okay.
B
B
B
B
C
Just
real
quick,
I
wanted
to
mention
that
I'm
gonna
be
out
again
next
week,
monday
through
wednesday.
So
bart,
would
you
mind
running
the
meeting
next
week?
Sure.
C
Okay,
I
copied
this
from
last
week,
but
it's
still
true,
so
there's
a
lot
of
open
pr's
that
need
reviews.
A
lot
of
them
have
like
two
reviews,
but
just
need
one
one
or
two
more
so
a
lot
of
close
pr's,
but
I
just
want
to
remind
people
to
always
be
reviewing
prs.
C
There
are
a
couple
to
do
with
the
ga
progress.
I
actually
don't
think
that
this
one
is
gay.
C
There
we
go
okay,
so
I
saw
the
global
error
handler.
Pr
was
open
by
matt
has
two
reviews
so
far
from
myself
and
bart,
but
it
would
be
nice
if
we
could
get
a
couple
more
eyes
on
this
before
we
merge
it
matt
is
there
anything
you
want
to
say
about
this?
Pr.
Are
you
just
waiting
for
reviews.
C
Yeah,
okay,
so
please
approvers,
I
know
they're
not
too
many
approvers
on
the
call
today.
Actually,
but
please
review
that
if
you
can,
since
it
is
required
for
the
ga.
C
So
I
was
out
last
week
and
when
I
came
back,
I
I
merged
a
bunch
of
pr's
at
the
beginning
of
this
week,
so
I
was
wondering:
do
you
guys
think
that
we
should
cut
a
release
or
do
you
think
we
should
wait?
Is
there
anything
that
any
pr's
we
want
to
merge
before
we
cut
a
release.
A
C
Yeah,
I
think
they
duplicate
duplicate,
some,
no
there's
one
yeah
this
one
here,
okay,
so
I
know
this
and
this
you
mentioned
they
duplicate
some
functionality.
Are
they
complete
duplicates
of
each
other
or
they
just
duplicate
parts
of
it?.
A
Some
of
and
I'm
just
wondering
what
would
be
the
outcome
if
we
match
two
of
them,
so
I
mean
valentin.
I
think
he
said
he
will
wait
for
first
for
mine
and
then
he
will
remove
something,
because
now
he
needs
to
add
something,
but
once
that
pr
is
much
he
needs
to
remove
something.
C
Yeah
his
is
still
marked
as
a
draft,
so
I
think
we're
probably
safe
to
move
forward
with
your
fix.
He
obviously
already
approved
it,
so
he
thinks
it's
okay,
so
I'll
review
this
before
I
create
the
the
release
pr
and
we
can
try
to
get
this
one
merged.
C
C
C
So
in
14.8
there
was
a
a
fix
for
a
bug
in
async
local
storage
itself,
but
at
least
according
to
johannes,
the
the
pr
that
broke
14
was
never
back
ported
to
12,
so
12
isn't
broken.
C
C
C
Fine,
okay,
that's
that's
the
way
that
I
was
leaning
to
you,
but
I
figured
I
would
bring
it
up
just
to
see.
If
anyone
had
any
dissenting
opinion,
I
guess
we'll
call
it.
C
C
I
just
wanted
to
bring
it
to
everyone's
attention
that
this
is
ready
for
review
and
this
is
sort
of
the
next.
This
is
the
way
that
we
will
expect
plugins
to
be
created
from
now
on.
So
it's
a
fairly
important
piece,
but
it
doesn't
affect
any
existing
functionality
right
yeah.
So
I
think
we
should
probably
get
it
merged
fairly
soon
and
start
trying
to
actually
write
plugins
with
it,
because
until
we
try
to
use
it,
we
won't
know
if
it
needs
any
changes,
but
it
generally
looks
good
to
me.
C
A
I
mean
not
really,
I
mean.
Finally,
it
works
in
the
way
as
it
should
so
it's
it's
giving
you
possibility
of
instrumenting
all
the
files,
including
the
internals,
before
the
release
so
like
for
graphql.
Without
this
one,
I
cannot
write
the
plugin
graphql,
because
the
graphql
is
exposing
all
methods
and
object
as
it
only
so.
You
cannot
batch
them
at
all
yeah.
That's
the
internal
files,
patching
yeah!
C
Okay,
so
this
is
a
fairly
important
pr.
It's
not
technically
required
for
ga,
but
I
would
I
think
we
should
have
it
done
before
ga.
So
I'm.
A
Just
thinking
the
next
step
would
be
just
to
have
some
some
package
that
will
basically
combine
because,
in
the
end,
we'll
remove
the
plug-in
loader,
as
if
I
understand
correctly.
So
we
need
still
a
way
to
include
some
meta
package
which
basically
load
and
create
all
the
plugins
that
you
want
automatically
and
assign
the
tracer
and
meter
provider.
C
I
would
hope
so,
unfortunately,
like
we
already
so
if
it
was
just
our
plugins,
then
I
would
say
I'd
like
to
deprecate
the
old
plugin
system,
but
unfortunately
we
already
have
a
handful
of
plugins
in
the
wild,
so
to
speak
that
are
hosted
by
repositories.
We
don't
control
that
are
written
by
people,
we
don't
necessarily
even
know.
C
So
I
think
we
have
to
continue
to
support
the
old
method
for
at
least
a
while.
We
may
want
to
add
a
deprecation
warning
on
it,
or
something
like
that
and
I'd
like
to
encourage
people
to
use
the
new
plugin
format,
but
I
don't
know
if
it
will
be
possible
to
actually
get
everybody
to
switch.
C
It
should
it
does
so
now,
with
the
new
system.
Plugins
will
actually
load
and
patch
their
various
modules.
First.
That
will
be
the
first
thing
that
happens
before
anything
else
gets
loaded,
and
actually
what
really
made
that
possible
was
the
proxy
tracer
pr
that's
been
in
for
a
few
weeks
now,
because
it
initially
patches
it
using
the
proxy
tracer
and
then
once
the
sdk
is
loaded.
Those
tracers
become
useful,
rather
than
being
no
ops.
C
To
some
extent,
this
this
does
help
it.
I
it
requires
both
of
these
things,
so
just
this
wouldn't
fix
it,
and
just
the
proxy
tracer
didn't
fix
it,
but
both
of
these
working
together
does
fix
the
load
order.
C
Okay,
there
are
a
couple
of
pr's
here
that
I
wanted
to
to
pull
out
as
they've
already
received
some
approvals
and
I'd
like
to
merge
them,
but
I
just
wanted
to
get
you
know,
they're
ones,
that
that
had
a
lot
of
comments,
so
I
just
wanted
to
get
last
chance
to
say
no
on
these.
I
know
bart.
You
had
quite
a
few
comments
on
this,
but
it
looks
like
you
eventually
approved
it.
So
you
are
you,
okay.
If
I
merge
this.
A
C
A
A
Let's
I
mean
the
biggest
concern
here
is
that
if,
if
you
basically
previously,
you
could
in
a
pure
js,
you
could
create
and
nothing
could
happen
now.
If
you
don't
provide
a
config,
it
will
basically
throw
another,
because
now
it's
assumed
that
there
should
be
something
which
I
see
so
and
the.
A
C
So
I
see
what
you
mean
by
that,
but
I
think
the
whole
point
of
this
pr
is
so
I
I
think
we
should
start
the
server
by
default.
I
had
originally
been
against
that
because
I
didn't
want
to
modify
behavior,
but
without
it
the
exporter
is
useless.
C
C
C
C
C
C
Please
review
that,
if
you
guys
are
not
aware
of
what
this
is,
what
the
issue
is
here,
it's
that,
when
you,
within
its
current
state,
the
http
sensor,
is
setting
the
outgoing
span
as
active
on
the
context,
which
then
makes
it
active
in
the
response.
Callback
right
is
that
my
understanding
that
correctly.
A
I
think
the
the
things
that
valentine
is
doing
yes,
but
why
is
a
different
one
like,
for
example,
if
you,
if
you
are
using
it's,
it's
the
best
visible,
for
example,
with
open
tracing.
A
A
C
So
one
more
like
fairly
old
pr
that
I
wanted
to
bring
up
here.
This
is
the
ecs
resource
detector.
C
This
was
written
by
kong,
the
no
written
by
a
different
yeah,
yeah
kong,
the
previous
aws
intern,
who
is
gone
now
kelvin?
I
don't
know
if
you
are
taking
over
responsibility
for
his
open
prs.
I
think
this
might
be
the
only
one
he
has
currently
open,
but
it
doesn't
have
any
merge
conflicts,
it's
just
lacking
reviews.
C
So
if
we
could
get
one
or
two
more
reviews
on
this,
we
could
get
it
merged
and
not
have
to
worry
about
that.
So
I
would
appreciate
that
it
looks
like
it
only
needs
one
more.
C
C
C
That
covers
everything
that
I
really
had
on
the
schedule.
I
also
wanted
to
just
mention
that
the
ga
tracker-
we
still
have
a
lot
of
issues
that
don't
have
pr's,
yet
it
looks
like
matt
you
should
have
a
pr
in
here
looks
like
it
probably
just
wasn't,
added
to
the
to
the
tracker
right.
E
Not
added
to
the
tracker
project.
C
E
Cool,
I
was
hoping-
maybe
it
magically
happens
by
linking
the
issue
in
the
pr,
but.
C
Yeah,
it
would
be
nice,
it
doesn't
seem,
like
the
projects
have
a
lot
of
magic
at
all,
so
maybe
in
the
future.
But
for
now
it's
the
manual
step
cool
good
to
know
other
than
that.
I
have
this.
The
the
fields
and
keys
prs
I'll,
probably
open.
Today,
I've
been
working
on
them.
I
just
haven't
had
a
ton
of
time
to
work
on
them,
but
they
are
basically
done
so
I'll,
be
opening
those
soon.
C
C
E
I
have
a
b3
issue
assigned
to
me.
I
think
I
have
it
as
feature
requests,
but
it's
really
required
for
ga
now.
This
is
another
thing
that
was
kind
of
underspecified
that
I
found
on
the
spec
and
decided
to
kind
of
look
around
and
see
what
was
happening
in
hotel
yeah.
Basically,
we
need
to
have
single
header
support
and
the
way
the
spec
is
written.
B3
should
technically
the
b3
propagator
should
come
in
an
extension
package.
E
E
Yeah,
if
you
want
the
full
version
on
extract,
you
should
look
for
single
or
multi
header
v3
for
inject
by
default.
You
should
inject
single
header
b3,
but
have
some
config
to
change
that
to
multiheader.
C
E
Yeah,
so
that
was
already
in
the
spec
I
was
trying
to
just
say:
hey
you
can
ship
it
with
the
sdk
if
you
want,
but
bogdan
seemed
very
adamant
that
it
should
be
separate.
So.
C
Okay,
I
mean
I,
I
think,
that
those
should
probably
be
two
separate
prs
just
because
they're
separate
ideas,
but
if
it's
you
know
if
it's
minor,
then
I
guess
I
don't
see
a
problem
with
it
being
one
pr.
I
just
think
it'll
be
easier
if
it's
two
different.
E
Pr's,
I
think
that's
fine,
like
I'll
I'll
plan
on
doing
the
work
since
it'll
be
probably
painful
to
have
two
people
try
to
do
that
concurrently,
but
once
I
get
the
b3
support
working
as
as
expected,
I'll
win
a
pr
for
that
and
then
just
kind
of
base.
My
work
to
separate
that
out
into
a
different
package
off
of
that.
C
Yeah,
okay
and
then
I
think
the
jaeger
one
is
also
distributed
as
part
of
the
sdk
right
now.
So
maybe
in
the
in
the
pr
that
you
so
one
pr
to
do
single
header,
support
for
b3
and
then
another
pr
to
split
b3
and
jager
out
into
their
own
packages.
I
think
would
be
probably
the
way
to
go.
C
I
guess
that
covers
it
for
today
a
relatively
quick
meeting.
I
know
I
went
through
some
of
these
things
fairly
quickly.
Does
anyone
have
any
questions
or
concerns
that
they
want
to
bring
up
before
we
go.
C
Seems
like
no
well
thanks
for
your
time,
everybody,
and
I
will
speak
to
you
in
two
weeks.