►
Description
A
A
Okay,
so
we
have
no
announcements
today,
we'll
move
on
to
the
CPC
and
board
meeting
updates.
I
guess
the
the
update
I
would
have
we'd
made
a
request
for
build
resources.
I
did
get
a
few
names
from
Microsoft
who
I'm
chasing
down.
Unfortunately,
a
couple
of
them
at
least
one
of
them
doesn't
actually
have
cycles
so
still
pursuing
that,
but
haven't
haven't
gotten
to
the
point
where
we're
actually
getting
people
engaged.
Yet
I
will
take
a
quick
look
at
the
board.
I,
don't
think,
there's
anything
added
on
it,
but
just
make
sure
in
the
admitted.
A
And
so
I
think
that
we've
covered
the
the
ones
that
are
there.
The
other
thing
I
will
mention,
there's
a
there's.
Some
discussion
going
around
this
is
sort
of
CPC
related
to
about
the
travel
fund.
In
the
meantime,
we
did
get
one
travel
fund
request,
so
I've
asked
for
and
there's
underway
a
board
vote
to
get
approval
as
a
one-off,
so
that
we
can
improve
that
travel
as
well.
A
A
I
guess
the
one
thing
I
would
call
out
is
that
there
is
going
to
be
a
sort
of
code
of
conduct
team
spun
up
to
look
at
the
current
proposal
and
some
of
the
suggestions,
the
additional
sort
of
new
suggestions
that
people
have
made
in
terms
of
you
know,
scope
and
so
forth,
to
try
it
to
plot
the
direction
forward.
Out
of
the
discussion
after
the
discussions
at
the
collaborator
summit,
so
so
that's
something
if
you're
interested
you
should
look
to
to
get
involved
in.
A
A
A
A
This
one
I
know
there's
been
some
discussion
last
time
we
did
ask
if
we
could
get
somebody
from
a
run
kit
to
come
in
and
sort
of
have
a
discussion
with
us
sounds
like
the
you
know,
one
of
the
people
from
rent
kid
is
available
to
do
that.
They
weren't
available
this
week,
but
we're
looking
to
try
and
do
it
next
week,
so
I
guess
I'd
propose.
Unless
people
have
some
things
they
want
to
talk
about
now
we
might
defer
that
till
next
week.
A
C
C
C
C
B
A
C
I
know
something
there
was
a
talk
about
this
after
again,
who
was
at
the
summit,
so
I
won't
try
and
remember
their
name,
but
some
people
feel
like
there
should
be
an
example
under
every
API
it
just
gets
it
gets,
but
then
people
there's
people
who
also
think
that
every
example
should
be
runnable
stand
alone
and
on
the
face
of
it.
Both
of
those
things
sound
reasonable,
except
a
lot
of
our
API
is
to
get
a
stand
of
all
alone.
Rentable
example.
C
C
D
A
B
C
A
C
Just
gonna
I'll
comment
on
the
PR
and
I
think
it's
partly
sensitive
because
somebody
was
invited
to
make
the
change
as
a
code
and
learn
exercise
yeah.
So
it
feels
you
know
an
unfriendly
and
to
to
then
reject
the
change
when
we
we
will
not
any
individual
here,
but
as
a
group
they
were
somehow
asked
to
make
the
change
yep
and
that's
that's
unfortunate,
but
I,
don't
know
that's
enough
of
a
reason
to
land
it.
I.
B
A
Yeah
I
mean
I
think
it's
especially
as
a
you
know,
even
if
you
said,
let's
land,
that
because
of
that
I,
don't
think
it
should
be
a
policy
direction
of
like
now.
Everything
has
a
has
an
example,
and
if
we
decide
that
the
answer's,
no,
then
it
could
easily
be
removed
so
I,
it's
not
a
good
enough
reason
to
set
up
set
a
direction
that
chain
completely
changes
the
deck.
A
A
A
I'll
take
the
so
proceed,
so
this
one
is
a
PR
to
pull
in
CLS
context,
basically
being
able
to
have
an
API
where
you
can
help
preserve
context
across
async
requests.
It
was
came
out
of
a
discussion
at
the
diagnostic
summit
back
in
the
fall,
and
the
issue
we
were
struggling
with
at
the
time
is
that
async
hooks
isn't
stable
and
actually
we're
not
convinced
we
have
the
right
API
and
we're
making
very
very
if
any,
very
slow.
A
If
any
progress
on
unchanging
that-
and
so
the
discussion
was
that
you
know
it
might
be
easier
to
come
up
with
a
higher
level
API
because
async
hooks,
you
know,
some
of
the
concerns
are
like,
does
it
it?
Does
it
expose
too
much
internals?
Is
it's
too
specific
to
what's
going
on
and
that's
part
of
why
you
know
you
know
we're
concerned
about
taking
it
up
experimental,
but
a
higher
level.
A
Api
may
not
have
those
concerns,
so
an
API
that
helps
you
preserve
context,
which
is
one
of
the
the
key
use
cases
in
APM's
and
in
other
modules
for
async
hooks
might
not
have
that
problem,
and
so,
let's
have
a
PR
which
adds
that
to
core
that's-
and
this
is
this-
is
the
PR
which
does
that
in
the
issue
itself.
There's
some
some
objections.
Some
discussion
and
I
think
the
the
three
key
questions
in
my
mind.
Are
you
know
one
should
an
API
like
this
be
in
core?
A
A
There
is
that
context
of
run
and
also
I
think
in
domains,
which
is
you
know,
potentially
use
case
for
this.
This
context,
propagation
they've
also
used
the
you
know
some
sort
of
context
to
scope
it.
So
that's
why
the
run
would
make
sense,
and
then
the
third
question
is
around.
So
that's
what
you
know.
A
What
should
the
API
look
like,
and
the
third
question
is
then
there's
a
there's,
a
PR
out
there,
which
adds
3309
59,
which,
as
async
execution
resource
and
that
will
you
know,
allow
allow
a
better
implementation
of
any
of
these
PRS
I
mean.
Do
we
need
to
wait
for
that
to
land
or
not,
I,
think
the
main
concern
you
know
with
waiting
might
be.
A
Is
that
right
now
there's
some
performance
issues
with
that,
so
it's
not
clear
how
long
it
will
take
to
get
that
landed,
and
if
it's
not
going
to
affect
the
actual
external
API,
it
may
not
need
to
be
a
blocker.
If
you
know
the
the
experimental
API
that
this
adds
doesn't
need
to
change.
When
that
comes
in
it
just
gets
better.
Does
it
you
know,
do
we
need
to
link
the
two
together
or
not?
A
A
A
In
terms
no
I
mean
that
there
are
implementations,
although
they're,
like
there's
external
implementations,
I
say
that
people
are
happy
necessarily
with
them
like
those
being
external
like
evening,
so
the
maintainer
of
those
external
ones
would
be
very
happy
if
it
was
something
that
was
more
tightly
integrated
but
I.
Don't
think
technically,
there's
something
that
says
that
the
difference
is.
A
Is
that
like
an
external
module
would
have
to
depend
on
async
ox
or
do
monkey
patching
today,
and
we
don't
really
want
to
make
these
and
cook
something
non
experimental,
so
you're
you
may
not
get
to
a
non
experimental
feature
that
way.
If
you
know
what
I
mean,
whereas
a
higher-level
API,
we
might
actually
be
able
to
make
non-experimental,
even
though
you
know,
we
don't
think
he's
and
cooks
are
necessarily
the
way
in
the
way
or
form
that
we'd
want
them
to
be
forever.
C
C
So
it's
hard
for
me
to
approve
it,
but
I
have
to
I,
do
have
experience
with
continuation
localstorage,
not
necessarily
the
module
but
the
general
process,
and
it's
a
common
problem
for
all
of
the
the
APM
vendors
and
for
some
other
uses
as
well,
and
it's
it's
a
Kuip
of
mechanism
that
needs
coordination
across
the
whole
note
all
of
the
node
ecosystem
and,
as
such,
I
think
it's
a
feature
like
it
is
useful
in
core.
It's
a
little
bit
like
promises
of
what
sorry
not
promises,
domains.
C
C
B
A
A
A
A
You
know
it
sounds
like
people
haven't
necessarily
had
enough
chance
to
look
at
it
yet
does
it
make
sense
to
we'll
leave
it
on
the
agenda
and
revisit
this
again
next
week
to
see
if
we
can
get
people
time
to
look
about
look
at
it
think
a
bit
a
bit
about
it,
and
you
know
at
that
point
we'll
figure
out
what
we.
What
the
next
step
is
in
terms
of
getting
consensus
on
in
core
or
not
in
terms
of
a
general
direction.
I.
C
C
B
E
A
A
I'm,
not
convinced
that.
Will
that
will
be
successful.
We
could
say:
let's
push
it
back
and
have
some
more
discussion
and
talk
about
it
next
week
or
we
could
say.
Well,
maybe
we
should
have
a
vote
or
maybe,
if
not
a
vote,
but
like
a
you
know,
we
could
send
through
an
issue
or
an
email
or
whatever
we
could.
Basically,
you
know
specifically
ask
all
the
TSE
members
to
weigh
in
on
their
you
know,
which
way
they
think
it
should
go.
I.
E
Honestly,
don't
see
why
we
shouldn't
act
swiftly
on
you
know.
You
usually
have
not
in
favor
of
that,
but
this
has
been
open
a
while
everybody
said
what
they
want
to
say
and
I.
Think
it's
pretty
clear.
You
know
I
think
anybody
who
spends
you
know.
20
minutes
with
this
issue
say
is
probably
gonna
have
an
opinion
as
to
whether
this
should
land
it
shouldn't
land
or
oh,
my
gosh
I'm.
Never
gonna
have
opinion
about
this.
E
A
So
do
we
want
to
I
mean
I
can
basically
say:
I
could
send
out
an
email
or
we
could
open
an
issue
basically
saying
you
know
weighing
on.
You
know
whether
you
think
it
should
land
in
core
or
not
or
you
have
no
opinion,
and
you
know
if
we
don't
hear
from
you
in
a
week,
we'll
assume
it's.
It's
no
objection.
So
there's
consensus.
It's
that
reasonable.
E
A
Yeah
I
mean
the
other
issues.
We
can
continue
the
discussion
in
terms
of
what
the
API
should
look
like
and
and
and
that
stuff
it
would
be
good
if
people
jumped
into
the
issue
and
had
more
comments
on
that
front
too.
But
I
think
the
first
step
is
to
get
the
consensus
on
yeah.
Do
we
even
need
to
talk
about
it
because
we're
making
that
decision
of
in
or
out
so
I
guess
it's
most
likely?
I
should
open
an
issue
that
does
that
not
mention
the
TSE.