►
From YouTube: 2021-03-31 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
C
C
C
C
Valentine's
not
coming
today
because
of
curfews
in
paris.
D
Yeah
totally,
I
am
from
honeycomb,
I'm
actually
pretty
new
to
this
space
as
well.
Let's
see
I
joined
in
december
and
so
we're
trying
to
kind
of
be
more
involved
with
the
hotel
group
in
general,
and
I
was
the
winner
for
node.
So
here
I
am,
I'm
just
trying
to
learn
really
see
where
the
project
is
at.
I
kind
of
perused
the
repo
and
the
issues,
but
kind
of
still
getting
my
footing.
D
C
All
right,
so
the
first
thing
that
I
wanted
to
talk
about
is
the
the
release,
pr
action
it's
actually
failing.
Originally,
I
was
going
to
ask
will
about
this,
but
then
I
actually
in
trying
to
create
a
manual
release
pr
noticed
that
mine
failed
in
exactly
the
same
way.
C
So
I
think
there
might
be
some
different
issue
here
where
you
know
maybe
the
types
the
happy
types
updated
or
something
like
that,
so
I'll
look
into
that.
Hopefully
there
is
no
issue
with
the
the
release
action.
So
will
I
see
that
you're
on
the
call,
I
think,
there's
probably
no
problem
with
it,
but
if
there
is,
I
might
reach
out
to
you
on
slack
later
today
to
try
to
help
debug
it.
If
that's
okay,.
E
C
Release
the
I
think
it
was
like
the
0.15.0
yeah
I
manually
generated
that
one
earlier
today.
Okay
got
it
and
it
failed
in
exactly
the
same
way.
So
I
think
it's
probably
not
an
issue
with
the
action,
but
if
it
is,
I
might
reach
out
to
you
what
what
part
I
guess
I
can.
I
can
look
through
all
the
vlogs
I'll
just
do
a
part
of
the
action
you
can
see
my
screen,
it's
the
compilation
of
the
happy
instrumentation
that
actually
failed
with
some
sort
of
type
error.
C
My
my
guess
is
probably
that
the
happy
types
updated
in
a
breaking
fashion
and
pushed
it
out
as
a
patch
release
so
that
we're
probably
getting
the
a
later
version
in
ci.
I
probably
on
my
local
version,
just
need
to
blow
it
away
and
reinstall
and
I
will
probably
be
able
to
reproduce
it
locally
fairly
easily.
As
my
assumption.
C
Okay
got
it
so
just
pulled
in
a
a
non-sunbear
component
change
yeah,
I
think
so,
which
you
know
it
happens,
there's
a
lot
of,
especially
in
the
dead
dependencies.
There's
a
lot
of
dependencies,
so
yeah
all
right!
Well,
yeah
I'll
keep
an
eye
on
slack,
so
the
that
release
pr
is
failing
for
now,
but
I'll
try
to
push
an
update
to
it
that
that
fixes
it
today
and
that
release
is
blocking
essentially
all
of
the
rest
of
the
sdk
rc.
C
Beyond
that,
the
the
sdk
is
looking
pretty
good.
All
the
plugins
have
been
converted.
I
think
we
already
talked
about
that
last
week
and
the
steps
that
we
have
left
to
do
are
all
sort
of
blocked
by
this
release.
So
I
will
work
on
getting
that
release
ready
to
go
today.
I
was
hoping
to
do
it
before
this
call,
but
I
kind
of
ran
out
of
time
so
hopefully
today
beyond
that,
I
think
the
only
thing
left
is
removing
the
the
base
plug-in
of
the
plug-in
loader.
A
A
C
Okay
and
then
removing
the
meta
packages
again
is
blocked
on
a
release,
so
I
will
definitely
make
sure
to
get
that
release
out
as
soon
as
possible,
since
it's
blocking
essentially
everything
right
now
beyond
that,
we
don't
really
have
a
lot
to
talk
about
in
terms
of
the
sdk
rc.
A
I
mean
I
I
I'll
be
basically
removing
stuff
and
and
you'll
be
adding
the
new
stuff
to
the
removing
stuff.
So
there
will
be
confidence
which
I
want
to
avoid
I'm
having
a
hard
time
hearing
you
I'm
just
saying
that
I'll
be
removing
stuff
and
each
new
release
is
adding
and
updating
the
things
that
will
be
removed.
A
G
They
know
any
any
word
from
the
tc
on
that
approval
process.
Or
do
you
know
if
that's
going
to
be.
C
Yeah
I
talked
to
the
tc
about
it
and
what
they
said
is
essentially,
there
was
a
lot
of
pushback
from
the
other
cigs
about
the
review
process
and
that
making
it
mandatory
was
kind
of
going
to
be
a
no-go
and
they
couldn't
even
agree
on
like
the
process
for
it.
So
the
pr
is
still
not
merged
and
it's
still
open,
but
I
did
find
a
tc
member.
That
said,
he
would
review
it
for
us.
C
Some
of
the
other
cigs
have
done
sort
of
the
same
thing
yeah
just
because
nobody
can
agree
on
the
way
to
do.
It
doesn't
mean
it's
not
a
good
idea,
so
I
I
think
we
will
have
a
tc
member
review,
our
compliance
in
the
next
week,
or
so
I
think
he
was
going
to
try
to
start
on
that
today.
But
I
don't
know
exactly
what
his
schedule
and
timing
is
and
stuff
like
that.
So
yes,
we,
we
will
be
getting
a
review,
but
there
is
no
official
process.
G
Cool
thank
you.
So
then
that
said,
do
we
have
any
any
target
for,
like
the
actual
1.0.0.
C
C
G
Okay,
yeah
and
no
rush-
I
just
was
just
wondering
for
my
own
money
purposes,
so
thank
you
for
the.
C
Update
yeah,
I
know
that
it's
kind
of
been
been
a
slow
process,
but
we
just
want
to
make
sure
we
do
it
right.
C
Anyone
else
have
any
other
questions
about
the
sdk
rc
before
I
move
on
yeah
one
question.
H
So
at
the
moment,
when
you
use
the
api
release
candidate
it
it
doesn't
work
well
with
like
the
older
versions.
H
If
so,
if,
if
you
would
switch
the
sdk
to
like
this
release
candidate,
can
you
still
use
code
that
augmented
with
the
0.18
one
api,
or
does
that
need
to
be
upgraded
too,
because
I
just
spent
two
weeks
trying
to
fix
some
pops
up
library
and
I
don't
really
feel
like
upgrading
it
to
make
good
to
make
it
work?
C
H
C
So
there
is
actually
a
pr
for
that
linked
lower
down
in
the
dock
here.
So
essentially,
what
happened-
and
I
think
you
might
already
be
aware
of
this-
was
we
updated.
H
C
C
C
Or
it
depends
which
version
of
the
sdk
you're
using
if
you're
on
the
0.18
version
of
the
sdk,
then
you
should
stay
with
the
zero
that
18
api.
But
if
you
wait
and
use
the
0.19
sdk,
then
you'll
want
to
use
the
release
candidate
of
the
api.
C
Yep
and
I
will
make
sure
to
update
the
compatibility
matrix
to
make
that
clear
or
if
it's
not
already
correct,
I'll,
take
a
look
at
it
after
this
call.
B
C
So
I
think
the
major
the
the
biggest
issue
there
is
that
the
if
you
use
an
sdk
and
an
api
that
are
incompatible
right
now,
it
behaves
as
no
op
which
can
be
confusing.
I
think
that's
what
you're
getting
at
so
we
probably
need
a
better.
C
C
There
are
two
changes
that
we
can
make
to
sort
of
ease
this
one.
We
could
introduce
like
a
debug
environment
variable
that
would
turn
on
the
debug
logging
so
that
users
could
more
easily
see
what's
going
on
without
having
to
manually
go
enable
debug
logging
in
their
code.
C
The
at
install
time.
Npm
will
warn
you
that
the
sdk
requires
a
peer
dependency
of
this
version,
but
you
have
installed
this
version
and
they
don't
match.
C
C
Do
that,
but
I
don't
know
if
you
actually
can
remove
the
the
latest.
D
C
I
C
Going
to
come
after
this.
C
Api
dependency
update,
oh
I
got
it.
This
is
the
api
package.
I'm
sorry,
I'm
confusing
myself.
Yeah
so
is
my
release.
A
0.18.
I
C
C
Will
npm,
let
you
add,
a
latest
tag
on
a
version,
that's
older
than
the
current
latest?
I'm
not
sure,
I'm
not
sure
I
think
so,
but
I'm
not
sure
I
can
try
after
this
call.
You
know
the
worst
case
scenario
is
it
doesn't
work
and
you
know
we
tried
at
least
I'll,
also
email,
the
support,
but
you're
right.
We
should
try
to
get
this.
This
tag
removed.
C
H
H
I
C
Yeah,
but
it
is
something
that
I
it's
good
to
know.
I
hadn't
really
thought
about
the
fact
that
this
latest
tag
would
install
the
rc
and
then
it
wouldn't
be
compatible.
C
F
I
do
think
it
will
be
nice
to
at
that.
There's
like
this
locking
matches,
maybe
when
the
lock
levels
debug
or
something
or
all,
that
you
just
get
a
warning
that
you
use
incompatible
version.
Just
like
you
get
this
messages
when
you
try
to
regress
to
the
same
api
twice
so
something
similar
to
that
yeah.
So
I
think
we
do
log
don't
actually
and
then
I
probably.
C
We
do
log
all
api
registrations
should
match.
We
have
various
version
incompatibility
logs,
but
by
default
this
diag
logger
does
nothing
so
you
have
to
enable
it
yeah.
So
if
we,
I
guess,
simplify
that
process
with
an
environment
variable
of
just
enabling
those
does
diagnostic
logging
that
should
simplify
the
process.
I
think
yeah
makes
sense.
Okay,
so
I
guess
I
will
create
that
issue
now,
so
that
we
don't
forget
it.
F
F
I
also
noticed
yesterday
I
was
working
on
adding
the
semantic
convention
for
the
traces
for
the
google's
pub
sub
library
and
it
look
I
have.
I
don't
know
if
these
some,
if
the
semantic
convention,
packets
get
generated
or
not,
but
the
the
description
and
the
name
of
the
constant
don't
match.
Sometimes
so
I
don't
know
if
it's
just
randomly
generated,
but
there
is.
F
I
thought
there
was
like
a
tool
for
it
right.
At
least
I
read
about
that,
but.
C
C
I
forgot
what
the
repository
is
called
tools
repository.
There
is
a
tool
to
generate
these
semantic
conventions,
so
we
should
probably
be
using
this.
C
If
you
could,
if
you
could
handle
that,
I
would
really
appreciate
that
yeah,
okay.
C
Are
you
a
member
of
the
open,
telemetry
organization?
So
if
I
create
an
issue,
will
I
be
able
to
assign
it
to
you.
F
I
don't
think
I
don't
think
so.
I
did
contribute
1pr
a
little,
but.
C
C
Oh
never
says
the
sdk
already
has
a
log
level
environment
variable.
So
I
guess
that
just
means
we
need
to
document
it
more
prominently.
Probably.
C
You
know
add
a
troubleshooting
section
on
the
on
the
read
me
or
something
like
that.
F
I
I
personally
not
see
it,
but
I
will
ever
I'll
look
at
it
again.
Maybe
I
just
missed
it
last
time,
but
I
do
I
do
know
like
once
you
get
these
noobs
fans.
It's
highly
likely
we're
using
a
wrong
version
of
either
api
or
the
sdk.
So
but
yeah
I
will.
I
will
try
it
again
but
yeah.
I
think
it
will
be
good
to
document
it
like
somewhere,
maybe
in
discussions
when
they
read
me
file
to
say
if
you
got
this,
maybe
you're
using
wrong
versions.
C
Okay,
so
it
sounds
like
no
an
issue
was
reported.
I
believe
yesterday
yeah
and
I
believe
that
the
person
that
reported
this
issue
is
on
the
call,
but
it
was
linked
to
the
same
versioning
compatibilities
that
we
were
talking
about.
C
But
one
issue
that
comes
up
is,
if
you
use
an
incompatible
version,
it
uses
a
no
op
context
manager
and
then,
when
a
span
is
exported
using
http,
it
tries
to
automatically
trace
that
spam
because
the
disabled,
instrumentation
or
the
suppressed
instrumentation
on
the
context
isn't
propagated,
because
the
propagator
uses
a
no
op
context
object.
C
C
C
Span
would
be
to
return
a
context,
manager,
disabled
context
or
something
like
that.
I
I
have
to
look
into
this
a
little
bit
more
since
I
just
started
kind
of
looking
at
this
this
morning
and
I
don't
really
feel
like.
I
have
my
head
entirely
wrapped
around
this
issue,
well
enough
to
say
whether
that
that
fix
would
work
or
whether
there
would
be
other
issues
with
it.
C
I
C
So
it's
not
it's
not
that
we
can't
make
a
breaking
change,
because
that
is
sort
of
the
the
point
of
the
release
candidate
process,
but
I
do
feel
like
it
should
be
avoided
if
we
can
do
so
with
some
reasonable
level
of
effort.
I
C
C
Now
this
would
not
affect
the
context
manager
specifically,
but
it
does
you
it.
I'm
just
trying
to
say
it
does
have
some
possibility
that
that
there
will
be
versioning
compatibilities
in
the
future.
C
C
So
I
would
appreciate
if
people
can
take
a
look
at
this
issue,
and
you
know
if
you,
if
you
like
the
solution
that
I
proposed,
go
ahead
and
comment
that
or
if
you
have
some
other
solution.
I
would
definitely
appreciate
it
at
this
point
still
in
the
idea
mode
here.
So
I
haven't
started
implementing
any
fix
for
this.
Yet.
C
So
we
did
already
talk
about
this
earlier
about
how
the
the
zero
id
18.1
release
was
actually
accidentally
a
breaking
change,
so
that's
been
fixed
and
now
we're
waiting
on
the
the
release
candidate
upgrade
pr
again.
So
please
review
this
pr.
I
don't
know
how
many
reviews
it's
gotten
so
far,
but
I
think
yeah
none
yet
so
that's
sort
of
we're
just
waiting
on
that
for
the
for
the
next
sdk
release.
I
Yes,
sir,
I
have
a
question
or
discussion
about
this
issue
where
our
dependency
is
on
exact
version
like
we
have
dependency
on
18.0,
but
the
core
packages
when
they
use
other
core
packages,
they
have
dependency
with
the
current
at
the
beginning.
I
So
it
is
possible,
for
example,
that
we
have
collector
of
version
18.0
that
has
dependency
on
18.2,
which,
like
I,
I'm
not
sure
why
why
it
is
like,
like
this
like.
Why
not
have
exact
dependency
in
the
core
packages
on
other
core
packages.
C
Core
packages
are
released
together,
we
could
have
them
depend
on
exact
versions.
I
know
the
original
sort
of
motivation
behind
using
the
carrot
versions
was
to
allow
particularly
bug
fixes
to
be
automatically
picked
up
by
new
installs,
or
you
know
things
like
that,
but.
G
C
I
Yeah
because,
for
example,
we
we
want
to
pin
the
version,
so
if
a
new
version
is
released,
we
need
to
test
it
first
to
make
sure
that
nothing
is
breaking
our
system,
and
only
then
we
release
our
sdk
with
with
the
new
version
like
a
patch
version
or
minor
version.
But
since
the
core
packages
have
dependency
with
carrot,
then
we're
unable
to
do
it
like
perfectly
because
we
could
get
like
a
new
version,
push
to
us
without
us
being
able
to
test
it
first.
I
We
are
using
package
locks
on
the
application
level,
but
not
on
our
sdk.
Our
sdk
does
not
contain
a
package
lock.
I
Yeah
we're
a
vendor
of
open
telemetry
and
we
have
we're
using
open
telemetry
and
we
publish
our
own
sdk
a
lot
that
drops
open.
Telemetry
and
people
install
our
sdk
in
their
applications.
I
Okay,
so
there
is
a
package
lock
on
the
application
that
installs
us,
but
if,
for
example,
the
issue
from
yesterday,
fresh
installations
will
just
pick
up
the
latest
version,
which
is-
and
we
don't
have
a
chance
to
test
it.
First.
C
For
now
I'll
open
a
discussion
issue,
so
we
can,
you
know,
gather
feedback
on
that,
but
I
I
don't
see
a
reason
not
to
I
think
you
know.
I
would
like
to
say
that
this
was
a
carefully
considered
decision,
but
it
really
wasn't.
I
think
that's
just
the
default
behavior
of
lerna,
so
it's
something
that
we
can
definitely
change.
If
we
you
know,
if
there's
a
need
to
do
so,.
G
If,
if
you
switch
to
pure
dependencies,
how
does
that
affect
this
because,
like
if
you,
if
you
put
pure
dependencies
with
carrot,
ranges
and
then
amir
pins,
the
dependencies
in
in
the
in
the
package.js
that
package.json?
G
Would
that
not
do
the
same
thing
like
you?
Wouldn't
get
duplicate
versions
and
you
could
have
the
pinning
at
the
library
level,
without
the
lock
file
right.
C
It
would,
but
we
don't
want
to
have
like
the
trace,
like
that.
The
open,
telemetry
node
module
appear
to
bend
on
the
open,
telemetry
tracing
module,
because
then
users
would
have
to
manually
install
both.
We
want
that
to
be
like
a
an
auto
install
dependency
and
like
we
have
a
lot
of
modules
like
the
core
module
and
the
tracing
module
and
the
metrics
module,
and
things
like
that.
C
That
users
are
not
necessarily
you
know
most
of
the
time,
don't
necessarily
need
to
install
them
manually
and
if
we
started
using
pure
dependencies
for
that,
they
would
have
to
install
them
manually,
and
they
would
have
to
make
sure
that
all
the
versions
are
compatible
with
each
other
and
such
I
just
think
would
that
would
be
adding
additional
burden
to
the
user
that
we
wouldn't
necessarily
you
know,
bring
enough
value
to
justify
the
burden.
G
Okay,
yeah,
I
mean
I
I
don't
know
if
everybody's
using
mpm7,
but
it
does
install
them
for
you
automatically
and
it
complains
if
there's,
if
there's
issues
with
the
dependency
versions.
G
Like
the
resolution
I
did,
I
didn't
want
to
say
one
other
thing
was
with
the
core
packages
include
the
like
the
api,
because
that
seems
to
be
the
one
that
you'd
want
to
leave
as
like
a
carrot
range,
because
if
somebody's
instrumented
directly
and
they're
pinning
their
dependencies,
you
would
you
would
not
want
to
have
duplicate
api
installations
in
the
node
modules
right.
C
Yeah,
so
that
the
api
module
is
going
to
be
a
pure
dependency,
and
I
think
that
probably
it
can
safely
use
a
range
which,
since
the
user
has
to
with
a
peer
dependency,
install
their
own
version
of
it
anyway,
they
can
go
ahead
and
pin
that
and
then,
if
we
use
a
range,
we're
actually
being
more
permissive
in
terms
of
which
versions
they
can
pin
on
their
own.
C
Any
other
questions
about
this:
okay,
lambda
instrumentation,
who
added.
E
This
one
yeah
that
was
me
I
can
take
a
quick
review
of
this
pr,
but
it's
an
experimental
new
piece
of
the
spec
that
some
of
my
colleagues
at
aws
have
been
working
on
for
instrumenting,
like
functions
as
a
service
like
serverless
functions,
and
so
obviously
I
know
everyone's
working
on
the
rc,
but
just
wanted
to
raise
it
to
the
attention
of
the
maintainers.
Since
it's
kind
of
a
new
form
of
instrumentation,
that's
only
been
done.
E
I
think
on
like
the
java
and
python
sigs
so
far
so
yeah.
We
wanted
to
start
adding
it
to
all
the
languages
that
are
compatible
with
lambda,
and
this
is
kind
of
the
first
iteration
of
that.
E
The
handler
itself
yeah,
so
all
that
my
understanding,
all
that
this
one
does
is
wraps
the
the
lambda
function
handler
with
the
span
and
then
in
subsequent
iterations.
There
will
be
kind
of
more
handling
for
different
types
of
invocations
of
the
lambda
function,
because
there
can
be
kind
of
like
fan
in
invocations,
where
there's
like,
say
a
batch
of
several
traces
that
are
invoking
a
single
function
and
other
sorts
of
cases
like
that.
So
this
is
kind
of
just
like
the
first
iteration
on
that.
B
C
So
one
immediate
problem
that
I
can
think
of
with
this
is
that
the
spans
are
likely
to
fail
to
export
because
there's
no,
you
know,
there's
no
way
inside
the
handler,
then
to
to
force
a
flush
and
using
the
api
only
we
don't
expose
any
way
to
force
a
flush.
C
I
don't
know
if
that's
handled
here
or
how
that's
handled,
but
if
the
invocation
finishes
and
the
you
know
the
the
lambda
is
suspended,
then
it
won't
flush,
at
least
until
the
next
invocation,
and
if
it
gets
shut
down
it
you
know,
may
not
flush
ever.
E
They
yeah
that
force
flush
issue
is,
is
the
was
the
biggest
problem
with
the
lambda
instrumentations?
I
don't.
Actually
I
haven't
taken
a
look
at
it,
yet
I
guess
I
assumed
the
force
flush
api
was
available,
but
it's
possible
that
honorable
just
implemented
one
to
to
work
around
it
or
something
like
that,
but
yeah.
We
were
definitely
aware
of
that
limitation,
so
I
will
I'll
look
out
to
see
how
honorable
fix
that,
if
that's
not
like
kind
of
available
out
of
the
box.
C
Okay
and
if
it's
not,
then
it's
probably
worth
mentioning
that
I've
already
written
a
lambda
instrumentation
for
open
telemetry
for
dynatrace,
that's
you
know,
had
it's
been
in
production
for
quite
a
while
now
and
it's
fairly
mature
and
I
had
originally
meant
to
open
source
it.
But
I
sort
of
got
bogged
down
by
the
the
internal
processes
for
open
sourcing
things,
and
I
just
didn't
have
time
to
follow
through
with.
H
C
But
the
the
way
that
we
went
about
it
was
actually
instrumenting.
The
rapid
client,
which
is
the
I
don't
know
how
familiar
you
are
with
lambda
internals,
but
it's
actually
the
the
the
lambda
internal
mechanism.
That's
handles
function,
indications
and
calling
user
functions,
and
that
kind
of
thing
right.
B
C
Delay
the
the
the
completion
of
the
function
itself
until
after
the
export
had
finished,
and
we
passed
the
span
processor,
I
believe,
into
the
constructor
of
the
of
our
instrumentation,
so
that
it
would
have
a
handle
to
it
so
that
it
would
be
able
to
flush
that
way.
C
Interesting,
I
can
talk
to
that.
Nobody
was
blocking
the
you
know,
open
sourcing
that
it
just
sort
of
fell
through
the
cracks
because
nobody
had
time
to
handle
it.
So,
if
you're
interested
in
that,
I
can
talk
to
my
manager
about
moving
that
process
along
a
little
bit
more
or
if
you'd
prefer.
C
C
E
Yeah,
no,
I
mean
we
definitely
are
comfortable
with
maintaining
the
lambda
components.
E
So
if
I
don't
yeah,
if
you
wanted
to
open
a
separate
pr
like
the
yeah,
the
only
thing
is
like
I
don't
know
how
comfortable
we'd
be
with
instrumenting
the
rapid
client
and
like
taking
the
dependency
on
like
the
kind
of
lambda
internals,
because
right
now,
there's
like
kind
of
a
newish
feature
from
lambda
called
lambda
extensions,
which
provides
like
life
cycle
events
for
lambda,
invocations
and
so
it'll
kind
of
emit
an
event
for
the
beginning
of
an
invocation
and
then
for
the
end
of
one
and
then
eventually
we're
kind
of
working
with
the
lambda
team
to
get
them
to
also
emit
a
a
freeze
event
to
let
you
know
to
get.
E
Allow
you
to
do
things
before
the
environment's
frozen,
which
is
kind
of
the
workaround
that
it
sounds
like
you've
reached
and
so
we're
working
with
the
lambda
team
to
get
that
kind
of
exposed
as
a
public
hook,
that
we
could
use
to
to
flush
out
spans
so
that
it
would
be
actually
something
that
they
officially
support.
E
E
But
I
I
mean,
I
think
that
as
long
as
it's
the
same
end,
user
experience
like
I
could
certainly
talk
to
talk
to
onorag
and
to
my
team
and
see
how
how
much
we
care
about
the
implementation
details
or
like
if
we
want
to
wait
on
like
continuing
to
iterate
on
ours
and
maybe
like
wait
against
yours,
yeah,
okay,.
C
So
I'll
talk
to
my
manager
also
about
you,
know
cont
moving
that
process
along,
like
I
said,
no
one
was
really
blocking
it.
It
just
kind
of
got,
you
know,
fell
through
the
cracks
because
it
wasn't
a
priority
for
anyone,
but
but
I'll
reach
out
to
you
on
slight
you're
on
the
slack
right,
the
cncf
slack
yep
I'll
reach
out
to
you
there,
and
we
can.
C
You
know
we
can
continue
this
discussion,
since
this
is
fairly
lambda
specific
and
I
I
don't
know
how
many
other
people
on
the
call
or
want
to
talk
about
this
for
10
minutes,
so
yeah
totally
I'll
reach
out
to
you
and
I'll.
Let
you
know
what
my
manager
says
he's
in
europe,
so
he's
he's
likely
already
done
working
for
today.
So
I
would
expect
a
response
tomorrow
at
the
earliest,
but
yeah.
C
C
C
It's
pretty
pretty
crazy
yeah,
so
we
we
did
it
because
we
needed.
We
didn't
have
a
freeze
event
and
we
needed
a
way
to
make
sure
that
no
spans
were
dropped.
So
we
have
zero
dropped
spans
which
we're
pretty
proud
of,
but
yeah
yeah.
We
can
talk
about
this
offline
yep.
That
sounds
good.
C
Does
anybody
else
have
anything
that
they
would
like
to
bring
up
before?
We
call
it
for
the.
C
Day,
okay,
then,
I
guess
please
review
prs
and
I
will
talk
to
everybody
next
week.