►
Description
A
B
E
G
C
D
I
I
Been
addressing
some
tests
here
in
the
arrow
particularly
excited
to
land,
the
test
inspector
flaky
tests
fix,
which
will
probably
land
early
this
afternoon,
and
then
that
should
turn
our
regular
CI
from
yellow
to
green.
So
that's
exciting,
PR
issues,
reviews
the
usual
stuff
and
preparing
for
code
and
learn
in
Austin.
If
you
are
going
to
be
in
austin
and
have
not
signed
up
to
be
a
mentor
for
10
code
and
learn,
you
should
okay,
that's
it
do.
A
Okay,
I'm
so
moving
on
in
the
agenda,
we
will
go
through
the
previous
meeting
review.
We
talked
about
issue
29,
so
the
new
CTC
meeting
schedule
proposal,
I
think
in
the
end
we've
agreed
to
stick
with
SAR
to
meeting
time
rotation
until
the
end
of
the
year
and
then
revisit.
Then
we
talked
about
the
documentation,
workgroup
32,
which
is
really
just
a
call
to
see.
If
there
was
anybody
else
who
avail
you
know,
who'd
be
wanting
to
stand
up
and
sort
of
reinvigorated.
A
We
talked
to
bail
revert
but
for
a
runtime
deprecation
of
calling
buffer
without
new
95
29,
which
we'll
talk
about
again
today.
So
I
think
we'll
leave
that,
for
now
we
talked
about
to
fix
leak
of
right,
wrap
and
TLS
wrap.
I
think
that
was
a
number
of
nine
six
two
six
that
was
going
to
go
back
to
github
with
trevor
proposing
a
way
forward.
A
H
Was
a
it's
a
security
issue
and
we
wanted
to
get
it
into
the
backboards
really
fast
and
so
basically
little
discussion,
whether
to
get
into
v,
seven
and
then
backward
or
otherwise
and
Miles
said
that
they
had
reached
a
conclusion
that
it's
fine
with
it
an
MV
seven
in
that
back
port
in
the
regular
process.
Right.
A
And
then
that'll
go
out
in
the
regular
december
six
releases
right.
Thank
you,
okay.
So
that
was
the
last
meetings
and,
let's
move
on
to
the
agenda
for
this
week,
we
only
have
one
issue,
which
is
nine
five
to
nine,
the
buffer
runtime
deprecation
of
calling
buffer
with
it
new.
There
has
been
a
lot
of
discussion
going
on
in
that
issue.
We
still
need
more
discussion
to
come
to
a
conclusion.
B
A
B
B
G
G
C
J
J
J
A
Right-
and
I
think
I
think,
though,
there's
a
discussion
around
that
has
also
been
we're
not
closed,
necessarily
on
whether
we
should
go
and
create
a
new
API.
Instead
of
you
know,
deprecating
and
changing
the
first
one
I
think.
Maybe
the
question
is
like:
does
anybody
object
to
us,
reverting
that
for
now,
while
we
figure
out
what
we
do
want
to
do
in
this
whole
area,.
C
I
have
a
question
about
that:
I,
don't
detect
objects
to
reaction
that
good
request
in
traversing
I'd
change
about
codes.
We
think
that
it
is
there.
It
was
a
good
change
when
we
get
to
the
full
buffer
arc,
duplication
and
in
run
new
buffer
from
an
argument
and
buffer
from
an
argument
will
be
both
duplicated
for
security
reasons
and
I
hope
that
it
will
happen
in
the
next
major
radius.
You
should
get
to
that
point,
I
would
within
the
edge.
This
was
a
good
change
and
in
there
unduplicated
inch
or
not.
A
I
think
that's
you
know.
We've
been
having
a
big
discussion
on
that.
We
haven't
come
to
consensus
on
the
right
answer
yet
so
you
know
I,
don't
think
we
have
that
answer
in
terms
of
what
will
you
know
this
is
reading
it
in
eight,
the
right
answer
or
not.
That
will
have
to
continue
that
discussion,
but
it
sounds
like
a
good
idea
to
separate
that
from
do.
We
just
revert.
It
revert
this
and
then
you
know,
discuss
figure
out
what
we're
doing
and
then
plan
for
the
next
major
version
to
do
what
we
all
agree.
C
A
It
basically
means
we're
going
to
say
we
put
this
in
there's.
Definitely
some
negative
impact
to
having
done
it.
We're
not
in
cannot
an
agreement
that
it's
the
right
thing
to
do.
So,
let's
go
back
to
where
we
were,
and
then
you
know
complete
the
conversation
as
to
what
we
should
do
and
if
an
eight
we
say
we
should
deprecated
it.
We
would
do
that
if
the
answer
something
different,
we
would
do
that
something
different.
F
B
So
too,
just
in
case
how
to
warm
it
up,
so
we
would
have
to
remove
buffer
calling
buffer
without
new
for
allowing
subclass
ability
with
via
the
current
API.
If
you
want
to
do
that
and
like
I
think
it
has
become
pretty
obvious
that
we
just
we
will
never
be
able
to
remove
buffer
without
new.
So
we
just
don't
do
that
and
if
you
want
to
allow
supplies
ability
we're
going
to
add
a
new
API
I
know
there
has
been
some
resistance
to
that.
B
J
I
You
know
care
a
lot
about
this
and
having
and
have
informed
opinions
and
will
show
up
to
meetings
to
talk
about
it
and
and
sort
this
out,
because
this
is
like
this
is
the
third
time
it's
been
on
the
agenda
and-
and
we
don't
even
have
enough
people
here
to
to
like
even
just
like,
take
a
boat.
If
we
want
to
go
that
route
or
something
I
am.
A
Thinking,
though,
that
we
should
try
and
clothes
like
I
didn't
hear
anybody
say
they're
strongly
objecting
to
reverting
the
deprecation,
so
I
think.
If
that's
the
case,
it
would
be
good
to
just
close
on
that
and
then
and
then
take
the
larger
discussion,
which
is
you're
right.
Why
we're
having
trouble
closing
in
on
that?
You
know,
take
that
to
a
different
form.
To
have
that.
Can
you
know
I
guess
it
is
get.
J
F
I
It's
all
Michael
I
definitely
hear
objections
to
recording
it
out
here
too.
Well,
my
asst
doesn't
sound
like
he's
on
board
and
I
get
the
impression
that
Nikita
is
is
on
board
conditionally
that,
like
week,
yeah
yeah,
we
can
revert
it,
but
only
if
we
plan
on
but
but
probably
doesn't
want
to
revert
it
if
we're
not
going
to
reinstate
it
in
version.
Eight
am
I
misunderstanding:
Nikita,
oh
no.
A
I
I
mean
either
we
either
either
someone
can
move
for
a
vote
or
we
can
continue
that
we
can
continue
talking
here
or
we
can
delegate
it
to
a
smaller
group.
I
mean
that's
basically
the
options.
I
think-
and
I
don't
know
what
the
right
answer
is.
But
but
I
do
know
that,
like
dragging
this
out
is
probably
not
good
for
node
no.
A
F
So
like
just
as
no
like
the
latest
stats
show
that
v7
is
already
used
more
than
like
0
10
and
like
I'm,
not
sure,
maybe
someones
marked
to
like
these
discussion
threads
or
where,
like
issues
are
being
report
on
modules.
It
seemed
like
there
was
like
an
initial
heat
of
stuff,
and
then
there
wasn't
like
as
much.
Maybe
that's
just
my
impression,
I'm,
not
a
hundred
percent
sure
but
I.
F
Think,
like
I,
don't
know
what
damage
there
is
is
like
already
been
done
in
the
time
that
the
like
this
has
been
I,
which
is
about
a
month
now,
I
think
just
over
a
month.
So
like
anyone
that
had
test
failing
on
this
is
probably
fixed
that
the
rest
of
the
things
is
just
like.
Okay,
someone
complains
a
bit
of
bad
deprecation
notices,
but
that
might
be
in
for
like
at
least
a
year
and
those
will
probably
eventually
slowly
get
fixed
like
I,
don't
really
see
how
like
removed
reverting.
B
It's
usually
displays
one
of
those,
and
I
have
just
I
personally-
have
just
gotten
used
to
it
and
started
to
ignore
it,
which
is
like
not
the
point
of
it
and
I
mean
I.
Know
that
pretty
well,
that
that
is
not
the
point
but
I
guess
that
is
just
what
happens
when
you
just
have
warnings
that
always
pop
up
right.
A
I
A
C
I
I
Not
then,
this
my
opinion
only,
but
we
should
not
deprecated
this
until
unless
and
until
we
have
a
convincing
and
airtight
explanation
of
how
of
how
you
know
this
deprecation
fixes
or
enhances
security
for
the
end
user
and
right
now,
the
way
we've
deprecated
it
with
just
you
know
you
can
just
add
new
and
it'll
keep
working.
It
doesn't
do
that
and
I
think
I
think
I
think,
if
we're
going
to,
if
we'd,
if
we're
not
doing
it
for
security,
we
don't
have
a
strong
story
for
all
of
this
user
pain.
C
C
That
I
also
wanted
to
mention
for
the
security
duplication
that
I
want
to
see
the
next
measure
the
it
should
probably
print
budget
error
message.
I
mean
not
another,
a
better
one
into
the
console
like
something
something
is
duplicated
for
security
reasons,
see
this
link
for
explanation
and
explain
next
steps
for
to
do
like
upgrade
you
packages
Appalachia
dependencies,
I
check,
whether
buffer,
I'll
kiss
used
use
save
buffer.
C
If
you
want
backwards,
compatibility
with
zero
point,
12
and
four
point,
something
not
for
profit
is
four
point,
something
that
was
before
then
European
was
the
language
or
just
use
the
new
buffer,
p
and
and
the
explanation
why,
which
was
duplicated?
You
probably
need
a
link
explaining
that
and
that
song
should
be
included
to
the
duplication
of
art
in
itself.
A
A
I
A
So
you
want
to
hit
the
developer,
who
could
fix
them
and
if
they
don't
fix
them,
you
know
eventually,
if
they're
module
stops
working,
because
you
know
the
thing
goes
away
that
that's
fine,
but
the
users
don't
need
to
be
in
the
loop
of
pushing
that
necessarily
so
I'm
just
you
know
it's
here.
You
know
it's
almost
like.
We
need
a
mechanism
to
say
we
want
to
let
you
know
that
there's
a
security
issue
and
you
should
upgrade
and
it's
not
actually
suffered
from
a
deprecation
warning.
I
B
Yeah,
so
maybe
just
one
particular
point
to
adjust.
We
were
at
reverting
the
deprecation
as
we
have
it,
so
I
think
chalker
mentioned
that
and
one
of
the
email
threats,
but
anyway
it's
also
something
I
heard
watching
the
discussion
like
in
the
ecosystem
and
right
now
we
are
basically
more
pushing
people
towards
using
new
buffer
instead
of
just
buffer,
then
towards
the
actual
new
api's.
B
B
F
Kind
of
look
at
this
from
like
maybe
a
different
direction,
like
I
kind
of
think
that,
like
we're
kind
of
in
the
business
of
like
arm
allowing
people
to
do
more
stuff
with
node
so
like
if
there's
something
that
could
be
like
really
useful
to
be
extended
using
like
how
JavaScript
is
going
to
be
working
now
in
the
future,
pretty
much.
We
should
move
towards
that.
Even
if
there's
like
some
temporary
pain
around
it,.
F
Does
not
like
make
sense,
I
think
that's
like
mostly
for
where
I'm
coming
from
on
this
I
mean
I.
Think,
ideally,
we
would
probably
mean
in
our
message
regard
tell
people
to
use
like
the
new
API
is
armed.
I
mean
those
aren't
really
available
until
before.
I
think
but
like
download
counts,
suggest
that
the
majority
of
the
the
ecosystem
is
on
v4
and
v6,
even
even
if
those
people
who
are
holding
out
on
old
versions.
F
A
F
Okay,
so
that
was
the
other
thing
like
I'm,
not
sure
how
you'll
do
that,
though
right.
So
it's
like
it's
pretty
hard
to
like
message.
These
things
I
mean
the
entire
reason
we
kind
of
have
it
like
Warren.
Whenever
is
that,
so
users
can
then
go
back
to
the
libraries
and
report
them
and
kind
of
get
the
visibility.
F
That's
needed
for
library
authors
to
upgrade,
even
if
there's
like
some
pain
through
that
through
that,
like
entire
chain
like
I'm,
not
really
sure,
if
there's
actually
like
a
better
way
of
doing
it
on
like
the
distributed
scale,
that
say,
NPM
modules
like
have
right,
like
I'd
love,
to
hear.
If
there's
like
better
suggestions
but
I
think
like
I
mean
that
lets
me.
That's
maybe
night
not
the
most
comfortable
way
of
doing
it,
but
like
it
does,
it
does
work
in
the
end.
A
Being
able
to
do
new
things,
though
right
you
can
you
can
create
a
new
API
and
new
people
can
use
that
new
API
without
you
know
that
doesn't
stop
the
people
from
doing
new
things.
It
doesn't
force
people
who
don't
want
to
change
to
use
the
new
thing,
but
it
doesn't
prevent
adoption
of
the
you
know.
New
technology,
I.
E
A
G
Also
to
consider
you
know
who,
whose
responsibility
is
it
to
be
to
take
on
the
pain,
but
if
we
are
going
to
be
introducing
something
new,
because
we
think
of
the
direction
node
should
be
going
if
we
should
be
biasing
our
effort
towards
you
know,
if
it's
more
work
for
us
but
doesn't
require
look
for
the
users,
then
that's
okay.
It
requires
more
work
for
the
users
and
that's
probably
not
something
we
want
to
do.
A
G
Know
any1
does
linesman
it's
like
save
with
buffer.
If
we
do
want
to
do
a
version
of
buffer
that
is
based
on
ESX
classes
and
better
subclassing
and
yeah,
you
know
just
better
support
having
a
buffer
to
its
suck
from
a
maintenance
point
of
view
made
stuff
from
it
from
a
pure
API
design
point
of
view,
but
it
would
allow
us
to
move
forward
without
touching
an
existing
buffering,
making
the
teasers
move.
I.
F
G
F
C
C
G
B
G
G
G
So
in
theory,
if
we
landed,
this
PR
haven't
updated,
but
the
right
fer
that
I
have
out
there.
Then
we
get
put
this
deprecation,
as
we
ran
only
show
up
if
the
flag
is
turned
on
the
feedback
that
I've
received,
though
from
a
number
of
users,
is
that
they
would
never
actually
use
this
flag,
which
is
like
they.
A
A
H
A
A
H
G
Be
a
whole
intent.
Would
it
be
it's
something
you
could
turn
on
in
CI
right?
It's
something
that
you're
doing
development
you
could
use
it
periodically.
You
wouldn't
have
to
use
it
all
the
time.
So
I'm.
Not
quite
sure,
though,
if
it's
going
to
be
useful,
if
it's
folks
aren't
going
to
using
it,
so
you
go
stone,
open
question.
G
A
I
guess
we
can
pry
into
a
fleck
that,
but
you
know,
is
that
our
job
to
say
no,
it
has
to
be
so
in
your
face
that
you
can't
ignore
it
versus
well,
we'll
give
you
that
if
you,
you
should
be
and
also
message
that
you
should
be,
you
know,
module
owners.
You
should
be
turning
this
on
your
CI
so
that
you
see
this
and
that
you
know
when
we
actually
remove
them.
If
you
don't
fall
over
and
and
you're
surprised,
okay,.
I
F
I'm
I,
don't
think
that's
my
job
on
my
side,
the
conversation
but
I
mean
like
animal
if
everyone
else
really
feels
like
like
doing
it.
That
way
like
we
like
I,
feel
like
if
we're
not
doing
this
by
next
week,
like
we
should
just
drop
it,
because
it's
going
to
be
like
a
month
in
two
weeks,
almost
yeah.
G
I
I
C
I
F
Feel
like
public
sorry,
private
packages
are
like
maybe
less
of
a
problem,
because
most
of
the
people
that
are
using
them
are
going
to
be
like
in
morn
direct
contact
with
the
development
of
them.
Maybe
I'm
wrong
here,
but
I
think
that
is
probably
less
painful
than
like
modules
maintained
by
other
people
downstream.
F
C
C
C
There
are
a
lot
of
users
that
use
five
packages.
There
are
a
lot
of
private
packages,
but
each
private
package
has
significantly
doesn't
have
many
users
in
general
this
why
the
total
number
of
packages
multiplied
by
the
users
is
smilk.
Your
head
in
the
public
part
at
least
tries
to
match
this
way.
I.
E
A
Yeah
I,
I
wonder
if,
even
if
we
don't
have
a
consensus,
would
we
have
consensus
that
we
should
schedule
a
vote
now
like
either
next
week
or
at
some
fixed
time?
I
was
like
okay,
we've
been
talking
about
this.
If
it
goes
on,
I
think
we're
all
of
the
feeling
that
it
goes
gone
wrong.
That's
not
a
good
thing
can.
I
A
B
J
C
A
E
C
It
is
a
lot
less
likely
to
be
a
security
issue,
because
when
someone
uses
above
from
an
array,
it
is
in
most
cases
it
is
granted
to
pin
array,
but
there
one
that
causes
most
problems
is
the
buffer
promise
trading
conception
when
no
one
checks,
if
the
user
has
question,
is
a
link
or
someone
else,
so
we
could
duplicate
on
the
Buffalo
mistaken.
For
example,
you.
C
A
So
I
do
we
have
do.
We
have
an
objections
to
calling
for
a
vote
and
setting
that
vote
for
I.
Don't
you
know
it's
in
my
mind?
It
would
either
be.
You
know,
let's
put
it
in
the
get
github
issue
now
and
get
a
vote
or
you
know,
stay
that
we're
going
to
wait
for
those
stats
to
come
up
with
in
some
number
of
days
and
then
do
that
its
objections
to
that
or.
H
E
I
A
A
F
A
F
A
A
F
G
F
I
will
note
at
least
that
it's
a
little
bit
impressive
as
compatible
as
it
is
because
there's
a
lot
of
little
minor
nuances
in
the
way
that,
over
the
time
you
know
the
NPM
ecosystem
has
gotten
used
to
like
installing
things.
So
like
previous
solutions,
even
if
they
were
faster,
I'm
typically
had
lots
of
education.
So
that's
at
least
impressive.
F
F
I
H
Yeah
I
updated
a
little
earlier,
so
next
CTC
is
next
week.
This
one
would
be
to
20
hundred
UTC,
so
12pm
Pacific
next
tsc
is
Thursday,
although
I
think
that
we
may
I
need
to
look
with
that
may
be
cancelled
because
of
the
note
interactive
stuff,
but
it's
scheduled
for
next
Thursday.
Twenty
hundred
yeah,
nothing
else.
Diagnostics
WG,
is
that
the
class.