►
From YouTube: 2022-03-22-Diagnostics WG 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
So,
basically,
yeah.
Basically
what
this
means
is.
We
have
the
list
of
tools
that
we
claim
to
support
and
there
are
different
levels
of
maturity,
stability
that
we
assign
to
each
of
this
list
each
of
these
tools
in
the
list
based
on
some
assessment.
We
did
some
time
back
so
the
the
question
is:
should
we
look
at
the
list
as
a
team
and
validate
that
their
status
is
same
or
they
need
any
change,
positive
or
negative
change,
based
on
various
parameters
that
we
listed
for
the
maturity
status.
A
So
in
in
conjunction
with
that
code
that
one
triggered
tony
to
you
know
open
a
pr
in
the
code,
repo
to
add
the
trace
gc
tool
to
the
support
tooling
list.
B
Yes,
I
think
that
the
first
time
I
read
the
issue
and
I
discovered
the
list-
I
was
asking
why
this
tool
wasn't
mentioned
and
then,
when
we
discuss
a
bit
with
with
jairish,
I
guess
maybe
why
it
wasn't,
because
it's
related
to
v8,
but
from
my
point
of
view
it
was
even
if
it's
just
integrated
in
the
gs.
B
We
maybe
have
lines
of
code
that
cover
this,
and
if
there
are
line
of
code
that
cover
the
integration,
we
should
cover
it
by
test
and
if
it's
possible
from
to
use
it
from
a
node.js
usage,
maybe
we
should
document
it.
Maybe
I
have
a
guide
to
make
it
easier
or
make
the
adoption
easier,
and
then
I
thought
that
it
could
interesting
to
have
it
in
the
list,
but
I
fully
understand
if
it's
not
the
case,
this
was
maybe
a
naive
approach
that
I
get
there
and
in
nutshell:
that's
it.
A
A
Some
of
the
v8
flags
have
been
elevated
to
you
know
not
just
documentation.
C
Yeah,
I
would
say
the
same:
there
is
two
flags
that
I
not
entirely
sure
if
it
is
inside
v8,
but
is
there
the
profiling
one,
the
dash
dash
prof,
I'm
not
sure
if
it
is
inside
the
v8,
but
we
we
have
added
to
the
tier
three.
A
Okay
yeah,
so
as
a
working
group,
I
believe
the
the
question
we
should
be
asking
and
answering
is
what
type
of
flags
based
on
what
conditions
or
based
on
what
qualifiers.
We
should
be
elevating
to
the
node.js
documentation.
A
Because
this
question
will
definitely
come
from
the
core
repo
when
we
add
flags,
so
maybe
some
some
of
the
pr's
will
pass.
Some
of
them
will
have
this
question.
So,
if
having
a
clear
guidelines
on
what
is
the
qualifying
criteria
for
v8
flags
to
be
called
as
first
class
tools
and
to
be
listed
in
the
support
tools
as
well
as
documented?
A
Is
it
based
on
the
perceived
usability
in
the
field
or
based
on
unique
value?
These
flags
are
providing
these
tools
are
providing.
B
B
I
think
that
it
should
be
a
part
of
the
documentation
and
I
think
I
don't
remember-
maybe
I'm
wrong,
but
I
try
to
find
documentation
on
the
trace
dc
itself
from
v8
and
I
didn't
find
anything
so
maybe
it'd
be
nice
to
because
I
will
understand
if
there
are
an
existing
documentation
in
the
community
and
we
could
redirect
people
there.
But
I
don't
think
that
it's
the
case.
Maybe
I'm
wrong.
I
should
probably
double
check,
but
before
raise
the
pr
I
check,
I
think-
and
I
found
nothing.
D
In
my
mind,
I'm
not
sure,
like,
I
don't
think
it's
the
documentation.
Part
is
an
interesting
aspect,
but
it
I
don't
think
that
necessarily
is
directly
related
to
what's
in
the
table,
although,
like
I
guess
where
I'm,
where
I'm
like,
it's
not
directly
related
to
the
table
and
whether
the
documentation
is
in
the
node
core
documentation
or
there's
some
other
documentation
shows
how
to
use
it.
D
I'm
not
sure
that
would
affect
it
being
in
the
table
or
not.
It
might
be
good
to
have
this
call.
I
don't
know
if
like
well
documented,
is
probably
something
that,
like
as
the
tiers
go
up,
you
would
like
to
have
better
documentation,
it'd
be
more
like.
Is
it
reasonable
for
us,
like
tier
one,
we
basically
say
we're
going
to
have
tests
and
always
be
working,
so
it's
like
the
trace
gc
functionality,
something
that
would
make
sense
for
us
to
have
a
test
of
in
node
and
validate
that.
A
A
A
A
A
Anybody
have
any
opinion
whether
we
should
do
that.
We
shouldn't
be
doing
that.
A
So
the
the
benefit
of
doing
that
is,
if
we
see
that
this
there
is
a
specific
tool
which
is
which
is
good.
We
think
it
is
good,
but
it
is
not
listed
in
the
list
in
the
support
list,
which
essentially
means
it
doesn't
have
enough
test
coverage
in
the
in
the
node.js
test
pocket
and
we
are
not
promoting.
We
are
not
giving
its
new.
C
Yeah,
I
think
that
probably
would
be
great
before
making
this
assumption
as
us,
as
the
group
assumption,
we
check
all
the
the
the
current
list
that
we
have
and
see
if
we
see
some
educate
or
check
if
there
is
some
tool
that
is
not
is
no
longer
usable
windows
in
this
in
this
list,
you
know,
I
feel
that,
before
making
those
assumptions,
it's
better
to
check
the
current
list
and
make
it.
E
D
C
Yeah,
I
agree,
I
see
some
some
tools
that
is
not
yet
classified,
but
but
it
is
mostly
because
this
document
was
created
some
some
some
years
ago
or
some
months
ago.
It's
a
maybe
it's
worth
it
to
revisit
and
and
check
how
it
goes.
A
C
C
I
think
that
yeah,
I
think
that
would
be
great
to
do
the
same
thing
that
we
did
for.
I
forgot
the
two,
but
the.
C
No,
not
not
not
this,
but
basically
we
create
an
issue
for
each
eat.
One
of
those
tools
add
to
the
agenda
and
then
we
we
goes
through
through
each
of
this
item
and
then
we
close
during
the
meeting
and
then
it
goes
to
to
the
other
meeting.
If
it
remains
you
know,
so
maybe
for
instance,
we
create
an
issue
in
the
repository
for
the
node
report
that
is
not
yet
classified,
and
then
we
we
can
do
a
synchronous
execution
in
the
issue.
But
in
the
meeting
we
we
basically
make.
A
C
I
think
that
we
can
add
all
the
items
in
the
meeting,
even
if
the
the,
if
the
time
overlaps
we
just
keep
to
the
next
to
the
next
meeting.
You
know
because
some
meetings
we
will
we
may
take-
and
I
may
take-
I
don't
know
five
minutes
to
to
solve.
You
know.
A
A
C
Yeah,
maybe
it
would
be
worth
it
to
also.
I
don't
know
if
there
is
a
way
to
to
give
a
priority
list,
but
basically
we
will
add
a
lot
of
issues
and
add
to
the
agenda.
It
means
that
if
you,
for
instance,
stephen
create
a
new,
a
new
request
and
we
need
to
discuss
it,
it
will
be
in
the
in
the
last
as
a
last
item
and
probably
will
be
skipped
because
there
is
a
lot
of
items
in
the
agenda.
C
So
maybe
we
should
create
a
new,
a
specific
list
for
for
those
for
that
material.
So
maybe
maybe
we
can.
We
should
create
that
yeah.
We
should
create
just
one
one,
one
issue
at
just
one
issue
to
the
agenda
and
the
other
ones
we
don't
add,
and
then
we
make
sure
that
we
pass
through
those
items.
C
A
Okay,
the
the
the
problem
we
are
trying
to
discuss
is
suppose
there
are
50
tools
and
if
we
add
labels
to
each
of
them,
we
will
have
50
issues
lined
up
and
if
we
pick
up
the
first
item
and
discuss
and
find
some
actions
out
of
it
and
we
implement
the
action
in
the
form
of
a
pr
and
we
want
to
discuss
in
the
following
meeting:
will
that
pr
appear
in
the
bottom
of
the
list?
Or
is
there
an
evidence.
A
A
C
I
think
that's
fine,
then
just
looking
to
the
docks
in
the
in
the
google
docs
this
this
minutes
looks
like
the
node.js
pls
will
appear
in
the
first.
So
no
problem.
A
A
Yeah,
so
this
should
be
removed
and
closed
meeting
time
again.
A
507
the
tricky
part
thanks,
everybody
who
logged
in
your
convenient
time,
though
it's
little
little
strange,
we
have
the
convenience
of
everybody
and
if
you
can
scroll
to
the
last
command
in
the
issue,
we
have
two
slots
that
shows
the
only
or
the
best
possible
way
for
running
this
meeting.
A
A
A
A
A
A
A
Yeah,
for
example,
in
this
meeting,
we
discuss
something
and
we
take
a
call
through
consensus,
so
we
already
took
three
or
four
decisions
based
on
consensus
now
that
how?
How
will
that
work?
If
the
meeting
is
split
into
two
time
slots
with
two
different
set
of
people.
G
I
I
I
think
we
just
need
to
like
capture
like
what
the
consensus
is
in
that
meeting
and
then
record
that
in
a
github
issue,
and
let
them
like
use
that
to
augment
their
own
consensus
in.
Like
the
next
meeting.
D
G
Yeah,
like
I
like
personally,
I
I
think
in
our
video
calls.
We
shouldn't
really
be
making
hard
decisions
we
should
like
this
is
mostly
just
a
discussion
space
to
like
get
gets
synchronized
on
things
essentially,
but
like
any
like
actual
difficult
decision
making.
I
think
we
should
be
bringing
more
to
the
community
to
make
a
github
issue
and
leave
it
open
for
a
while
to
make
sure
everyone
has
a
chance
to
weigh
in
if
they
want
to.
G
Making
making
decisions
in
a
meeting
like
this
is
like
a
little
like
exclusive
like
if
someone
like,
if
someone
wants
to
join,
they
can
join.
But
I
I
don't
feel
like
we're
particularly
clear
that
that's
the
case
and
can
be
kind
of
intimidating
joining
a
video
call
with
a
bunch
of
people.
You
don't
know.
B
So,
for
example,
if
we
in
the
current
meeting
issue,
we
could
then
write
down
there
all
the
decision
or
ids
that
we
put
there
and
let
the
other
group
check
them
and
validate
them
or
could
have
the
opportunity
to
have
a
war
on
them.
B
Maybe
because
I
I
I
thought
that
we
have
an
issue
for
the
meeting
and
there
there
are
pr
for
the
note
meetings
and
they
are
not
linked
and
maybe
could
help
if
we
could
have
a
link
to
not
meeting
to
left
and
just
mention
it
in
the
beginning
of
the
next
meeting
quickly.
Five
minutes,
no
more
and
just
let
people
be
aware
of
the
decision.
A
D
E
D
D
D
A
D
A
A
Yeah,
so
what
I
wrote
is
correct,
but
then
its
translation
gets
changed
to
people
who
has
the
utc
the
dst
changes.
F
A
D
D
No,
it
moved
that
moves
too,
so
yeah
there
would
be
some
conflicts,
but
I
think,
like
everybody,
there'd
be
some
conflicts
away.
Yeah.
A
D
A
D
C
A
F
A
Okay,
so
let's,
let's
all
go
through
the
list
again
and
if
you
can
do
a
thumbs
up
in
the
issue.
If
you
are
okay
with
the
current
timings,
then
we
can
actually
decide
on
the
logistics
for
running
the
meetings.
G
So
not
really
any
updates
there.
Since
the
last
time
I
I
have
started
a
like
semi-related
experiments,
but
not
entirely.
I'm
trying
to
re-implement
implement
async
local
storage
in
v8,
but
basically
I
oh,
I
have
a
design
that
should
be
quite
a
bit
faster
than
going
through
asincocks
and
also
putting
it
in
v8.
G
So
I
I
have
a
specific
need
for
it.
That's
a
feature
I'm
working
on.
Essentially,
I
need
to
be
able
to
get
the
asymptotical
storage
state
when
a
cpu
profile
sample
is
captured,
so
I'm
I'm
trying
to
set
it
up
so
that
we
can
basically
capture
just
like
all
storage
state
whenever
a
cpu
profile
is
captured
and
then
have
like
an
interface
to
like
evaluate
that
back
into
what
the
storage
data
is.
G
Which
I'll
just
share
in
the
chat?
It's
still
like
in
progress
not
entirely
working
yet
oops?
That
should
be
that's
a
direct
messaging.
G
G
The
basic
idea
is
just
using
like
v8
style
scopes
like
handle
scope
and
things
like
that.
G
But
yeah
still
still
working
on
that,
so
don't
don't
expect
it
to
be
in
actual
functional
state
right
now.
It
partly
works,
but
there's
still
lots
of
context
loss
issues.
I
need
to
work
on.
B
G
G
G
It
can
be
helpful
to
just
do
it
that
way,
so
you
can
kind
of
like
test
the
test,
the
concept
for
the
gains-
okay,
just
yeah
like
I
I
I
would
want
to
like-
make
sure
that
it
like
the
performance
is
like
at
a
level
that
we're
happy
with
before.
I
just
go
to
land
this
and
kind
of
hard
to
know
that
until
it's
actually
in
node-
and
you
can
play
with
it.
G
A
G
C
So
I
will
create
the
issues
for
the
the
tools
during
the
week.
Then,
okay,
we
can
discuss.