►
From YouTube: 2017-06-07 Node.js Foundation CTC Meeting
Description
A
A
C
And
welcome
to
the
nodejs
foundation,
core
technical
committee
meeting
for
June
7th
2017
and
we
no
longer
start
the
meeting
with
a
stand
up,
which
means
we
instead
are
going
to
start
the
meeting
with
announcements.
This
is
the
first
meeting
since
no
dis,
8.0
was
released
and
NPM
five
was
released
and
does
anybody
have
anything
they
want
to
announce
to
the
world
via
this
meeting.
D
I
guess
one
thing:
I
can
announce
really
quickly.
Note
Soros
had
some
pretty
fantastic
numbers
that
they
had
reported
in
downloads
in
the
first
week,
so
just
to
anyone
listening
who
downloaded
no
date
right
away
and
was
testing
it
out
and
helping
his
find
bugs.
You
know
about
thank
you
for
jumping
on
the
train
so
quickly
and.
E
C
C
But
since
then,
there's
an
additional
discussion
in
the
github
issue
and
I
believe
that
what's
happening
now
is
Matteo
is
going
to
put
together
a
request
at
some
point
in
the
foreseeable
future.
Do
I
have
that
right,
Matteo,
yes,
yep!
You
have
it
right!
Thank
you,
excellent,
ok!
So
moving
on
to
this
week's
agenda,
we
have
I
believe
just
one
item.
C
C
Okay,
I'm
lost
already.
This
is
a
yeah
noting
that
bol
platforms
and
the
black
platforms
are
not
supported,
there's
some
difference
of
opinion
about
what
terminology
means
and
what
we
should
do
as
a
project.
This
is
in.
This
is
a
pull
request
in
the
nodejs
slash
node
repository.
It's
pull
request
number
one,
six,
seven,
and
I
think
it
was
sam
roberts
who
put
this
on
the
agenda.
I'm,
not
100%.
Sure.
Let
me
take
a
quick
look
or
anyone
know
speak
up.
C
C
F
I
can
take
it
cut,
it
I
mean
the
initial
decision
was
that
we
add
into
our
supported
description,
something
that
said
you
know.
Platforms
are
no
longer
supported
once
they
go
end
of
lives.
It
came
out
of
the
discussion
around
for
door
22,
which
is,
is
gone
an
end
of
life.
We
wanted
to
remove
it
from
our
CI
that
sort
of
triggered
some
discussion
saying
well
like
if
we're
not
testing
on
it
should
not
be
supported.
I
think
that
you
know
the
the
objections
to
saying
not
supported
is
that
it's
not
actually
super
clear.
F
What
would
you
know
what
we
mean
by
supported
anyway?
You
know
it's
it's
like,
even
if
it's
end
of
life,
if
somebody
came
in
gave
us
effects,
we
would
probably
take
it
as
long
as
it
didn't
break
any
other
platforms
and,
on
the
other
hand,
just
because
it's
in
our
CI
doesn't
mean
that
we're
actually
going
to
fix
everything
right.
It's
it's
still
open
source
sort
of
best
effort,
and
in
that
context
you
know
there
was
discussion
over
whether
saying
it's
unsupported
at
end-of-life
was
the
right
thing
to
do
or
not.
F
D
Michael
a
question
for
you
really
quickly
because
I
haven't
stayed
100%
up
to
date.
I
know
that
there
was
some
conflict
around
whether
or
not
we
should
be
dropping
support
and
so
I
think.
A
really
great
example
here
is
with
node
v6
and
Ubuntu
12,
because
that
is
end-of-life
and
it's
no
longer
going
to
be
having
support
from
canonical
itself.
D
Yet
we're
still
like
there
was
the
question
about
whether
or
not
it
would
be
considered
like
a
sunburn,
major
chain
or
the
contract
to
stop
testing
and
launching
I
for
one,
don't
think
that
we
should
be
supporting
anything,
that's
not
being
supported
by
their
upstream
maintainer,
but
I
know
that
other
people
felt
differently.
Was
there
any
resolution
there?
I
I.
F
Don't
think
so,
I
think
that
yeah
I
mean
this
came
from
the
you
know
the
in
between
rather
than
saying,
while
we're
not
going
to
support
in
going
to
12
now,
because
it
will
go
out
of
end-of-life,
was
that
if
we
added
in
a
statement
saying
that
you
know
when
they
go
out
of
and
when
they
go
eh
of
AOL,
they
will
no
longer
be
supported.
You
know
that
would
mean
that
it
wouldn't
be
super
major
to
drop
it
middle,
because
we
basically
had
told
people
at
a
timeless
and.
D
That's
kind
of
like
where
I
think
that
we
should
be
heading
personally
I
mean
it
seems,
kind
of
borderline
irresponsible
to
continue
like
offering
support
of
you
couldn't
see.
I
was
quoting,
or
there
were
air
quotes
on
the
other,
but
like,
if
he's
exactly
right,
yeah
like
two
years
past,
the
end
of
life
date
of
the
actual
operating
system.
It's
also
like,
in
my
opinion,
like
kind
of
hypocritical.
If
we've
like
really
been
pushing
that
people
should
be
dropping
support
for
ten
and
twelve,
when
we're
no
longer
supporting
it
right.
F
I
mean
that
I.
Think,
though,
if
in
the
late
the
later
part
of
the
discussion,
you
know,
I
suggested
something
that
maybe
takes
a
different
tact,
and
so
I'll
read
that
out,
and
it
was
the
and
and
then
Gibson
suggestions
a
shortened
version
of
this
with
which
ended
up
being
you
know,
the
community
does
not
build
a
test
against
end
of
life
distributions.
Thus
we
do
not
recommend
that
you
use
node
on
end-of-life
or
unsupported
platforms
in
production,
because
then
we
don't
actually
list.
The
distributions,
like
you
know,
are
supported.
We
just
support.
F
G
F
C
D
Of
harbor,
okay,
well
I
mean
that
totally
makes
sense.
Jordan
has
definitely
held
that
opinion
in
the
past,
on,
like
things
involving
10
and
12,
and
with
his
maintenance
of
nvm
I
can
totally
see
where
that
opinion
is
coming
from.
I
personally
do
not
agree
rich.
You
had
mentioned
that
you
had
some
opinions,
I'm,
sorry
to
put
you
on
the
spot,
but
would
you
like
to
share
those
I
mostly.
C
Agree
with
Jordan,
but
I
also,
like
I,
said
I
totally
defer
to
LTS
or
build
or
release
on
this
issue.
I
and
and
I
think
Ben's
right.
You
know
it's
not
going
to
make
a
you
know.
It's
really
I
mean
this
is
more
about
appearances
than
anything
else,
because
someone
running
an
EO
L
operating
system
is
unlikely
to
install
a
just-released
version
of
node
and
if
they
do
they're
unlikely
to
be
surprised
that
it
doesn't
completely
work
on
their
on
their
operating
system.
There's.
D
The
opposite
really
I
mean
we
don't
have
the
best
of
release.
Schedule
with
Debbie
and
I
mean
with
the
way
that
LTS
are
like
just
like
apt
repositories,
work,
they're,
stuck
on
unfairly
old
versions
and
they're,
not
like
constantly
updating
those
through
the
lifecycle
of
the
of
the
release
itself.
There's
something
I
personally
wanted
to
see
improve.
You
know
Trevor
first
handed
over
a
note
source.
B
After
the
Linux,
we
don't
call
them
PBA's
anymore,
because
some
that
only
applies
really
to
the
punty
ecosystem,
but
the
repositories
were
maintaining
apply
to
most
things.
That
run,
that
the
other
point
I
want
to
make
to
add
to
this
is
that
we
actually
have
increased
difficulty
over
time,
even
getting
the
required
platforms
to
test
and
build
on
so
as
the
as
they
drop
as
they
drop
support,
they're
going
to
be
drop
support
by
our
infrastructure
providers
as
well.
B
So
when
you
know
at
the
moment
we're
running
CentOS
5
to
do
builds
for
the
LTS
versions,
but
you
can't
I,
don't
pretty
sure
you
can't
create
a
new
Central's
5
like
droplet
or
instance,
on
these
providers
we're
using
now.
So
if
we
were
to
for
some
reason,
lose
the
current,
because
we've
got
we're
going
to
have
trouble
getting
them
again,
so
it
just
becomes
very
difficult
to
even
get
the
base
operating
systems
for
us
to
test
on
so
tying
ourselves
to
strictly
to
these,
things
can
create
them.
F
Right
so
I
guess
it's
it's
at
this
point.
It's
how
strong
do
we
want
to
be
like
you
know,
are
we
comfortable
with
that
last
statement
that
I,
you
know
said
that
we
just
basically
state
we
don't
build
or
test
against
those
end
of
life
distributions
and
that
we
don't
recommend
them
or
do
we
want
something
stronger?
That
actually
says
you
know
they're
unsupported,
whatever
unsupported
means
and
unquote
in
air
quotes
when
the
heavy
Yoel
I,
like.
F
D
I
actually,
like
I,
was
not
aware
that
it
was
down
to
just
a
kernel
level
right
now
and
I
think
that
that
is
actually
a
really
nice
broad
way
of
supporting
things
and
gives
us
a
lot
of
flexibility.
So
rich
I
know
I'm
like
keep
talking
about.
You
seem
to
be
the
one
person
kind
of
in
the
group
right
now:
who's
leaning
on
the
other
side.
C
That
just
feels
like
we're
kind
of
breaking
a
contract
with
the
end
user
and
a
lot
of
it
again
has
to
do
with
what
we
mean
by
supported,
because
you
know
to
me
and
apparently
to
Jordan
I
think
you
know
support
it.
Just
basically
means
you
know,
you
know,
you'll
try,
you
know
and
I
mean
that's
I
mean
that's
true
with
things
that
aren't
you
well
like
there
there
are.
There
are
operating
system
quirks
that
we
can
do
nothing
about
that
affects
how
note
operates.
C
C
F
B
D
Operating
system,
it's
not
our
job
necessarily
as
volunteers
to
manage
that
I
do
think
like
reach.
One
point
that
I'm
getting
from
what
you're
saying
that
I
think
may
be
important
to
stress:
is
that
maybe
it's
less
about
quote,
unquote,
support
and
more
about
what
infrastructure
we
have
in
our
CI,
because,
realistically,
what
we're
talking?
What
we're
really
talking
about?
What
we
really
care
about
is
not
having
to
maintain
end-of-life
os's
in
our
CI
ya,
seem
very
reasonable,
both
a
security
standpoint
and
a
sustainability
standpoint,
and
so
we're
not
ever
saying
hey.
D
C
Think
so,
either
I
think
I
think
it's
I
think
the
important
thing
is
to
be
absolutely
clear
about
what
we
mean
and
maybe
that's
the
problem
with
support.
Is
that
means
different
things
to
different
people
but
but
yeah.
It's
absolutely
I
mean
like
like
we're
doing
the
user
favor.
If
we
tell
them
that
you
know
once
your
operating
system
is
eol,
we're
not
testing
on
it
anymore
and
you
know,
and
and
and
bug
fixes,
as
always
our
best
effort
and
etc,
etc
and
strong
we're
doing
them
a
favor.
B
One
of
the
complications
with
that
is
that
we
may
then
have
to
define
what
systems
we
do
test
on,
because
we
don't
list
that
anywhere
explicitly
in
the
in
the
node.js
repo
and
building
or
support,
supported
platforms,
or
anything
I
mean
we
don't.
So
we
don't
test
on
Arch
Linux.
We
don't
test
on
a
bunch
of
other.
You
know
weavers,
we
don't
test
on
rail.
We
just
on
CentOS,
assuming
that
it'll
be
the
same.
B
F
J
I,
just
was
going
to
say
that
yeah
at
Microsoft
at
least
I
I
think
support
is
a
little
more
than
best.
Effort
like
best
effort,
is
a
different
category.
Support
kind
of
means
we're
going
to
fix
the
problem
for
you
somehow
or
other,
and
best
effort
means
you
know.
If
we
can't
fix
it,
we
can't
we'll
do
our
best
Oh.
What.
F
J
A
F
D
The
version
of
a
bunt
to
that
had
been
supported,
I
think,
like
one
point,
I
just
want
to
put
out
there
and
then
and
I'll
hand
it
back
to
you
is
like
maybe
the
way
in
which
we
can
talk
about
OS
or
Linux.
Flavor
support
can
be
specifically
by
the
flavor,
so
we
could
say
we
support
a
bun
to
but
not
be
specific
about
the
version
just
kind
of
a
thought
there.
It
looks
like
rich,
has
his
hand
up
I.
C
Want
to
propose
that
we
kick
this
back
to
github
that
we
sort
of
like
once.
We
have
minutes
copy
paste
the
contents
into
the
github
issue,
so
that
people
know
what
we
talked
about
and
thought
about.
If
they
didn't
listen
to
this
meeting
and
that
we
check
back
in
a
week
and
if
there's
no
decision
in
a
week
or
so
maybe
two
weeks
but
about
a
week
I
would
guess.
Then
we
just
you
know
we
make
a
decision
on
what
the
wording
should
be.
Yeah.
F
B
Okay,
I'll
go
for
it
just
remember.
What's
going
to
say,
we
may
actually
be
talking
ourselves
around
in
circles
here
and
not
really
like
it
lately.
In
practice.
We
support
loopsy
versions
and
compiler
versions.
That's
really
what
we
support
when
it
comes
to
things
not
working
on
different
Linux
distributions,
because
I
think
we're
mainly
talking
about
Linux
distributions
here.
I
can't
actually
think
of
any
good
examples
of
things
that
have
failed
on
a
Linux
distribution,
but
not
on
another
one,
with
an
equivalent
or
roughly
criminal,
oopsie
or
compiler
and
I'm.
B
Accepting
the
case
of
you
know
something.
Some
configuration
is
different
and
our
test
time,
but
not
actually
no
itself
failing
so
in
practice.
As
long
as
it's
putting
the
Lipsy
version
and
the
compiler
version
and
some
sort
of
rough
things
about
that
environment,
it
should
actually
just
work
so
I'm.
You
know
I'm,
not
I'm,
not
sure
yeah
I'm,
not
saying
that
we
won't
run
into
problems,
but
we
could
we,
but
it's.
We
may
never
even
run
into
a
problem
here
as
long
as
we're
supporting
that
rough
environment.
D
So
one
path-
Matson
BSD-
was
limb
that
like
kind
of
caught
us
by
surprise
with
the
real
path,
implementation
for
just
one
example,
but
that
wasn't
between
versions
of
the
same
OS.
So
just
one
instance
of
the
OS
combat,
which
is
the
one
thing
I
want
to
quickly
say
before
we
move
forward
and
I
think
this
is
the
crux
of
the
issue:
does
anyone
strongly
object
to
us
dropping
end-of-life
operating
systems
from
our
SIA
I?
A
Well,
I
mean
like
like
I'm,
not
sure
it's
like
you,
you
completely
what
I
was
going
for
with
my
previous
question
because
like
if,
if
we
know
that
we're
in
situation,
we're
building
on
newer
OS
instead
actually
gives
gives
binaries.
That
would
work
on
the
previous
version
that
we
were
testing
before.
If
we
know
that
that's
going
to
happen,
are
we
still
going
to
drop?
The
older
system
can
see
I.
D
B
That
we
need
to
and
that's
such
an
elite
we're
still
running
CentOS
5,
even
though
it
doesn't
support
and
we're
going
to
try
what
we're
going
to
have
to
try
and
continue
running
it
for
a
lifes
lifetime
of
node,
4
and
6,
because
we're
building
those
binaries
on
that
particular
set.
So
the
goal
is
to
always
build
it
in
the
same
environment.
So
it's
got.
B
The
same
loop
see
same
compiler
for
the
lifetime
of
that
LCS,
but
there's
now
a
thing
in
in
in
Jenkins
that
when
we're
building
that,
if
we're
building,
node,
8
or
newer,
it
builds
on
CentOS
6.
For
that
reason
that
sent
us
5
is
out
of
support
and
will
drop
soon
and,
like
oh
sorry,
n
node,
6
woman
will
go
and
then
we'll
be
free
of
sin
x,
5
completely,
but
we
as
we're
also
still
testing
sent
us
5.
Well,
we
haven't
dropped
them
and
there's
no
actually,
no
discussion
of
clock.
F
F
H
Curious,
how
do
you
other,
how
do
other
projects
and
like
how
does
chrome
say
all
right?
Well
we're
upgrading
and
at
this
point
no
longer
going
to
support
you
know
this
operating
system
or
I
mean
since
that
I'm
an
LTS,
some
other
project
that
it
does
have
an
LTS
relating
how
do
they
handle
it?
If
anybody
has
an
example.
H
F
D
I
guess
the
question
here
that
we
can
maybe
look
at
like
is
there
a
way
that
we
could
look
at
having
supported,
builds
of
kernels
and
Lipsey's
and
kind
of
try
to
align
that
with
the
LTS
before
things
go
LTS
like
maybe
we're
stuck
with
forum
6
because
of
the
current
contract.
But
is
this
something
that
we
can
like
explicitly
plan
out
for
notate
before
it
goes
LTS,
so
that
we
like
know
that
we're
going
to
be
spoiling
the
entire
time
and
not
maintaining
out
of
date
info
didn't.
A
F
G
I
think
a
folks
I
think
that
we
should
we
should
when
we
do
a
LTS
release,
we
should
say
look
L
Boone
to
12
is
going
out
of
support
at
this
point
and
we
will
provide
you
banner
is
still
at
that
point.
They
keep
as
usual
when
so
those
type
of
things
are
planned.
So
if
somebody
is
planning
to
release
a
seat
to
upgrade
the
note
version
in
a
life
system
using
all
UNIX
distribution,
typically,
there
is
somebody
making
those
decisions.
C
D
Sounds
good
to
me,
I'd
like
if
we
can
to
at
nodejs,
build
and
nodejs
LTS
in
there
for
this
to
be
discussed
in
their
working
group
meeting
so
that
they
can
provide
what
releases
LTS,
yeah
so
I
just
think
those
working
groups
should
have
a
conversation.
Put
the
results
in
those
conversations
in
the
home.
I
suspect.
F
F
C
Okay,
so
hopefully
okay,
so
hopefully
it'll
resolve
itself,
but
we'll
leave
it
labeled
CTC
agenda.
So
we
check
back
on
it
next
week
and
and
it's
it's
fitting
a
little
we
can
move
on,
but
otherwise
we'll
let
the
let
the
let
the
working
groups
and
people
invest
it
in
the
issue
sort
of
salable.
So
it
certainly
looks
like
close
and
moving
forward.
It's
like
Michael,
already
I'd
mentioned
those
groups.
So
right,
I
just
threw.
C
K
C
L
C
C
C
C
C
Okay
looks
like
there:
they
are
in
the
eye
in
the
sideboard.
Okay,
great
well,
let's
see
here.
Okay,
super
duper,
all
right,
congratulations,
Matteo
and
show
you
if
you
end
up
listening
this,
recording,
congratulations
and
sorry
about
your
name,
because
I'm,
terrible
and
the
horrible
person,
but
yeah
thanks
for
all
the
contribution
of
the
year
welcome,
and
we
have
a
bunch
of
things
that
I'll
shoot
you
an
email
or
someone
else
will
about
yeah,
there's
a
whole
bunch
of
stuff,
so
yay
all
right.
B
C
Cool
all
right,
so
I
think
we
are
now
at
the
part
of
the
meeting
where
we
list
off
upcoming
meetings,
and
we
mentioned
that
we're
about
to
take
Q&A
from
anyone.
So
if
you're
on
the
YouTube
stream
or
if
you're
in
the
IRC
channel
now's
a
good
time
to
post
your
questions
for
the
CTC.
In
the
meantime,
there
is
the
node.js
foundation
calendar,
which
is
at
nodejs
org,
slash
calendar.
C
This
meeting
the
CTC
meeting
next
week
will
be
at
11
o'clock
UTC,
but
on
June,
14th
and
that'll
be
4
a.m.
if
you're
on
the
west
coast
of
the
United
States
7
a.m.
if
you're
on
the
east
coast
of
the
United
States
and
much
more
agreeable
times.
If
you're
in
Europe
and
probably
in
in
Asia
and
Australia
as
well.