►
From YouTube: 2022-03-23-Node.js Technical Steering Committee 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,
so
welcome
to
the
node.js
technical
steering
committee
meeting
for
march
23rd
2022.
We
will
follow
the
issue
that
was
opened
in
the
tc
repo
for
this
meeting,
which
is
issue
number
one,
one,
nine
one
before
we
get
started.
Does
anybody
have
any
announcements
they'd
like
to
share.
A
Okay,
if
not
we'll
move
on
to
the
issues
that
were
tagged
for
the
agenda,
the
first
one
is
40817,
add
resume
ci
label
to
issues
I'm
going
to
open
that
up.
A
A
Right
we
had
some
discussion.
This
is
basically
over
whether
we
want
a
label
that
says
let's
just
resume
the
ci
versus
having
to
do
it
in
the
the
issue
itself
like
going
through
jenkins
and
doing
it.
So
I
don't
know
if
people
here
have
any
thoughts
on
that.
B
Is
there
anything
left
to
discuss?
I
thought
I
thought
we
had
discussed
this
before.
I
don't
remember
what
what
the
remaining
blockers
were
on
this
other
than
someone
would
need
to
volunteer
to
do
the
to
do.
C
B
I
think
that
I
think
it
was
more
we
we
would
allow
it
and
revise
if
anything
untoward
happened,
but
I
don't
believe
anything
has
so.
I
think
it'd
be
the
same
for
this
sort
of
resume.
B
Theoretically,
there
could
be
sort
of
things
that
might
might
happen,
but
that's
the
same
with
collaborators,
and
we
haven't
seen
any
evidence
that
you
know
the
triages
are
more
or
less
responsible
with
their
their
sort
of
starting
ci's
or
yep,
or
at
least
to
do
to
the
extent
of
their
ability
to
do
so
so
yeah
in
terms
of
the
regime.
I.
A
A
A
A
A
A
A
Do
we
have
any
concerns
with
adding
by
default
to
security
and
now
security
pre-announces?
A
If
they're,
just
openness
to
selling
security
releases,
the
following
tax,
which
would
be
you
know
if
you're,
using
a
node.js
version,
which
is
part
of
a
linux
distribution
which
uses
a
system
installed
openssl
the
security
update,
might
not
concern
you
please
check
with
their
security
team,
and
it
came
from
an
issue
that
was
opened
by.
I
think
their
part
of.
A
I
know
that
the
same
is
true
for
rel,
in
that
you
know
for
rel
the
open
ssl,
you
know
the
node
that
comes
with
rel
is
not
built
using
the
in
the
the
built-in
open
ssl
it's
built
so
that
it
uses
shared
open
ssl.
So,
like
a
an
open
ssl,
only
security
release
doesn't
affect
cat
binary
and
that's
where
sort
of
the
context
I
see.
Nikita
has
his
hand
up.
D
Yes,
this
actually
affects
more
distributions
than
just
religion,
but
this
also
might
work
both
ways
and
perhaps
the
user
should
be
reminded
to
update
open.
So
they
have
to
like
the
wording
that
was
proposed.
There
just
says
that
it
might
not
be
of
concern,
but
perhaps
they
should
update
openness
to
sell
in
some
cases
like
it
doesn't
mean
that
they
shouldn't
update.
A
D
A
Right
agreed,
I
see
miles,
has
his
hand
up.
E
Yeah,
I
think-
and
you
can
correct
me
if
I'm
off
based
on
this,
I
don't
actually
think
that
this
problem
is
even
you
know
like
specific
to
security
releases.
It's
just
like
more
obvious
when
it
comes
to
security
releases
like
we
generally
would
not
have
this
happen
because
of
how
much
work
we
have
happening,
but
there's
no
reason
why
we
couldn't
have
a
node
release.
That's
just
an
update
to
depths
right
like
and
so
any
any
like
distribution.
E
It
obviously
happens
practically
in
a
security
release
where
that's
the
only
thing
we're
updating,
but
I
don't
think
that's
the
only
time
and
we
wouldn't
all
of
a
sudden
not
do
like
a
sember
patch
release
like
it
may
not
make
sense
to
update
those
releases
on
on
those
operating
systems.
But
that's
to
some
capacity
like
that's
also
just
saying,
like
hey
we're,
changing
the
version
that
we're
pointing
at.
E
I
know
that's
not
how,
like
shared
libraries,
works
from
a
package
management
perspective,
but
but
it
does
lead
me
towards
the
won't
fix
camp
here
because,
like
you
know,
we
vendor
dependencies
updating
those
dependencies
is
part
of
our
versioning
process
and
in
lieu
of
like
changing
the
way
that
we
do
versioning.
I
couldn't
imagine
that
there's
something
to
really
change
there.
A
I
I
think
the
only
ask
here
is
that
in
the
pre-announced,
because
I
think
the
the
the
thing
that
they
the
people
can
get
is
we're
shouting
that
hey
you
better,
do
your
secure,
better
update!
You
know,
security
release
is
coming.
You
better
get
ready.
You
have
to
update
your
note
and
then
people
go
back
to
umbutu
and
say
well,
where's
your
new
note
and
they're
like
well.
You
don't
need
one.
A
E
Our
security
releases
can
have
lots
of.
I
guess
this
is
kind
of
a
point.
Our
security
releases
could
have
lots
of
other
things
in
there
we
may
be
floating
other
patches.
There
may
be
other
things:
different
operating
systems
and
package
distribution.
Maybe
linking
some
things
and
not
linking
other
things.
A
I
identify
with
this
one
only
because
it's
more
common,
like
we
quite
often
have
an
open,
ssl
security
release,
probably
several
times
a
year,
and
you
know
for
any
regular
security
release.
There's
a
bunch
of
things
in
it.
It's
not
going
to
apply,
but
we
do
have
probably
two
three
a
year
where
it's
just
an
openness
to
sell
update,
and
it's
only
about
the
pre.
E
But
we
have
had
like
pre-release
announcements
for
like
a
release
that
we
thought
was
going
to
only
have
open
ssl,
but
we
end
up
having
to
make
some
other
changes
as
well.
At
the
same
time,
I
guess
like
we
can
do
it.
I
am
just
concerned
about
these,
like
these
kinds
of
blanket
statements
that
maybe
don't
apply
to
all
circumstances
or
could
be
undermined.
E
A
A
D
Yes,
I
also
use
this
and
I'm
not
not
sure
if
this
is
a
good
idea
to
commit
to
that
by
default,
like
try
that
by
default
to
me,
where
we
are
planning
just
to
finish
updates,
perhaps
we
can
have
this
of
like
sort
of
form
recorded
somewhere
for
for
the
usage
and
in
case
by
case
on
case
by
case
basis,
we
can
choose
to
add
that
to
some
release
where
the
enchanted
shortage,
that
would
be
just
openness
updates.
A
Yeah,
I
think
the
only
way
it's
workable
is,
if
we
actually
put
it
into
our
like
our
our
security.
Like
we
have
the
the
process,
we
would
need
to
pr,
in
some
words
there
that
would
say
in
this
situation
you
know
consider,
maybe
you
could
could
be
consider
putting
this
this
text
or
something,
but
if
we
just
leave
it
as
ad
hoc,
it
might
as
well
be
we're
not
doing
it
because
it
just
relies
on
somebody
remembering
or.
D
I
don't
think
it
would
be
very
bad
if
we
just
forget
it
in
some
case,
but
it
could
be
bad
if
we
accidentally
added
when
we
like
when
it
you
know,
we
are
going
to
add
some
other
changes
to
the
security
chair
update.
D
A
A
I
don't
think
there's
that
I
mean
I
just
put
it
on
the
agenda
to
get
some
discussion.
So
if,
if
you
know
it
sounds
like,
I
don't
know,
if
the
few
people
who
had
some
thoughts
could
add
those
thoughts
to
the
issue,
that
would
be
good
yeah.
I
will
promote
tobias.
A
Okay,
the
next
one
is
publishing
specs
for
buffer
and
event.
Emitter
number
1176.
D
F
A
Okay,
so
then
next,
that
is
all
the
issues
that
were
tagged
for
the
agenda.
We
can
now
flip
over
to
strategic
initiatives.
So
let
me
take
a
quick
look.
There.
F
Yeah,
oh,
I
think
it
asked
the
first
cpc
updates
this
week.
Did
we
cut
that
out
of
the
agenda
or
we
skipped
over?
I
just
missed
it.
So
go
for
it.
I
don't
have
any.
We
never
we'd
have
a
meeting
there.
We
had
this
week.
We
had
a
working
group
thing
and
we
just
you
know,
michael
because
I
think
you
were
there.
We
we
were
just
cleaning
up
repositories
and
stuff
and
doing
some
housekeeping.
A
So
board
meeting
is
this
friday,
so
I
don't
have
anything
from
the
no
project
to
bring
there,
but
if
there
is
anything,
let
me
know
a
similar
vein.
A
Ton,
mary
so
mary
anything
on
the
future
build
chain.
You
want
to
bring
up
no.
C
A
My
next
10
that
the
the
two
things
I
will
just
mention
is
there
is
a
mini
summit
planned
for
april
7th,
so
you
can
plan
for
that.
That'd
be
great.
I
hope
to
get
that
issue
open
this
week
and
maybe
a
few
more
more
promotion.
The
other
thing
I'd
mention
is
there
is
some
good
discussion
going
on
related
to
bundling
of
node.
A
A
That's
all
I
had
on
that
front,
and
I
think
that
takes
us
to
the
end
of
the
agenda.
Is
there
anything
else
that
we
should
discuss
before
we
close
out
this
week.