►
From YouTube: Diagnostics WG meeting 08-07-2020
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
B
Yeah
I
had
a
session
at
the
collaborative
summits,
I
hoped
and
disgusts
best.
We
have
a
bunch
of
different
hook
systems,
some
some
existing,
some
that
are
emerging
needs
for
things
and
there's
a
bunch
of
overlap
between
them,
so
I
hope
I
hope
to
have
a
session
that
we
could
kind
of
define
what
the
overlap
is
and
where
we
can
unify
some
sort
of
like
API
surface
that
can
be
shared
between
these
components.
B
Reduce
code
duplication
and
have
better
performance
profile
and
that
sort
of
thing
so
yeah
the
the
session
at
the
class
over
there,
someone
said
I
think,
unfortunately,
was
that's
derails,
but
I
wanted
to
try
and
continue
the
discussion.
Just
figure
ups
I
kept
trying
see
if
we
can
put
together
a
list
of
like
what
things
like
need
to
hook
into
where
I'm
like
what.
What
are
the
particular
needs
of
those
hook.
B
Systems
like
I,
know,
I,
there's
several
things
like
FS
hooks
on
and
hugs,
like
ASA
cooks
and
things
like
that
which
their
particular
like
that
they
have
some
particular
needs
like
they
need
to
be
able
to
intercept
when
something
is
being
called.
Some
of
them
need
to
be
able
to
like
stop.
The
call
cancel
the
call
or
something
like
that.
They
need
to
be
able
to
intercept
arguments
in
some
way
or
another.
B
There.
There
was
a
desire
for
like
FS
hooks
to
be
able
to
intercepts
like
calls
entirely,
so
you
could
do
something
like
virtual
file
system
say.
If
you
have
like
a
test
suite,
you
want
to
market
the
file
system.
You
could
do
that.
B
Yes,
there's
basically,
we
have
these
like
similar
barriers,
similar
barriers.
We
need
some
sort
of
hooks
at
to
what
Aysen
cooks
already
provides
just
like.
We
need
something
at
at
the
end
that
point
but
more
powerful
than
what
Asian
cooks
can
currently
do,
and
we
need
something
around
the
callback
but
again
possibly
more
powerful
than
let's
isn't
cooks
can
actually
currently
do
it's
like.
We
want
to
be
able
to
intercept
the
returns,
the
returned
arguments
as
well
from
callbacks.
Let's
say
you
have
like
an
HTTP
request.
You
want
to
pull
out
the
status
code.
B
B
A
Guess,
for
that
matter,
deep
dive
sitting
is
also
a
good
idea,
because
at
this
point
we
are
looking
at
three
looking
at
the
into
the
user
journey
documents
and
see
how
much
coverage
we
do
have.
Is
there
any
realignment
and
that's
required,
and
things
like
that,
so
definitely
maybe
for
the
next
sitting.
If
you
timidly
contend,
we
can
plan
for
that
as
well.
C
C
B
B
B
B
A
A
So
James
has
conducted
I,
know,
J's,
contributor
survey,
some
time
back
and
the
one
which
we
see
in
the
screen
is
a
snapshot
of
relevant
portions
from
that
act,
which
is
applicable
for
the
Diagnostics
working
group.
I'm,
not
sure
how
to
interpret
these
results,
but
just
looking
at
that,
my
first
impression
is
that
it's
a
mixer
kind
of
result,
debugging
test
failures,
40%
say
it's
bit:
annoying
it's
natural
because.
A
The
problem
determination
is
still
not
very
sophisticated,
so
I
would
say
it's
a
it's
a
lightly
with
my
understanding
as
well,
but
this
is
not
giving
an
indication
about
of
what
can
be
improved
or
what
is
the
areas
where
need
to
focus
on,
like
exceptions
or
crash
of
Han?
What
is
the
specific
debugging
scenario
where
there
is
a
major
concern
that
kind
of
a
breaker
up
for
an
insight
is
not
available.
A
How
important
diagnostics
is
for
you
around
35
percent,
say
it's
high-priority
and
35
another
35
percent
states
of
moderately
high
priority,
which
is
a
good
news
which
essentially
means
highlight
of
adoption
and
high
rate
of
corruption
in
serious
and
enterprise
grade
deployment,
because
you
know
only
from
an
enterprise
or
only
on
a
large-scale
business.
Great
deployment.
A
A
A
B
And
what
my
perspective
was
kind
of
been
that's.
I
got
a
lot
of
diagnostics
tools
like
it.
It's
not
really
specific
to
denote,
but
like
dynamic
languages
in
general,
tend
to
not
be
very
good
at
Diagnostics
in
certain
categories
like
tracking
down
memory.
Leaks
is
a
good
example.
It's
if
you
look
at
something
like
Java
or
something
like
that.
You
can
pinpoint
like
exact
memory.
B
Locations
of
things
like
this
memory
is
being
held
by
this
thing,
whereas
in
a
dynamic
language
like
you
get
a
memory
leak
and
it
can
be
quite
a
pain
to
track
down,
sometimes
like
at
best
you'll
usually
get
like
I
have
a
bunch
of
this
type
of
thing
in
memory,
I,
don't
know
what
like
each
thing
contains
or
any
of
that,
but
it's
just
less
less
user-friendly
trying
to
track
that
down
and
I.
Don't
know
if
there's
a
whole
lot.
We
can
do
about
that.
A
A
So,
looking
at
the
comments
which
James
poster
one
is
the
inconsistency
in
various
mechanisms-
I
guess
this
is
something
which
we
at
least
in
theory,
recognized
already
and
are
trying
to
address
through
the
user
journey
based
initiative.
Have
the
tooling
initiative
in
the
agnostic
working
group
should
be
aligned
with
the
user
journey
and
that
philosophy
is
going
to
address
this
aspect
of
inconsistency.
A
A
A
A
We
could
act
on
it
if
there
is
an
enterprise
user,
a
user
who
is
using
node.js
on
a
lot
of
deployments,
large-scale
deployments
and
can
come
up
with
this
observation.
Probably
that's
a
good
driver
for
us
to
act
on
it,
I'm,
not
saying
that
it's
not
true,
but
to
give
it
the
due
priority
for
acting
on
it
or
looking
at
what
are
the
performance,
inhibitors
and
trying
to
find
you
an
optimized?
A
A
Continued
lack
of
diagnostic
use
cases
to
help
drive
continued
development,
yeah
to
an
extent
I
agree.
There
is
no
noon
diagnostic
use
with
use
cases
coming
as
it
is
bird,
not
sure
that
how
much
it
is
a
problem
for
the
working
group
or
the
echo
system
as
such.
If
there
is
no
diagnostic
use
cases
new,
that
means
they
use.
The
user
base
is
happy.
Having
the
workload
is
running,
fine
and
nothing
new
is
identified.
A
All
the
problems
are
well
scoped
within
the
existing
symptom
types
and
follows
the
same
troubleshooting
and
debugging
scenarios
and
the
last
one
is
instability
or
bugs
in
the
diagnostic
tool.
In
yes,
we
need
to
align
all
the
tools
to
the
same
standard,
same
quality
as
that
of
the
node.js
code.
Probably
we
need
to
align
the
maintenance,
the
support
release
cycles
of
the
Endo's
tools
along
side
with
the
nodejs
core
itself,
and
that's
also
something
which
is
called
addresses
and.
B
B
B
A
You
so
probably
I
will
keep
this
item
in
the
agenda
for
next
week
as
well,
next
meaning
the
method
when
we
pick
this
up
for
the
regular
working
group
so
that
we
have
other
members
like
Mickael
materials,
and
then
we
can
probably
have
a
discussion
around
what
should
be
the
actionable
items
coming
out
of
this
survey.
This
feedback.
A
A
Anton
Valley
presented
the
EBP
of
capability
feature
in
the
working
group
couple
of
weeks
back,
probably
a
couple
of
months
back
and
then
the
idea
was
to
run
it
through
the
user
journey
to
figure
out
where
the
capability
stands
in
terms
of
the
the
kind
of
symptoms
or
the
kind
of
diagnostic
scenarios
in
which
this
can
be
applied.
And
then
how
do
we
document
that?
And
or
how
do
we
look
at?
What
are
the
specific
capabilities?
We
want
to
focus
on,
and
things
like
that,
we
were
never
able
to
do
that.
A
C
I
also
meet
here
for
next
step
in
I,
have
some
images
on
Agilent
with
the
next
day
39
meetings,
so
it
will
be
discussed
on
the
case
in
a
meeting
on
July,
20th
and
I
change
the
to
adjust
the
issue
that
we
have
corrected
since
the
last
kids
they're,
not
making
entry,
so
I
would
write
to
request
for
reviews
on
the
new
proposal.
If
there
is
anyone
interested
in
the
facing
local
and
it
from
the
talks,
I
mean
it
must
good.
C
So
the
major
changes
we
have
presented
last
time,
I
can't
summarize
that
we
have
more
hooks
mechanism
from
the
photo
and
there
will
be
a
merely
value
change.
It
is
non-local,
so
the
the
listener
can
do
a
limit.
Is
that
all
the
things
we
have
compared
to
the
competitors?
Globe,
pasting
hooks
and
so
I
would
like
more
reviews
on
the
proposal.
If
they're.
C
C
D
A
A
A
C
C
A
B
As
the
don't
know,
if
there's
too
much
to
it,
but
we
basically
created
that
issue
at
the
time
and
find
a
path
to
Mason
cooks
becoming
stable,
but
I
think
over
time.
Like
we
kind
of
came
to
the
conclusion,
that's
guessing
hooks
itself,
maybe
you
should
never
be
stable
or
if,
if
it
does
get
stable,
someday,
there's
like
a
bunch
of
things
about
it,
this
would
have
to
change
that
currently
exposes
the
resource
directly,
which
I
guess
it's
exposing
internals,
and
we
don't
want
to
make
any
promises
about
what
internals
look
like.