►
From YouTube: Diagnostics WG meeting Feb 8, 2022
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
A
A
C
I
think
that
mostly
if
we
have
a
rotating
meeting,
we
should
have
more-
I
don't
know
issues
or
something
in
the
agenda
for
that,
because
right
now
we
have
few
items.
C
I
think
I
planning
to
finish
the
the
user
user
journey
documentation
soon
and
then
perhaps
we
can
go
back
with
the
deep
dive
meetings
to
make
it
accessible
for
everyone.
So,
but
at
this
time
I'm
not
sure
about
the
current
current
items
for
a
rotating
meeting.
A
And
that's
true:
there
isn't
too
much
development
for
feature-wise
that
we're
doing
right
now,
at
least
in
the
meetings.
A
A
Yeah,
so
I
guess
all
my
notes
are:
we
could
try
to
pick
between
a
rotating
meeting
or
canceling
if
it's
between
rotating
meeting
or
canceling
I'd
personally
prefer
just
cancelling
meetings.
B
I
I
would,
I
would
be
okay
with
the
canceling,
but
we'd
probably
want
to
replace
that
with
like
not
just
like
interacting
on
the
issues,
but
we
should
try
to
still
have
like
a
time-sensitive
check-in
issue
or
something
just
like
continuing
the
same
like
every
couple
weeks
or
something
have
an
issue.
That's
just
like
yeah
everyone
check
and
is
like
not
having
actual
video
call
meetings.
Still
fine
is
like
status
updates.
C
Yeah,
I
think
that
in
this
script
for
the
creation
of
the
meeting,
he
will
be
probably
have
some
conditional
check-ins
for
at
least
three
or
more
meetings,
or
at
least
actually
a
new
flag.
That
is
required,
a
cow
to
discuss
that
in
some
situations,
the
video,
the
video
cow,
is
really
really
interesting.
You
know
to
fix
some
something.
C
Yeah,
like
each
schedule
with
based
in
the
necessity
I
mean
if
we
have
more
turn,
I
don't
know
three
three
items
to
be
discussed
that
need
to
be
in
the
video
card.
We
schedule
a
cow
to
fix
it
in
a
single
cow
instead
of
a
schedule
every
period,
even
if
we
don't
have
items
enough
for
that.
C
C
B
We
could
also
just
leave
the
meetings,
basically
as
they
are
and
have
like.
We
already
have
like
the
issue
is
created
for
it
like
a
while
before
we
could
just
have.
Whoever
is
going
to
be
the
like
lead
of
the
call
check
in
like
a
day
before
and
ask
like
do.
We
need
to
have
this
like
if
enough
people
don't
say
like?
Yes,
I
want
to
actually
have
a
call,
then
just
don't
have
it.
A
B
A
A
This
is
identifying
async
use
cases
beyond
async
local
storage.
I
don't
does
anybody
have
anything?
It's
still.
A
So
I
did
talk
with
our
side
of
things
at
work
and
at
least
her
data
dog's
current
path
forward,
because
the
thing
we
need
is
not
really
possible.
Currently,
in
async
hooks,
we
think
it's
fine
to
effectively
stop
using
async
hooks
if
async
local
storage
becomes
viable.
A
A
C
B
C
Okay,
yeah:
I
think
that
you
know
the
clinic
use
it
just
to
to
map
and
provide
feedback,
but
also,
I
think
that
would
be
great
to
to
create
a
tweet
in
order
to
get
more
feedbacks
from
my
painters.
A
C
Yeah
yeah,
actually,
we
are
only
enabling
it
to
track
every
cow
and
show
it
it
is
not.
Production
is
not
to
be
running
their
production,
adjusted
to
smart
rides.
I
did.
B
We
actually
need
the
functionality
in
v8
for
profiling.
I
kind
of
want
us
to
actually
just
build
a
thing.
C
C
Yeah,
actually,
I
did
an
experimental
version,
just
a
performance
in
comparison
by
enable
async
rooks
in
old
clinic
using
the
v14
and
also
in
16,
and
the
16
was
way
way
better,
because
the
I
think
rooks
was
not
fired
enough
in
the
prior
version.
I'm
not
sure
if
it
was
a
v8
change,
but
it
was
firing
a
lot
of
events.
C
Most
of
them
is
duplicated,
so
we
could
investigate
it
and
I
don't
know,
but
in
order
to
to
I
I
mean
I
think
that
this
this
issue
is
blocked
for
two
major
reasons:
the
first
one
actually
for
a
single
major
reason.
That
is,
we
don't
have
enough
feedback
to
make
to
to
deprecate
the
sync
rooks
right.
C
We
will,
we
only
will
get
feedback
from
maintainer.
Mostly,
I
mean,
I
think,
that
around
time
the
preparation
would
be
too
too
risky,
or
you
know
too
annoying
for
users,
but
if
we
create
a
tweet
or
something
in
the
node.js
account,
we
could
get
more
use
cases
edge
cases
or
something
like
this.
A
A
C
A
Would
that
would
certainly
give
you
feedback
at
least
my
history,
with
things
like
es
modules
and
requesting
feedback
from
newsletters
from
twitter,
wherever
you
don't
get
much.
A
That
makes
but
the
moment
we
put
warnings
on
things
in
es
modules,
we
got
actual
feedback.
We
got
the
love,
I
guess
people
simply
if
it
is
not
showing
up,
they
don't
care
even
maintainers.
C
C
But
but
I
I
mean.
C
What
is
the
problem
to
to
do
not
deprecate
it,
but
instead
make
other
a
wiring
in
the
the
documentation
of
the
sync
groups.
C
But
my
question
is:
we
should
duplicate
it
to
make
a
single
local
resource
stable
or
we
can
or
those
things
is
not
related.
We
can't
make
a
single
local
storage
at
no
experimental,
even
if
the
syncrook
is
not
duplicated.
A
So
right
now,
async
local
storage
is
not
experimental.
Only
a
couple
methods
are
on
it.
A
Async
local
storage,
I
think,
has
a
few
that
aren't
the
class
is
not
disable
is
experimental,
enter
with
is
experimental,
exit
is
experimental,
so
we
have
git
store
and
run
are
stable.
B
B
C
Okay,
so
so
the
idea
is
just
to
replicate
the
sync
groups
because
of
the
performance
issues
and
other
edge
cases.
C
B
Like
it
actually
makes,
I
think
local
storage
slower
than
it
could
be
like.
I
think
glucose
storage
actually
only
uses
a
limited
subset
of
asin
cooks,
it's
like
if
we
can,
just
like
deprecate,
cooks
or
like
remove
it
entirely.
We
can
make
facing
global
storage
just
more
directly
connected
to
the
parts
that
it
actually
needs
to
and
probably
make
it
quite
a
bit
faster
and
yeah.
B
Just
the
whole,
like
safety
like
exposing
internals
like
we've,
had
a
security
push
for
node
over
the
last
couple
years
like
trying
to
lock
down
interfaces
and
things
like
that,
and
that
doesn't
really
help
us.
If
we
have
this
other
api
just
leaking
all
over
the
place,
so
it
would
be
good
to
get
rid
of
like
plug
that
big
hole.
Basically,.
A
And
it's
not
just
performance
from
cpu-wise
like
memory
is
always
a
problem
like
so
whenever
you
do
stuff
with
async
local
storage,
for
example,
every
async
local
storage
that
you
create
actually
has
to
propagate
independently
every
time.
So
every
single
async
hook
event
that
fires.
It
assigns
a
property
for
every
currently
output,
global
storage
and
stuff,
like
that.
C
Okay,
I
will
take
a
look
with
more
calm
in
the
node
clinic
and
bubopra,
specifically,
which
is
the
tool
that
makes
use
of
syncrooks
and
check
if
I
can
make
it
with
a
cyclical
storage.
A
Yeah
and
we're
not
necessarily
out
of
ideas
here,
so
one
thing
that
we're
doing
a
data
dog
is
we're
using
diagnostics
channel
instead
of
async
hooks
for
things,
and
so
that
may
just
mean
we
need
to
put
diagnostic
channel
events
directly
in
node's
core,
if
that
may
be
a
workaround
to
avoid
async
hooks,
for
example,.
C
Yeah,
if
you
remember
correctly,
we
are
enabling
enable
async
rooks,
because
we
are
using
the
trees,
trace
events,
flag
or
v8,
and
then
it
triggers
their
sync
hooks
in
its
event.
B
C
Okay,
yeah,
I
I
can
look
at
it
with
some
day.
I
mean
I
think
this
week
or
the
next
one.
I
will
probably
be
talking
with
the
node
clinic
members
and
then
we
guess
a
bit
of
work,
but
okay.
A
Yeah,
if
it's
in
v8
it'll
be
less
costly
as
well,
because
it
won't
have
to
jump
between
c
plus,
plus
and
javascript
as
much.
For
example,.
B
Yeah
I've
been
wanting
to
have
essentially
the
idea
that
I've
had
is
to
make
an
equivalent
of
like
there's
javascript
function
and
then
there's
bound
function.
B
B
It
might
be
worth
talking
about
that
offline
actually,
but
yeah.
I
I
need,
like
that
same
thing,
for
profiling
right
now.
Basically,
so
I'm
currently
actually
using
async
hooks
to
like
wire
that
up
externally
through
some
horrible
hacks,
but
basically
I
have
like
an
asynchronous
storage
and
async
hooks
using
the
like,
before
and
after
trigger
to
like
pass
the
current
state
of
basic
storage
into
something
else
yeah.
I
I
need
that
for
profiling,
we're
trying
to
pass
labels
through
on
each
sample.
A
Okay,
do
we
have
anything
else?
It
seems
like
we're
more
just
chatting
at
this
point.
We
don't.
We
just
are
saying:
we
need
more
feedback,
we
need
to
look
into
what
clinic
is
doing
if
they
could
use,
maybe
diagnostics,
channel
or
trace
events
directly
without
async
hooks
and
async
local
storage
instead
of
asynch
hooks,
and
then
we
don't
really
have
a
good
way
to
get
more
feedback,
but
we
could
add
a
warning.
So
I
don't
want
to
do
that
until
we
hear
back
from
clinic.
A
B
Not
sure
we
have
like
an
immediate
task
to
do
at
least
in
nodes,
yeah,
just
wait
on
node
clinic
and
then
decide
what
to
do.
B
A
Okay,
I'll
put
that
in
my
notes,
are
you
going
to
do
that
raphael.
A
With
a
single
star,
just
without
async
looks
okay,
what
is
the
real
thing?
It
is
not
about
replacing
async
hooks
with
local
storage.
It
is
about
not
using
async
hooks
yeah.