►
From YouTube: Diagnostics WG meeting 2022-01-25
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
D
B
C
A
Do
you
want
to
introduce
yourself?
I
guess
you
are
joining
us
for
the
first
time.
A
B
Yeah,
I
have
other
it
just
to
to
to
discuss
about.
I
I
think
that
mary
has
expressed
some.
I
don't
know
question
about
if
we
showed
a
list
or
not
thirty
party
tools,
as
a
recommendation
inside
your
recommendation,
so
he
profile
was
recently
landed.
It
makes
some
good
stuff
with
the
memory
through
with
the
flame
graphs
and-
and
I
I
suggest
to
add
it
to
the
to
the
memory
documentation
that
we
are
creating
so
far,
but
I'm
not
sure
about
it.
B
If
we
should
or
not
recommend
30
part
30
part
tools,
so
it's
more
execution.
I
guess.
A
Yeah,
I
don't
see
an
issue
with
the
third
party
tool
as
such.
If
you
look
at
the
listing
of
our
tools,
many
of
them
were
originally
developed
as
third-party
tools,
for
example,
the
diagnostic
report,
or
the
heap
dump
itself,
but
later
got
standardized
or.
A
Inducted
into
the
core,
because
of
various
reasons
such
as
improved
performance,
improved
support,
lts
and
things
like
that,
but
if
the
third
party
tool
is
already
qualified
with
all
those
criteria
there
is.
There
is
no
reason
why
we
should
induct
them
into
the
core,
and
I
don't
see
a
problem.
We
endorsing
them
the
real,
the
real.
D
I
have
a
little
bit
of
a
different
opinion,
kind
of
going
back
to
npm
and
yarn
and
all
the
stuff
we've
had
with
other
third-party
tools.
D
My
only
concern
really
isn't
whether
it
does
the
job
or
not,
because
it
does
more
than
what
people
normally
do.
So
overall
it'll
be
a
net
improvement.
It's
the
looking
over
clinic,
it's
still
controlled
by
near
form
entirely
and
I'm
always
hesitant,
even
if
I
work
at
a
company
to
be
like
use
this
company's
tool.
Even
if
it's
free.
D
D
B
D
D
B
Make
sense
to
establish
some
criteria,
I
mean
if,
if,
if
the
project
is
open
source
and
is
not
copyright
by
any
any
company,
we
can
list
or
something
like
that.
A
A
B
Yeah,
okay,
so
I
will
make
sure
that
all
the
third-party
or
other
dependents
inside
the
clean
key
profiler
is
a
mit
li
sense
set
in
case.
I
will
open
a
pr,
but
also,
I
think
that
might
make
sense
to
update
some
document
just
to
make
sure
that
the
further
I
don't
know
incomes
will
be
restricted
to
this
license.
Agreement.
A
Okay:
next
one
is
file
level,
which
is
document
a
sync
hooks
types
purposes.
B
Okay
yeah,
this
is
also
mine.
I
was
I
wasn't
in
the
last
meeting,
so
basically
I
was
I
was
facing
some
troubles
with
the
sink
rooks,
because
I
need
to
track
some
events,
but
there
are
some
types
that
was
not
documented.
I
mean
there's
only
the
the
type
name,
but
not
the
definition.
What
is
this
about?
D
Seems
fine
as
long
as
we
can
mark
stuff
as
experimental
or
subject
to
change,
I
do
know
people
can
inject
their
own
types
that
are
not
normally
available.
I
don't
know
how
we
want
to
track
those.
B
Yeah,
I
mean,
actually
I
mean
the
async
rooks
types
in
the
documentation
shows
a
lot
of
type
types,
but
those
types
don't
have
some
description.
I
mean,
I
don't
know
what
I
I
know,
what
is
fs
event
wrap.
Do
those,
but
most
of
the
users.
D
D
Status
for
that,
like
our
api
status,
is
the
closest
it
would
be
would
be,
it
would
forever
be
experimental
because
in
any
even
minor
it
could
add
or
remove
properties.
D
B
Just
to
be
clear,
you
mean
that
those
types
in
the
documentation-
it
is
experimental-
I
mean
they
can
well,
they
can
they're,
not
stable.
D
D
D
D
B
Okay,
I
think
that
it's
fine
to
let
it
open,
but
I
mean
don't:
don't
do
any
work
until
we.
I
don't
know
it's
hard,
because
we
don't
have
anything
working
in
this
front
right
now,
right
so.
F
Yeah,
but
personally
I
would
just
be
more
clear
in
the
documentation.
That's
just
define
type
as
like
it
is
just
a
string.
It
is
something
it.
It
could
mean
anything
but
say
like
th
this.
This
is
a
list
of
things
you
might
get,
but
like
it,
it's
just
a
list
of
arbitrary
things.
It
could
be
anything
at
any
time,
so
don't
don't
like
take
it.
D
B
D
F
Problem
is
just
like.
I
don't
think
we
want
to
document
necessarily
exactly
what
all
the
things
are,
just
because
it's
going
to
change
at
any
arbitrary
time
like
there
could
be
a
patch
release
and
something
changes,
and
that
like
if
we
project
this
as
like
this
is
an
api
contract.
That's
that's
a
bad
way
to
be
doing
things,
but
if
we're
like
trying
to
be
clear
that
like
no,
this
is
just
a
bunch
of
labels.
It
could
be
anything
like.
Don't
don't
consider
this
as
api
contract,
then
that's
more.
D
E
D
C
B
So
I
will
remove
it
from
the
agenda
again,
but
I
will
comment
in
the
issue
that
there
are
two
two
main
major
suggestions.
That
is
the
first
one
is
generated
types
based
in
documentation,
but
there
are
some
downsides.
I
mean
I'm
not
sure
if
we
we
want
it,
as
stephen
mentioned
it,
and
the
second
one,
the
second
one
is
pretty
much
simple.
That
is
just
update
the
language
of
the
the
type
documentation
I
mean,
make
it
explicitly
the
that
the
types
might
change,
and
also
it
by
it
might
be
a
custom
type.
A
The
next
one
is
on
the
meeting
time.
Probably
we
can
visit
it
towards
the
end.
We
can
quickly
go
through
the
other
technical
items
if
it
makes
sense
502,
which
is
user
journey
tracking
documentation
again
on
rafale.
A
Okay,
yeah
but
yeah
for
the
for
the
awareness
of
tony.
This
is
one
of
the
work
in
progress
item
for
the
diagnostic
working
group
and
as
you,
you
can
see
the
progress
there
are
items
where
contributions
are
appreciated.
A
So
have
a
look
at
those
review
that
and
ask
questions
directly
in
the
issue,
or
we
can
discuss
that
in
the
next
setting.
Whichever
way
is
convenient
to
you,
okay,.
F
Different
there,
there
hasn't
really
been
any
movement
on
this
for
quite
a
while
now
might
want
to
just
take
it
off
the
agenda
but
yeah
we
we
we
had
like
that
tweet
at
one
point
and
got
like
a
couple
responses
about
it,
but
I
don't
know
if
we
really
got
enough
responses
for
any
useful
idea
of
what
people
are
doing
with
it,
not
really
too
sure
what
the
next
step
is
from
there.
A
A
F
I
don't
know
if,
like
we,
we
we're
kind
of
like
on
on
a
path
before
to
like,
depending
on
the
feedback,
decide
if
we
want
to
just
like
deprecate,
jason,
cook's,
docs,
deprecated
or
like
mark
it
as
legacy,
or
something
and.
A
D
F
Yeah,
there's
there's
a
handful
of
things
that
ace
and
cooks
currently
solves
the
basic
local
storage,
which
is,
which
is
fine.
We
just
need
some
additional
different
apis
specific
to
whatever
the
needs
are,
but
we
need
to
figure
out
what
those
needs
are
and
distill
that
into
the
api.
F
A
A
No
okay,
then
the
last
item
in
the
agenda
is
meeting
time:
five:
zero.
Seven
thanks
for
all
those
who
provided
the
convenient
time
in
the
doodle
I
see,
bradley's
voting
is
not
included
bradley.
Can
you
have
a
look
at
that
and
please
mark
your
convenient
time.
I
will
okay
and
tony
as
well.
If
you
plan
to
attend
the
meeting
on
a
regular
cadence.
E
A
A
I
will
I'll
make
my
observations
in
the
issue
itself
and
we
can
discuss
it
in
the
next
meeting.