►
Description
A
A
G
H
And
no
updates
well
we're
working
with
some
people
from
I
think
both
the
CTC
and
TSE
about
some
strategies
moving
forward
in
the
community
regarding
d.
So
that's
not
really
as
much
of
an
update
as
a
stay
tuned,
we'll
be
filing
some
issues
in
the
next
couple
days
over
that.
So
there's
that
on
that
side
and
then
the
certification
just
to
keep
people
updated
for
those
who
would
like
to
be
involved.
The
next
part
of
the
the
project
with
certification
in
node
is
coming
to
fruition
with
the
scoping.
H
A
Thank
You
Tracy
I,
see
we
don't
have
the
door.
Ok,
so
I'm.
Next
PR
review
more
investigation
into
the
possibility
of
an
HTTP
to
implementation.
I've
been
working
on
an
ICU
module
proposal
lens
and
involved
in
some
of
the
discussions
are
running
close
to
be
such
a
Tracy
gets
mentioned.
So
that's
me
next
would
be
Josh.
I
J
A
J
K
A
L
N
Yeah
so
I
on-boarded
Josh
this
morning
ray
well
a
few
hours
ago.
I
guess
whether
it's
morning
depends
on
where
you
are
doing
some
me
s,
length,
updates
and
enabling
rules
here
and
there,
especially
on
like
new
things
that
were
starting
to
use
that
are
appearing.
The
code
base
inconsistent
way
and
we
want
them
to
stay
consistent
and
a
bunch
of
small
test
to
plug
holes
and
test
coverage.
N
A
Okay,
that
does
it
for
the
scanned
up
portion.
Let's
see
if
we
have
a
review
of
last
meeting
in
here-
oh
yeah,
previous
meeting,
so
we
had
a
number
of
items.
Last
week
we
talked
about
the
450
proposal
needing
to
get
some
testing
and
tested.
That's
out,
we
talked
about
hard
deprecation
of
the
buffer
constructor
I.
A
A
Again
we're
going
to
talk
about
that
today
we
talked
about
the
errors
module
decision.
There
I
knew
this
I
decide
to
pull
this
off
the
agenda
for
today,
because
it's
just
additional
work
that
needs
to
be
done
here.
We
talked
about
introducing
a
staging
branch
for
stable
release
streams
and
decided
to
continue
a
discussion
in
github.
A
N
N
O
O
F
L
A
A
B
Yeah
this,
like
that
there
are
three
options:
basically
not
deprecating
the
buffer
constructor
at
all,
deprecating
it
when
called
without
new.
So
only
new
buffer
with
arguments
works
or
completely
deprecating
it
and
the
first
option,
not
abrogating
it
at
all,
would
make
it
pretty
hard
to
subclass
buffer
in
the
future,
because
that
is
going
to
break
new
buffer
and
buffer
without
new.
O
A
M
O
So
we
still
have
0,
10
or
12
out
there
that
don't
I,
don't
think
we
haven't
backported
any
updates
in
there.
So
if
we
deprecated
the
constructor,
then
people
who
are
supporting
multiple
versions
are
gonna,
be
in
an
awkward
position
of
having
to
do
feature.
Checking
I
can't
just
switch
all
their
API
for
the
Union
I
mean.
M
B
G
M
The
the
first
yes,
the
second
one,
deprecated
all
non,
you
int
of
signatures,
there's
new
you
an
eight
array
signatures
so
like
passing
encoding,
xand
stuff
with
strings.
That
would
be
the
intent
there,
but
the
two
are
not
like.
Even
if
we
move
to
extending
you
an
eight
array,
we
can
still
support
the
old
API,
so
the
two
or
not.
A
M
I
G
D
G
M
N
F
A
N
Yeah
Yeah
right,
if
yeah,
okay,
okay
so-
and
it
will
continue
to
be
like
that
into
into
version
8,
because
that's
when
it's
the
end
of
life
and
then
and
in
the
earliest
it
would
be
removed,
would
be
the
earliest.
Whatever
we're
talking
about,
deprecating
will
be
fully
removed,
would
be
version
I.
I.
M
M
G
How
many
of
these
people
I
mean?
We
probably
need
to
get
the
statistics
on
it
to
see
how
many
people
are
actually
like,
requiring
the
module,
because
what
we
could
do
is
we
could
have
it
if
you
require
it
via
the
module.
We
break
that,
but
we
have
like
some
sort
of
Shem
for
the
global
and
the
global,
just
like
kind
of
works
keeps
working,
but
that
work.
B
A
Okay,
so
I
guess
you
know
we
have
a
number
of
other
items
on
the
agenda.
It
sounds
like
there's
still
more
that
we
need
to
get
more
discussion.
We
need
to
have
on
this,
so
why
don't
we
bring
the
conversation
back
to
github
I
get
this
stinked
feeling
that
we
do
need
to
have
two
separate
conversations,
so
maybe
splitting
it
into
two
separate
key
ours
would
be
the
right
thing
to
do,
one
that
does
the
duplication
for
the
new
and
another
one
later
on.
A
O
A
Okay,
so
let's
go
back
to
get
up
on
that
one
and
move
on
to
the
next
issue,
which
is
6413,
revert,
the
fs
add
a
temporary
fix
to
reevaluation
support
the
old
graceful
at
best
issue,
where
this
is
that,
since
last
week,
miles
got
a
tix
landed
into
graceful,
fsbo
township
breakfast
on
that
and
kind
of.
Let
us
know
where
the
statuses.
L
Sorry,
my
call
dropped
for
a
second
James.
Is
it
safe
to
assume
you
were
talking
to
me
there?
Yes,
yes,
so
we
have
a
couple
changes
going
into
graceful,
efest
that
use
internal
util
graceful
if
s3
and
I
believe
too
I'm
not
sure
about
1.
I'd
have
to
double
check
that
the
way
that
it
actually
monkey
patch
graceful
if
s
was
to
go
and
grab
the
source
code
of
graceful
if
s
and
then
run
that
into
a
vm
and
then
it
would
execute
all
of
it.
This
worked.
L
You
know
finding
fine
and
dandy
until
we
threw
something
from
internal
util
in
there
and
then
that
caused
everything
to
explode.
That
originally
happened
just
before
node
v6
and
we
backed
it
out
and
in
lined
the
code
for
that
deprecation
warning.
It
was
print
deprecation
message
in
particular
that
was
causing
the
problem.
L
So
it's
now
on
the
plate
to
come
back
in
and
there's
you
know
about
three
other
commits
that
are
also
being
blocked
right
now
by
this
decision,
one
of
them
has
to
do
with
I
believe
I,
believe
I
James
is
working
on
stuff,
with
error
messages
and
I.
Think
there's
some
other
deprecation
warnings
that
are
getting
put
in
there
as
well.
I'd
have
to
go
through
and
read
them
all
to
get
on
top
of
it,
but
to
the
issue
that
we're
running
into
right
now
is
graceful
fs3.
L
We
got
that
patch
in
there
that
it
solves
this
one
problem,
but
now
we
have
three
more
and
there's
no
guarantee
moving
forward,
that
there
won't
be
a
fifth
one
or
61
or
a
seventh
one.
I
think
that
there's
probably
a
limited
number
of
functions
from
internal
util
that
we
put
in
there
and
you
know,
thinking
out
loud,
there's,
probably
a
couple
other
ways
that
we
could
solve
this.
But
the
problem
that
we
end
up
with
today,
in
particular,
is
the
most
important
one
is
gulp,
so
gulp
version
3
relies
on
graceful.
Fs
version.
L
3
well
relies
on
vinyl
offense,
which
the
version
of
ifs
that
it
relies
on
relies
itself
on
graceful,
FS
version.
3
I've
had
a
conversation
with
Blaine
is
you
know
the
current
maintainer
of
the
project?
He
is
extremely
reluctant
to
bump
graceful
efest
due
to
December
major
breaking
changes.
He's
had
issues
in
the
past
with
bumping
these
kinds
of
dependencies
in
breaking
things
in
the
ecosystem.
There's
nothing
in
the
test
suite
right
now.
That
is
obviously
broken
from
the
bump.
L
I've
done
some
tests
on
that,
but
I've
not
had
the
ability
to
go
through,
and
actually
you
know
not
just
testing
testing
suites
for
testing,
workflows
and
testing
a
variety
of
other.
You
know
gulp
plugins
that
I'll
rely
on
this
there's
a
new
issues.
I've
got
opened
today,
81
49
by
Isaac's,
just
kind
of
a
which
was
a
more
overarching
question
about
the
benefits
of
internal
which
I'm
not
going
to
get
into
too
much.
But
I
do
think
that
it's
worth
it's
worth
discussing.
L
You
know
we.
We
don't
want
to
stop
moving
core
forward
due
to
internal
modules,
but
at
the
same
time
we
don't
want
to
break
gulp,
and
I
think
that
the
if
we
went
through,
I
got
a
from
chalker
a
data
set
to
go
through
and
look
at
all
the
stuff.
That's
relying
on
graceful,
FS
version,
2
and
version
3
I
believe
ember
CLI
may
be
broken
by
this
as
well,
but
it's
a
non-trivial
ecosystem.
Breakage,
if
we
start
putting
these
internal
modules
into.
L
L
H
L
Certain
coding
right,
it
has
a
couple
functions
that
move
into
their
there's
the
errors
PR
that
James
was
working
on,
which
makes
all
of
the
error
errors
actually
use
internal
/
errors
that
will
break
it
and
that's
an
extremely
large
amount
of
code
to
just
shoot
them
in
and
another
one
is
to
rated
move
string.
Two
flags
into
internal
FS,
so
kind
of
I
guess
like
the
potential
problem,
is
that
a
this
doesn't
really
scale
for
us
to
go
and
just
start
dumping
all
of
internal
into
integrates
full
of
s.
L
A
O
O
A
You
use
the
errors,
the
air
thing
as
an
example
right
we're
trying
to
you
know
this
PR
is
trying
to
make
it
so
that
we
don't
have
to
treat
error
message,
changes
December,
majors
right
by
assigning
an
error
code
to
everything.
Alright,
the
point
of
putting
this
into
this
internal
errors
module
is
to
make
it
easily
reusable
consistent
across
you
know,
all
of
all
core
and
to
reduce
the
possibility
of
inconsistency
in
errors.
A
We'd
end
up
having
to
do
is
have
codes
specifically
within
FS
that
just
you
know
you
know,
does
its
own
error
handling
and
wouldn't
bill
to
use,
throw
internal
errors?
We
could
still
do
it.
It
just
makes
it
a
total
pain.
Now
it's
not
unusual
we're
having
to
do
that.
Currently,
the
streams,
if
you
look
at
that,
you
know,
I
have
to
create
to
the
streams
module
special
because
of
the
readable
streams
model.
So
it's
not
without
precedent.
We
can
do
it.
It
just
is
it's
a
pain
right.
It
makes
me
significantly
harder.
L
So
one
thing
that
I
was
thinking
that
we
could
potentially
do
so.
The
way
in
which
graceful
FS
is
doing
this
right
now
is
using
processed
up
bindings
native
EFS
to
grab
the
source
code.
Is
there
any
way
that
we
can
either
a
have
the
call
to
process
the
findings
actually
like
shin
in
the
internal
stuff
or
some
sort
of
added
API
that
allows
that
to
work?
That's.
L
G
L
The
test
suite
still
passes,
but
there's
no
guarantee
that
it's
not
going
to
cause
ecosystem
breakage,
and
so
the
issue
here
is
kind
of
like
a
catch-22.
It's
like.
We
could
upgrade
it
and
then
maybe
break
it
and
have
note
7
support
or
we
could
not
upgrade
it
and
know
that
we
have
support
on
node,
6
and
lower
and
hadn't
leave
a
broken
on
node
7.
M
Hey
what
then,
whatever
happened
to
your
peers
her
forever
ago,
Isaac
got
old,
they
see
about
the
first
breakage
that
happen
and
you
challenged
him
and
said:
yes,
you
can
do
it
a
steinway,
he
said
no,
and
then
you
spend
it
a
PR
that
did
it
and
then
it
got
reverted
because
they
were
supporting
like
node
0
point
8,
which
they
don't
support.
It
like
what
happened
with
that
bad.
D
G
L
A
H
A
L
Guess
there
is
like
I
mean
if
Isaac
is
willing
to
work
with
us
on
patching
it
and
the
number
of
patches
that
we
have
are
going
to
be
limited.
It's
not
like
there's
going
to
be
hundreds
and
we,
you
know
if
we
could
add
graceful.
Fs
version
3,
for
example,
to
carrying
the
gold
mine
and
make
sure
that
that's
run
like
I,
for
myself
would
raise
my
hand
on
being,
like
you
know,
the
shepherd
of
making
sure
that
those
things
land.
L
A
Do
we
do
have
another
possible
option
so
similar
to
how
we
do
with
streams
where
we
have
the
separate,
readable
streams
module
if
we
have
a
separate
maintained,
FS
module
baby
that
would
that
could
be
updated
and
maintained
as
we
go
and
used
as
an
alternative,
the
core
FS
module
went.
You
know
what
you
know
without
the
dependencies
on
internal.
D
L
Fsv,
for
is
fine,
mostly.
I
wanted
to
see
this
one
land
and
induce
some
testing
see
that
it
actually
worked
and
then
back
forward
it
to
v2,
and
so
we
kind
of
hit
where
we
hit
earlier
this
week,
where
we
saw
that
this
doesn't
scale.
So
I
wanted
to
come
up
with
a
solution
before
you
know
pushing
forward
with
more
patches.
Okay,.
D
This
exactly
what
gulp
doesn't
want
to
do,
and
there
is
no
difference
between
version
3,
visa,
page
and
version
4
days
for
the
festival
related
to
version
four.
Just
because
of
the
page.
That's
why
they
bumped
the
major
version,
and
there
is
in
fact
one
compatibility
to
invention
three
in
version:
four,
it's
when
something
other
than
graceful.
First
monkey
basis,
the
first
module
before
graceful
first
is
loaded.
D
In
that
case,
graceful
fast
version
3
would
await
the
market
page
and
use
a
clean
version
for
their
first
model,
while
graceful
first
version
4
would
use
their
month
based
model.
I
can't
come
up
with
any
other
in
the
country
incompatibility
between
version
3
in
version
four,
and
they
believe
this,
while
graceful
fast
maturation.
Northbound
did.
D
D
A
A
So
it
definitely
seems
like
there's.
This
is
a
larger
discussion.
We
need
to
have
and
I
don't
think
we're
going
to
be
able
to
wrap
it
up
concisely.
We
do
have
a
question
you
know
for,
for
this
PR
6413
wish
fest
was
you.
We
do
have
a
fix
for
this
specific
one
in
graceful
with
us,
and
you
know,
there's
you
know
this.
Particular
one
has
been
seeing
their
open
for
a
while.
We
need
to
decide
whether
we
want
to
land
it
before
v7
or
wait
till
after
v7.
A
A
A
O
Yeah
I
breakfast
just
slowing
down
with
this
I
know
it's
frustrating,
but
if
you
consider
the
class
of
users
impacted
by
this
particularly
grunt
users,
or
is
it
gulp
gulp
uses?
This
is
the
class
of
user
who
are
they
a
lot
of
them?
Are
not
primary?
No
users
they're
using
a
tool
chain
and
so
having
stuff
brake
on
them
and
having.
H
O
C
P
P
L
Recess
to
patch,
for
this
would
not
be
difficult.
It
would
not
take
a
long
time.
I
do
want
to
express
a
slightly
different
opinion
on
this,
though,
if
you're
looking
at
Twitter,
if
you're
looking
at
github
there's
a
lot
of
people
who
are
contributors
to
the
ecosystem,
who
do
not
feel
like
we're
listening
to
them
and
feel
like
we're
kind
of
bulldozing
forward.
I
personally,
don't
feel
like
there's
any
technical
benefit
to
landing
this
patch
versus
not
landing.
It
I
mean
it's
pretty
much
the
same
thing.
L
A
All
right,
well,
then,
I
mean
I,
given
that
it
didn't
like
we
have
a
consensus
to
land
this
one
I
mean
you
know
so
in
about
forty
seven,
it
is
one
not
land,
so
the
next
target
would
be
v8
and
keeping
in
mind
that
whatever
lands
in
v8,
you
know
we
we
support
to
the
next.
You
know,
36
months
after
that,
right
11
v8
gets
cut.
So
we
need
to
you
know
very
carefully,
weigh
the
decision
on
whether
this
goes.
You
know
whether
we
land
these
changes
by
v8
or
not,
but
I'm.
A
L
P
L
So
one
big
thing
that
could
change
between
now
and
then
would
be
gulps
for
landing,
losing
the
graceful,
fs3
dependency
and
having
a
transition
of
the
ecosystem
towards
it,
I
think
in
the
next
six
months.
If
that
hasn't
happened,
we
can
apply
more
pressure
towards
goal,
upgrade
the
graceful
FS
invoked
version.
3
I
also
think
that
we
can
try
to
do
some
more
eco
system
testing
before
v7
on
gulp,
to
see
if
we
can't
actually
get
the
upgrades
happening
without
breaking
people.
There's
another
thing
that
we
can
explore
right.
P
J
A
The
conversation
then
missing.
If
and
when
that
happens,
I
think
the
point
here
is
I
mean
I.
I
would
very
much
like
you
see
the
plan
now,
but
I
definitely
see
the
point
of
slowing
down,
saying
it.
Okay,
we're
it's
moved,
we're
gonna,
listen
they're,
going
to
willing
to
work
with
you
just
work
with
us
and
let's
figure
out
a
path
between
now
in
the
next
six
months
of
something
that
is
that
lil
works.
That
allows
us
to
keep
moving
forward.
A
M
K
M
So
say,
gold
upgrades
right
for
is
released
honestly.
Do
you
believe
enough?
The
ecosystem
will
upgraded
from
about
three
to
four
for
us
to
change
it
because
I've
been
told
almost
as
entire
time
that
the
community
that
uses
gold
doesn't
like
to
upgrade
at
all.
So
why
would
they
upgrade
from
three
to
four?
Because.
O
Yeah
and
and
and
if
we,
if
we
still
have
a
supported
version
like
you
know,
v4,
it
still
worked
all
them
in
the
recommendation
for
them.
If
you're
using
gulp
three,
then
you
use
node.js
version
four
or
five
or
six
or
seven
so
yeah
and
they're
bits,
not
version
8,
but
yeah
I
found
here
I'm.
If
there's
a
choice
between
put
inflicting
patent
on
a
lot
of
users
but
parts
having
a
living
to
show
a
little
bit
of
pain,
I'd
block
for.
A
Okay,
we're
quickly
coming
up
to
the
end
I'm
going
to
go
ahead
and
call
it
on
this
particular
thread:
let's
defer
the
next
one,
the
6306
and
that's
introducing
staging
branch
for
stable
release.
Extremes
we've
talked
about
that
before
another.
We
had
consensus
on
it.
Let's
defer
that
until
next
week,
for
just
for
sake
of
time,
issues
3979
seeking
legal
advice
on
license
and
copyright
box
rod,
I
think
this
is
something
that
you
just
needs
to
escalate
it
to
the
legal
committee.
I,
don't
think
we've
ever
got
closure.
O
O
A
H
A
Okay,
then,
why
don't
we
run?
We
do
this,
let's
set
up
a
all
thing
to
do
to
get
a
doodle
set
up
some
of
the
next
week
and
we
can
have
a
dedicated
meeting
for
four
modules
or
I
can
ask
everyone.
You
know
we
could
extend
the
next
week's
meeting,
maybe
by
a
half
an
hour
or
an
hour
on
either
side.
You
started
you're
ended
late
and
dedicate
a
portion
of
that
extended
time
to
to
module.
So
what
do
people
prefer.
N
G
N
G
H
A
Yeah
that
that's
been
kind
of
an
open
discussion,
so
I
think
we
should
definitely
make
sure
it's
on
on
the
agenda
out.
Do
we
have
a
TFC
meeting
tomorrow
or
is
it
next
week
I
remember
next
week
guys
we
make
six
okay.
So
let's
make
sure
it's
on
the
agenda
for
next
week
to
discuss
them
know
and
let
him
know.