►
From YouTube: 2022-08-23 - 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
Okay,
we
are
live,
I
believe
yes,
we
are
so
welcome
everybody
to
the
node.js
diagnostic
working
group.
Oh
good.
I
think
that
before
before
going
to
the
agenda,
does
anybody
have
any
announcement.
A
So
the
first
item
in
your
agenda
is
to
discuss
possible
agenda
items
for
the
collab
summit
that
you've
been
doubling
in
the
next
mall.
Actually
two
mobs.
A
Do
you
wanna,
do
you
have
anything
in
mind?
Let
me
promote
michael
to
discuss
alien,
do
do
we
know
who's
going
to
be
there
like
influence
yeah.
I
think
it
will
be
me.
Tony
anton
michael
will
be
there
as
well
for
the
club
summit.
Yes,
girish,
you
you
go.
A
Okay,
so
most
of
us
right,
okay,
I
think
that
one
thing
that
I
would
like
to
discuss
in
the
in
the
summit
will
be
the
the
addition
of
ebb,
evp,
app
support
and
node.js
actually
internally
at
near
form,
I'm
creating
a
proposal
with
my
leader
to
to
give
me
time,
or
at
least
to
the
company
time,
to
work
directly
on
that
we
are
willing
to
that.
This
is
going
to
be
a
good
future
or
observability
tools
in
node.js
and
even
for
diagnosing
the
application
production.
A
So
we
really
understand
that
this
is
a
a
norm
or
something
that
we
need
to
working
on
in
order
to
improve
that
consistent.
So
this
is
one
of
the
things
that
I
really
would
like
to
discuss.
Next
steps
current
support,
I
know
that
we
have
a
few
traces
in
the
current
node.js
source
code.
We
can
intercept,
but
I
mean
we
need
to
to
understand.
Also
what
is
the
the
the
benefits
of
adding?
I
I
don't
know
I
static
probes
and
each
cheeks
of
of
the
event
loop.
For
instance.
A
C
Yeah,
I'd
love
to
have
it
the
solid
conversation
about
that
and
sort
of
document.
All
the
ask
one
yeah
document,
but
just
get
some
thoughts
about
it.
I
would
be
good.
I
think
a
lot
of
the
conversation
is
going
to
stem
in
terms
of
what
are
the
roles
and
responsibilities
of
node.js
as
a
platform
across
the
different
across
the
different
operating
systems.
C
There's
always
been
attention,
I'm
going
to
call
it
that,
in
terms
of
what
and
for
historical
reasons,
in
terms
of
what
capabilities
we
have
on,
but
there's
a
lot
happened
in
the
dynamic
tracing
world.
Since
I
know
it's
landed
in
windows,
obviously
zbpf
the
other.
The
other
unity's
have
equivalents
as
well,
so
vbsd
has
dtrace
and
we
must
obviously
draw
the
whole
initiative
yeah
and
because
my
personally,
my
there's
always
been
a
field
that
we're
writing
capabilities
like
that.
C
We
need
to
write
the
tooling
that
goes
with
it
and
I
don't
think
we
do.
I
just
think
we
need
to
provide
the
entry
points
and
let
it
all
happen,
but
the
challenge
with
that
is-
and
I'd
love
to
talk
to
james
snell
about
this.
But
the
challenge
I
think
we've
had
is
the
folks
that
go
away
and
write
the
tooling,
don't
look
after
the
probes
in
the
source
and
that's
what
we
need
to
dive
into
the
detail
of.
I
think
and.
D
I
think
a
key
factor
in
the
discussions
and
at
least
in
the
past
discussions
were
around
maintaining
those
probes
and
the
overhead
of
maintaining
them
in
core
like
if
it
was
free
to
get
them
in
then
everybody
would
be
like
well
sure,
but
I
think
it
was
like
the
very
first
diagnostic
summer
summit.
It
was
kind
of
like,
should
we
rip
all
these
out
because,
like
they're
a
pain
and
nobody's
looking
after
them
right,
so
that's
the
key
I
think
thing
to
try
and
figure
out
is
like.
D
A
Yeah
there's
one
thing
that
I
mean
really
annoy
me
yeah
and
I
believe
stephen
can
go
deeper
than
that
is
that
you
know
when
you,
when
you
are
working
in
a
real
world
application
and
you
need
to
measure
performance.
You
normally
include
a
apm
for
that
and
it's
a
paradox
because
when
you
add
apm,
it
drops
your
performance
so
to
to
to
to
measure
your
performance.
You
are
basically
cutting
30
percent
of
your
performance.
A
Actually
we
did
a
research
in
the
past
and
usually
the
apm
adds
20
percent
of
overhead
in
your
code,
depending
on
the
application,
at
least
the
i83
application.
So
this
is
a
lot
just
for
measurement.
You
know,
so
I
believe
that
including
it
as
a
evp,
app
and
separate
process
would
certainly
be
a
game
changer.
C
There
was
some
initial-
I
don't
know
if
we
want
to
save
it
for
then,
but
we
should
definitely
have
a
catch
up.
I
don't
know
if
kane's
going
to
make
it
actually
and
but
kaine's
proposal
of
putting
the
debug
helper
into
rewrite
aspects
of
ll
node
to
make
it
more
supportable.
C
C
Obviously,
we've
got
a
lot
of
focus
on
the
moment
like
looking
at
the
pr
like
the
pr
is
just
inches
away
from
landing.
So
I
think
we'll
have
something
called.
How
are
we
going
to
make
sure
that
we
don't
get
into
the
similar
situation
where
we
all
walk
away
and
say
great
job
and
in
two
years
time,
and
it's
back
to
where
it
was,
you
know.
A
So
I
will
include
it
as
next
years
of
ll,
node
yeah.
D
In
one
one
very
concrete
thing-
and
you
can
correct
me
if
I'm
wrong
but
like
the
challenges
I
understand-
is
that
for
each
version
of
node
there's
some
changes
that
are
needed
to
keep
it
going
right
and
if
we
don't
have
people
doing
that,
then,
like
you,
get
node
18
and
it
doesn't
work
right.
So
an
interesting
topic
I
think,
would
be
like
what
can
we
do
to
simplify
that
automate?
It
you
know,
make
it
more.
D
I
don't
know
part
of
regular
the
regular
flow
of
the
work
or
either
it's
like.
How
do
we
address
that
challenge
that,
like
for
every
release,
something
had
to
happen
and
right
now
it's
pretty
ad
hoc
right
like
it
depends
on
somebody
saying:
oh,
I
know
that
needs
to
happen.
Let's
do
it
versus
it
naturally
happening
happening
out
of
the
regular
product
release,
whatever
flow
things
right,
yeah.
D
C
That
there's
some
it'd
be,
and
I
think
this
actually
came
up
on
the
ll
no
call.
So
there
was
certain
processes
catches
like
where
we
they
looked
for
changes
in
the
va
engine
and
bubbled
them
out,
but
even
when
they
did
that
nothing
happened.
So
I
think
we
need
to
learn
from
those
those
experiences
to
make
sure
it's
a
little
more
concrete.
C
I
mean,
ultimately,
what
would
be
really
good
is
if
we
could
fail
releases
based
on
their
load,
not
being
ready.
A
Yeah,
I
believe
we
probably
you
need
discuss
a
bit
about
like
any
kind
of
refactor
in
the
ll
node,
to
make
it
more
easier
for
newcomers,
at
least
because
you
know
we
can
learn
it
right
now.
But
if
someone
goes,
I
don't
know,
leave
the
project
or
doesn't
wan.
I
don't
want
to
to
keep
going
with
this
one.
A
So,
okay,
yeah
nextly
next
years
of
error
node,
was
added
a
second
talk,
which
one
I
mean
in
our
agenda.
We
have
the
user
journey
tag
tracking
documentation.
We
are
moving
with
it.
I
mean
slowly
very
slowly,
three
years
of
work,
but
it
is
going
on
and
I
think
that
we
can
at
least
go
to
to
those
talks
and
see
okay.
A
This
is
good
and
this
is
bad,
and
this
is
missing,
and
at
least
like
do
a
kind
of
reflector
in
since
we
have
our
first
documentation
in
the
in
the
node.js
blog
docs.
Actually,
we
can
at
least
go
deeper
and
see.
Okay.
This
is
helpful.
Okay.
This
is
not
helpful
at
all.
It's
just
pointing
other
other
links
so
and
also
the
the
the
structure
was
created
three
years
ago.
Probably
today
we
have
a
different
way
to
diagnose
applications
that
we
can
add
to
the
to
the
list.
At
least.
E
Yep,
I
think
that
also
I
create
a
new
issue
yeah
last
week
about
deepening
writing
practices,
writing
rules
and
yeah.
I
could
add
them
and
also
for
newcomers
could
be
easier
to
even
back
and
forth
and
yeah
even
give
to
newcomers
a
way
to
submit
new
documentation,
for
example,
submit
the
plan
first
discuss
about
the
structure
and
then
write
it
down
instead
of
making
the
opposite
running
down
and
then
disc,
into
structure
after
stuff
like
that,
that
could
be
awesome
so.
D
In
the
context
of
the
collaborator
summit,
I
also
wonder,
like
often
it's
been
like
a
recruiting
effort
so,
like
I
don't
know,
like
a
10
minute
overview
of
here,
the
significant
efforts
that
the
working
group's
working
on
and-
and
just
you
know,
for
new
people
to
say,
hey
these.
These
are
things
we're
working
on
if
you're
interested
in
these
things
come
and
join
us
before
we
dive
into
the
details.
A
Engaged
yeah,
I
would
probably
be
available
in
the
first
day,
because
the
second
day
I
think
I
will
discuss
a
bit
about
a
security,
another
working
group,
so
I
might
not
be
fully
available
to
discuss
everything,
but
you
know
it's.
I
think
it's
the
same
place
and.
D
D
I
don't
know
even
in
the
in
the
collaborator
summit
itself,
I
think
in
the
past
we
have
done
some
like
working
group
intros,
but
we
haven't
got
gotten
that
far
to
understand
it
just
figuring.
It
would
be
good
if
we
fit
that
in
somewhere.
D
A
So,
let's
go
go,
let's
move
on
to
the
next
item.
We
have
two
issues
related
to
ll
node
and
I
believe
those
I
mean
we
will
have
half
of
these.
This
working
group
to
that
anton
will
show
we
will
discuss
about
the
node
next
steps
and
tracking
some
tutorial.
A
So
I
think
that
we
can
let
it
to
to
the
to
the
this
half
to
another
half
at
least
so,
let's
move
to
the
ebpf
at
racing
tool
list
the
issue,
five,
three,
five.
A
Basically
it's
what
I
said.
I
I've
been
working
it
internally
at
near
form
to
to
give
time,
at
least
to
to
create
a
proposal,
how
we
can
work
in
that,
how
we
can
expose
it
to
community
to
to
be
more
open
source,
and
that's
it
not
too
much
really.
A
A
Just
one
thing
is
that
you
know
I
have
just
moved
the
the
documentation
to
the
node.js
org,
but
looking
to
the
to
the
documentation
itself
like
it's
just
pointing
to
another
documentations,
I
don't
know
if
this
is
helpful
at
all
I
mean
if
we
are
filling
some
gap
specifically
and
if
we
need
to
move
it,
so
I
have
created
a
pr
in
order
to
get
more
to
get
feedback.
So
what
what
are
our
thoughts
on
this.
A
So
I
think
that
you
can
do
a
thing.
We
don't
need
to
take
a
decision
here.
So
please
just
take
a
look
there.
If
you
have
any
any
insight,
I'm
planning
to
to
I
mean
if
nobody,
if
there
is
no
objections,
I'm
planning
to
merge
it
this
week,
so
in
the
end
of
the
week,
so
that's
it.
We
can
go
to
today,
issue
three
four
nine
is
report
version
semantics
are
not
defined,
so
this
issue
was
was
a
stale
and
jirus
resurrect
it.
I
guess
and
yeah.
B
Yeah,
basically,
this
is
a
long
standing
issue.
The
problem
is
the
fact
that
report
diagnostic
report
at
the
moment
do
not
have
a
consistent
versioning
mechanism.
B
B
That
had
some
concerns
raised
in
the
discussion.
For
example,
how
do
we
consistently
perform
backboarding
with
no
breaking
change
definition,
and
things
like
that?
So
one
of
the
comments
that
is
linked
in
the
issue
provides
a
reasonable
explanation
of
why
back
port
doesn't
need
to
honor
the
breaking
changes,
etc,
and
with
that
I
think
we
should
be
good
to
conclude
here.
B
If
I
remember
correctly,
this
is
not
blocked
on
anything,
but
as
such
it
went
off
the
diagnostic
agenda
and
then
we
forgot
to
discuss
it
further
for
convergence
and,
more
importantly,
the
tooling
vendors
who
are
the
stakeholders
or
the
beneficiaries
of
the
report
version
was
not
keen.
Since
then
I
mean
we
didn't
hear
anything
from
them
since
then,
so
that's
where
it
got
dropped,
but
I
guess
we
are
good
to
go
with
a
single
digit
versioning
system
for
structural
changes
in
the
report.
A
B
B
So
that
what
happens
is
there
could
be
software
parsers
and
tools
that
runs
on
top
of
the
report
to
build
a
pipeline
or
automated
workflows,
etc,
to
get
a
meaning
out
of
the
reports.
So
if
the
report
undergoes
structural
changes,
these
tools
are
going
to
break
so
having
a
version
attached
to
the
report,
it's.
D
B
So
the
question
is:
should
the
version
follow
a
x,
dot
y
dot,
z
model,
which
is
the
characteristic
of
a
semantic
questioning
versus
a
single
digit
versioning?
Because
report
is
anyway
data?
It's
not
a
code,
so
any
any
sort
of
changes
is
a
progressive
change
and
it
it
warrants
a
single
digit
bump
that
that's
my
that's
my
proposal.
A
B
A
B
A
C
What
we're
saying
when
you
have
a
single
digit,
you
can't
communicate
that
you've
made
a
change,
but
it's
backward
compatible
and
so
which
I
would
say
with
json,
where
you
kind
of
I'd,
say
you
add
a
field
but
you're
probably
going
to
get
away
with
that
or.
But
if
you
completely
change
some
of
the
the
data
structures,
then
that's
probably
going
to
break
the
vendors
you
should
really
be.
C
I
see
you
like
the
the
version
should
communicate
that
somehow
do
you
know
so
then
they
can
understand
how
much
of
a
change
it
is
between
one
version
and
the
next
version,
but
I
think
you're
right,
it's
not
sember.
It's
not
december.
Isn't
the
right
way
to
do
that,
but
it's
something
like
december.
I
think.
B
Yep
since
then,
I
don't
hear
anything
from
him
for
quite
some
time.
C
B
C
A
Okay,
so
I
think
that
the
remaining
issues
in
the
list
is
the
ll
node.
So
are
you
let
anton
move
on
with
the
tutorial
as
this
skill
set
in
the
issue
that
I
don't
recall
the
issue,
but
we
have
discussed
that
half
of
these
security
working
group
will
be
end
on
presenting
the
ll
node
and
the
next
steps
go
going
to
the
to
the
the
issues.
Is
it
and
so
yeah.
C
No,
absolutely,
I
think,
yeah
we
said
we
as
most
of
us
had
targeted
the
diagnostics
meeting
and
we
were
talking
about.
Should
we
have
a
separate
ll
node
or
should
we
do
this?
I
think
michael
you're,
okay,
if
we
do
a
bit
of
a
take
over
here,
yeah,
I'm
gonna,
take
silence
and
say
yes,
michael.
B
C
Okay,
so
do
you
want
to
pull
it
up?
If
you
want
me
to
pull
it
up,
I
can
pull
it
up.
C
Thumbs
up
cool,
oh
good,
okay,
so
I
think
in
reverse
order
then
which
go
over
the
work
has
been
completed
then.
So
I
think
we
mentioned
the
two
factor.
Authentication
last
call,
but
the
we've
landed
the
llvm
and
compatibility
piece
and
since
the
last
time,
so
the
current
version
of
ll
node,
which
is
to
be
published
and
we'll
discuss
that
in
a
minute,
but
it's
now
compatible
with
from
8
to
fourteen
and
that's
in
maine
right
now.
Okay!
C
So
then,
if
we
look
at
the
work
in
progress,
tony
you've
been
basically
just
collecting
some
sort
of
artifacts
that
are
currently
some
documents
that
are
currently
around
the
the
ecosystem
and
collating
those
is.
Is
there
any
update
from
that
or.
E
D
D
D
C
Nice
one
okay,
great
great,
and
I
think,
there's
always
a
problem,
isn't
that
when
everybody
gives
you
too
much
information-
and
it's
like
you
could
decipher
all
that.
What
are
we
trying
to
get
to
here?
Is
it
that's
like
an
introduction
to
ll
mode
and
all
this
so
yeah
anyway,
yeah
great
to
hear
and
there's
a
plan
there,
so
that'll
be
cool
to
get
that
landed
okay
and
then
we
needed
to
establish
a
core
dump
collaboration
call.
So
we
had
that
as
an
out
of
band
two
weeks
ago.
This
is
the
session.
C
Is
the
second
version
of
that
and
we'll,
I
guess,
we'll
keep
on
having
it's
two
weekly
a
fortnight,
the
cadence
on
that
up
until
the
summit
at
the
very
least
and
then
we'll
see
where
we,
where
we
stand
after
that,
okay,
so
I'll
we'll
have
a
follow
on,
for
this
probably
keep
it
in
the.
If
it's,
okay
with
everybody,
probably
keep
it
in
the
diagnostics
call,
but
that's
the
plan
with
that,
so
the
v8
changes
16
to
18
by
cairn.
C
It's
not
that
one,
it's
the
pull
request
I
want.
Actually
this
is
a
as
I
mentioned
earlier
on.
This
is
very
very
close.
Now
we
have
a
number
of
discussions
around
it.
There's
I
put
together
this
matrix.
C
So
fundamentally,
we've
got
I'm
going
to
say
98,
but
just
very
close
to
all
the
feature,
compatibility
to
the
old
versions,
but
we've
had
to
drop
and
these
five
sorry,
these
six
items
that
are
in
here
we're
going
to
look
at
what's
involved
in
reinstating
them
and
then
understand
what
the
user
impact
is,
but
we're
probably
going
to
release
the
next
version
of
ll
node
with
these
unsupported
or
unavailable
features,
that's
kind
of
the
decision
that
that
we've
made
or
myself
and
cairn
have
come
to
within
this
ticket
and
with
other
contributions
as
well.
C
So
I
think,
considering
we've
gone
from
nothing
there
to
have
16
and
18
supported
to
98.
I
think
is
pretty
pretty
happy
with
that.
In
terms
of
the
bills
we
have
and
it's
running
on,
14,
you
can
see
there
there's
one
of
these
items
up
here.
I
think
it's
a
stringified
error.
That's
causing
16
to
fail,
but,
interestingly
enough
18
is
is
passing
tests
now
for
10
and
11..
Okay,
so
16
seems
to
be
a
little
tricky
to
to
get
to
to
get
to
work,
but
we've
got
some
patches.
C
We
think
that
we
can
get
it
there
in
general
for
the
tests.
Just
so
everyone's
aware
running
lldb
on
the
standard
github
actions
for
the
later
versions
of
lldb
is
flaky,
so
we're
seeing
tests
fail
due
to
timeouts,
because
there's
not
enough
capacity
on
the
box,
and
one
thing
I
was
going
to
ask
is:
is
it
can
we
beef
up
those
boxes?
Can
we
get
access
to
provision
machines
in
order
to
do
the
builds
rather
than
relying
on
the
free
ones?
I
don't
know.
C
D
C
Think
it's
a
little
less
painless
as
that
than
that,
I
think
basically
just
attach
the
account
to
your
your
github
account
to
your
azure
account,
and
then
you
configure
that
action
to
run
as
a
an
enclave
type
action
or
as
a
as
a
specific
virtual
machine
and
the
magic
all
happens
for
you.
You
don't
have
to
it's
not
like
you
have
to
provision
the
machine
yourself.
It's
just
github
knows
to
go.
Github
action
knows
to
go
and
start
a
specific
virtual
machine
for
you
for
the
action
and
then
spin
it
down.
C
D
D
D
Do
have
a
geocode
we
do
so
we
do
have
a
sponsorship
from
azure.
To
be
honest,
it's
mostly
like
for
machines.
It's
all
used
for
our
windows,
testing.
D
Okay,
we
have
been
running
out
like
I,
I've
been
I've,
been
for
I've
been
back
and
forth
with
the
people
who
provided
those
credits,
saying
hey
we're
running
out.
Can
you
help
so
I'd?
Be?
D
D
As
a
company,
I
don't
think
there's
been
any
discussion
of
a
build
track,
yet
I
think,
like
having
opening
an
issue
in
the
build
repo
to
say,
hey,
we
would
like
to
do
this.
Yeah
I
mean
in
terms
of
resources,
it's
maybe
more
work
to
set
up
like
a
separate
vm
with
the
runner
or
whatever,
but
that
we
may
have
more
capacity
for
if
you
know
what
I
mean
like
we
have
lots
of.
We
have
lots
of
because
I
think
what
we
want
this
case
is
a
linux
machine
right,
not
a.
C
A
C
D
D
Yeah,
I
think,
opening
an
issue
saying:
hey
here's,
here's
our
problem
build
working
group.
What
do
you
think
is
you
know?
Here's
some.
You
know
throughout
the
solutions
you've
already
thought
of,
because,
like
that
one
about
having
it
being
a
machine
in
azure,
I
I
wouldn't
have
thought
of
up
the
top
my
head
so
like
putting
in
the
things
you've
already
thought
of
and
then
asking
like.
What
do
you
think
the
best
way
to
go
is
yeah
a
great
way
to
go.
D
The
other
thing
too
is
like,
and,
and
maybe
here's
one
to
throw
in
there
is
like
instead
of
testing
in
in
actions,
we
could
potentially
have
like
a
jenkins
job
which
did
the
testing
right.
Not.
We
already
have
machines
that
are
already
and
already
have
linux
machines
and
all
that
so
that
that
actually
might
be
an
easy
way
to
go
to
so.
C
Yeah
yeah
I'll
try
and
I
don't
want
to
sort
of
guide
the
guided
solution.
I'll.
C
Is
this
an
option,
but
fundamentally
we,
our
problem
is
we're
currently
timing
out
because
we
don't
have
the
capacity
what's
the
best
way.
The
best
and
most
consistent
way
for
this
to
be
dealt
with.
Yeah
sounds
good,
yeah,
cool,
okay
I'll.
Do
that
so
yeah
hoping
to
get
this,
then
then,
in
some
stage
this
week
and
we're
talking
kane
would
join
the
call,
but
he
hasn't
managed
to
make
it.
But,
like
I
say
we
are
very
very
close
to
that.
C
So
pretty
happy
with
how
that's
going
then
what
did
I
do
with
my
meeting
minutes
here?
Yeah?
So
that's
what
that
one!
I
have
we've
got
this
item
here
for
the
medium
term
for
debug
helper.
I
think
that's
the
one
that
we're
bringing
to
this
collab
summit.
Okay,
so
I'll
move
that
out
and
we
can
discuss
it
there
and
then
we
have
the
supported
features
matrix.
C
So
this
was
hangover
from
the
last
call
where
we
wanted
potentially
the
opportunity
to
take
some
bits
out
of
ll
node
if
it
made
sense,
and
so
what
we
have
done
here,
you've
seen
the
specific
features
that
we've
taken
out
for
14
there's,
which
is
captured
here
in
terms
of
backwards
compatibility,
we're
only
we're
going
to.
We
are
we're
going
to
only
support
14
current
supported
node
releases,
the
only
ones
we
want
to
support
with
them
with
ll
node
going
forward.
C
C
No,
no,
I
agree
cool
yeah
and,
like
I
said
I
don't
think,
there's
any
commitment
from
us
at
all
on
that,
but
I
was
looking
through
some
of
the
issues
previous
issues
and
that
we
have
in
ll
node
and
quite
a
few
of
them
are
around
compatibility
for
14
type
problems.
So
I
think
it
might
be
helpful
for
to
to
have
that
just
out
there.
C
For
folks
we
did
mention
in
the
last
in
the
last
core
call
that
we
want
to
look
at
the
js
api,
and
I
think
this
was
due
to
this
bug
here.
That
said,
js
api
is
probably
broken,
love
it.
When
you
get
these
things
from
the
community,
it's
all
broken,
it's
all
on
fire,
but
when
you
actually
look
at
it,
it's
because
they
didn't
put
the
right
options
into
the
build.
C
So
I'm
not
as
if
it's
if
it's
working
fine
and
it
seems
to
me
that
it
is
so
the
api
build
is
done
as
part
of
the
as
part
of
the
ci
tests
and
is
tested
as
part
of
the
ci.
So
as
far
as
we're
concerned,
it's
working,
I'm
don't
have
the
same
amount
of.
I
don't
have
the
impetus
to
remove
js
api,
yet
a
lot
of
work
went
into
it
and
it
still
works.
So
why
would
you
why
would
you
get
rid
of
it's
not
broken
yet?
Okay,.
C
Okay
and
then
we
discussed
the
the
features
that
we're
taking
out
to
get
1618
out,
discuss
the
the
versions
of
know
the
three
three
zero
and
that's
all.
I
have
really
for
work
in
progress
and
we've
gone
over
sort
of
the
release,
et
cetera,
et
cetera,
okay,
so
yeah,
I
think
that's,
that's
all
we
wanted
to
cover
for
our
knowledge,
yeah.
Well,
certainly
from
this
ticket.
A
A
It's
it's
supported,
but
all
the
active
release
lines
like
we
can,
because
recently
we
remove
it
from
the
support,
the
diagnostic
support
list,
at
least,
and
I
think
that
once
it's
completed,
I
think
that
we
can
truly
revert
it
and
say:
okay,
node.js
is
now
supporting
ll
node
again
and
perhaps
make
an
announcement
or
something
like
that
in
order
to
to
get
more
collaborators
at
least
or
people
using
it,
because
I
see
that
at
least
in
the
agenda
we
have
an
item
that
is
alternatives
to
ll
node.
A
C
A
Is
called,
let
me
send
the
link.
A
C
C
C
Yeah
sorry
we're
talking
about
there
once
we
have
landed
the
1618
pr
to
get
no
and
published
it
in
npm.
Do
we
reach
out
to
robin
to
get
the
to
get
the
announcement
done
or
how
does
that
work.
D
C
Yeah
so
probably
go
with
tony's
sort
of
how-to
article
to
lead
with
it.
So
yeah
ellen
knows
back
here's
you
can
now
use
it
with
16,
14,
16
and
18,
and
here's
a
tutorial
on
how
to
do
that
and
that
would
square
it
off.
I
think
no.
D
D
Basically,
if
we
have
like
a
link
to
a
blog,
if
we
want
a
blog
post
which
is
published
somewhere,
the
choices
we
kind
of
have
one,
and
so
we
have
the
node.js
medium,
but
there's
constant
discussion
of
whether
we
should
still
publish
things
or
not.
So
we
can
always
ask
and
it
would
be
robin
and
the
new
and
I'm
terrible
with
names,
but
like
there's,
a
new
person
related
who's,
doing
the
actual
blog
you
know
stuff.
So
we
could
reach
out
to
them
and
say:
hey
we'd,
like
this
published
in
the
node.js
medium
account.
D
You
know
we
could
see
if
that's
a
place,
we
want
to
start
putting
blog
posts
again,
we
haven't
like
if
you
look
at
what's
there,
you
know
it's
mostly
just
release
announcements,
but
it
had
been
discussed
that
maybe
that's
where
we
should
public
publish
blog
posts
as
well
yeah.
C
D
D
Just
the
pr
to
nodejs.org
yeah-
and
you
know,
if
you're
happy
to
sort
of
have
that
discussion
of
hey.
You
know,
does
this
belong
here
then
that's
that
doesn't
require
asking
anybody
else.
We
probably
then
want
to
you
know,
point
the
the
people
who
are
helping
from
the
foundation
in
terms
of
the
social
handles
and
everything
saying
hey.
We
want
this
promoted
yeah
on
twitter
and
wherever
else,
but
yeah.
C
C
Least
that
and
let's,
let's
have
a
think
about
it
in
terms
of
additional,
do
we
want
to
put
something
on
medium
as
well.
D
Yeah
because
like
if
we
tried
to
put
it
there,
you
know
it
would
reignite
that
discussion.
I
think,
because
we
we
just
we've,
never
closed
on
it
like
it's.
You
know
people
there's
lots
of
people
who
are
like
medium.
Isn't
that
great
a
place
to
put
places
we
haven't
decided
another
one.
Just
posting
them
on
here
is
you
know
one
of
the
places
we've
discussed
so
yeah.
It.