►
Description
A
A
B
A
B
A
So
I
think
that
at
least
rich
thought
that
we
should
at
least
well.
You
did
think
we
should
have
it
on
the
agenda
in
terms
of
progressing
it.
I
don't
know
if
we
have
anybody
on.
The
call
who
is
you
know,
is
an
opposition
and
wants
to
discuss
why
I
said
I
do
see
a
bunch
of
people
and
they're
like
well
I,
don't
love
it
but
see
why
it
would
make
sense.
A
A
D
So
we
did
land
a
somewhat
similar
API
recently
to
list
all
of
the
internal
modules
that
are
available.
There
are
people
in
the
ecosystem
who
had
tools
that
were
constantly
being
broken.
Every
time
we
added
api's,
so
I
could
imagine
for
any
tools
that
are
like
cooking
up
environment
flags
wanting
to
know
environment
play,
but
this
offers
a
similar
use
case,
but
it
does
seem
like
people
may
have
had
an
issue
with
the
way
this
was
specifically
implemented.
I.
A
B
C
Yeah
I
agree:
this
is
about
API
surface
area.
It's
been
a
really
strong
advancement
of
API
surface
area,
recently
I'm
just
I'm,
not
fair.
To
be
honest,
these
things
have
kind
of
minor
justifications,
often
convenience
marshal.
Convenience
is
usually
the
best
reason
to
expand
the
surface
area
that
we
have
to
support,
support
tests
that
impacts
every
time
we
make
a
little
change.
D
Case
then,
does
bring
up
an
interesting
point
in
like
the
first
response,
though,
that
like
it
doesn't
address
the
eight
flags
at
all
and
it's
not
a
comprehensive
list.
The
white
list
is
not
all
of
the
flags
that
are
potentially
available
in
the
run,
but
I
would
like
to
suggest
that
perhaps,
since
we
a
don't,
have
quorum
and
B,
we
don't
have
the
stakeholders
that
maybe
we
punt
this
to
a
future
meeting.
Yeah.
A
D
C
Mean
I
can
see
the
use
case
here
from
mocker
I,
understand
that
and
I
put
similar
things
with
similar
things
that
can't
with
work
a
farm
before.
But
you
know
I,
just
it's
like.
Have
your
own
whitelist
just
use
a
white
list
of
flags
that
have
to
be
passed.
It's
not
that
hard
and
we
don't
have
that
many
flags
and
then
there's
the
point
about
the
v8
flags
like
we
can't
be
comprehensive
in
any
way
and-
and
you
think
about
the
mock
occasion-
VA
Flags.
C
It
is
legitimate
to
pop
beep
up,
perhaps
passing
v8
flags
into
your
unit
test
mm-hmm,
and
if
we
can't
list
the
VA
flags
in
what
that
doesn't
even
solve
their
problem,
they're
still
gonna
have
to
whitelist,
somehow
or
finally
running
a
test
runner
and
having
it
final
because
you
passed
the
wrong
flags.
That's
a
file.
You'd
filed
your
tests.
B
B
D
So
I
think
that
seems
reasonable.
Then,
like
I
mean,
if
no
one
has
in
the
issue
itself
like
raised
unofficial
objection,
if
someone's
willing
to
object
in
there,
we
could
see
if
we
can
get
consensus
around
closing
it,
and
if
there
isn't
consensus
around
closing
it,
we
can
bring
it
back
to
the
TSE.
With
a
more
explicit
like
with
an
actual
stakeholder,
it.
C
E
D
D
D
A
A
D
Vowels,
nothing
to
add,
since,
like
the
last
board
meeting,
we
had
where
the
calm
calm
got,
the
directorship
there's
been
work
on
going
to
just
get
their
Charter
up-to-date
back
and
forth
through
legal
and
stakeholders
and
just
making
sure
you
know
all
the
t's
and
eyes
and
whatnot
are
figured
out.
That
is
that
for
it
yeah
there
we
go
okay.
D
Modules
are
going
well,
we've
gotten
through
a
lot
of
the
use
cases,
and
we
I
have
a
proposal
for
a
potential
like
kind
of
holistic
solution
and
I
know
that
some
other
people
from
the
team
are
starting
to
put
together
some
solutions
as
well.
I
opened
a
pull
request
today.
To
add
import
got
meta
is
one
of
the
incremental
improvements
that
would
be
necessary
for
the
proposal
that
I
made.
D
We
are
also
starting
to
talk
about
deadlines,
because
if
we
want
to
ship
this
without
a
flag,
you
know
some
time
before
maybe
2020.
It
is
something
that
we
need
to
start
thinking
about.
Since
no.28
goes
end-of-life
at
the
end
of
2019.
You
know
if
we
can
get
a
working
implementation,
not
behind
a
flag
with
the
version
of
v8
that
we
have
inside
of
node
10,
which
is
very
possible,
and
it
may
even
be
possible
in
node
8.
D
We
could
have
a
pretty
reasonable
timeline
to
an
unflagged
version
if
we
can
reach
consensus
as
some
of
the
contentious
topics.
The
main
contentious
topic
still
are
mostly
around
transparent,
Interop
and
module
specifier
resolution,
but
there's
also
a
lot
of
discussion
happening
right
now
around
hooks
and
specifically
custom
loaders
and
how
that
could
work.
If
anyone
has
more
questions,
please
feel
free
to
grab
me
I'm
more
than
to
find
some
time
and
get
you
up
today.
So
sorry,.
D
Specify
resolution,
if
for
those
in
the
group
who
haven't
been
keeping
up-to-date
on
you,
know
all
the
millions
of
things
that
are
happening
on
the
internet,
there's
a
really
interesting
proposal
right
down
from
Dominic
Dunham
denna
Cola
called
the
package
name
maps
I'll
drop
a
link
into
the
chat,
but
package
name
maps
is
a
proposal
that
would
allow
an
install
time
tooling
to
generate
a
manifest
that
could
be
consumed
by
browsers
to
allow
for
named
import
to
allow
for
bear
imports
of
modules
in
the
browser.
So
you
could
import
lodash
or
import
anything.
D
That's
npm
installed.
The
hope
of
this
proposal
would
be
you
know.
If
we
can
coalesce
some
of
some
of
the
stuff
around
specify
resolution,
we
should
potentially
be
able
to
have
a
path
board
for
NPM
Inge
NPM,
installing
universal
modules
that
could
be
used
on
either
node
or
the
browser
without
any
differences.
D
Jeremiah
is
asking
if
this
proposal
still
resolves
and
modules
differently.
The
resolution
algorithm
is
different
and
we
are
discussing
in
the
module
working
group
if
we
should
be
introducing
some
of
those
constraints
to
our
ESM
loader
in
either
a
default
loader
or
as
a
custom
loader.
The
pluggable
loader
proposal
has
the
resolution
constraints
specifically
required
extensions
and
no
index
J
Essen,
as
proposed
constraints
on
a
default
loader
and
allowing
us
to
ship
an
extended
loader
that
people
could
add
to
their
package.json
to
progressively
enhance
their
applications.
Loading
capabilities.
A
A
The
teams
working
on
is
the
proposal
for
adding
new
API
is
experimental,
so
we
want
to
be
able
to
add
new
api's,
but
have
them
guarded
by
a
define
so
that
we
can
have
some
baking
time
before
they
become
part
of
the
API
and
there's
also
proposal
being
worked
on
for
guidance
on
adding
the
new
API.
So
basically
some
principles.
A
That
say
you
know
what
kind
of
API
should
we
or
shouldn't
we
be
adding
and
some
additional
sort
of
you
know,
review
and
sign
off
type
things
on
that
front,
so
that
would
require
you
know,
TSC
buy-in.
If
we're
gonna
have
you
know,
for
example,
somebody
from
the
n
API
team
sign
off
on
new
API
is
going
going
in,
so
those
are
just
two
things.
Next
thing
is
open:
SSL
evolution,
broad.
A
E
A
D
D
What
one
that
was
floated
was,
you
know
around
code
owners
or
having
more
decoupled
understanding
of
like
parts
of
the
code
base
so
like
we
have
kind
of
working
groups
that
own
parts
of
the
code
base,
but
maybe
it
could
be
code
owners,
there's
definitely
mixed
feelings
on
whether
or
not
that's
actually
a
solution
within
Fort,
but
it
was
something
that
was
discussed.
Another
big
thing
that
we
discussed,
which
I
think
leads
into
governance,
was
around
our
LTS
policy
and
specifically
backwards.
D
I
know
that
there
was
an
issue
opened
and
I
owe
it
a
response,
but
specifically
on
kind
of
changing
what
our
definition
of
done
is.
Specifically,
we
closed
pull
request
now
when
they
land
on
master
and
the
discussion
was
whether
or
not
we
should
be
considering
not
closing
PO
requests
until
all
of
the
back
parts
had
been
audited,
landed
or
pull
request
opened
as
necessary.
I
believe
that
this
does
fall
under
governance.
B
Yeah,
so
there
was
a
bunch
of
progress
around
the
collab
summit,
which
I
haven't
been
able
to
get
an
update
on
yet
there's
some
NPM
modules
for
this
now
FS
source
and
apesh
think
and
it's
a
bunch
more
status
in
the
Bob
repo,
which
is
still
on
my
github
at
the
current
time.
So
official
f23
slash,
Bob
yeah,
so
there's
some
progress
are
in
there,
but
nothing
since
the
collapse
out.
B
A
A
D
D
So
I
really
think
that
namespaces
are
something
that
we
need
and
we
need
to
move
on
faster
than
we
have
been
every
time
we
look
to
introduce
new
API.
Is
this?
The
the
shadowing
of
things
on
NPM
becomes
a
blocker
for
them.
Moving
forward,
you
push
some
things
through,
it
should
be
to
is
able
to
be
pushed
through
the
performance
hooks
or
the
performance.
Api
stuff
was
able
to
be
pushed
through.
D
D
For
broadly
support,
and
while
those
two
both
independently,
you
know,
need
to
have
more
evaluation.
Aside
from
it,
they
are
strongly
blocked
on
us
not
having
namespace
things
in
this
is
also
something
that
blocked
our
ability
to
do
like
FS
promises,
if
a
slash
promises
and
had
us
put
it
on
FS
stop
promises
because
of
some
of
the
expectations
that
we
have
on
the
non
names
based
API.
D
There's
questions
about
deciding
what
kind
of
symbol
to
use
for
this
we've
gone
back
and
forth
on
a
couple
different
things.
I
would
like
to
highly
suggest
that
we
consider
doing
the
at
nodejs
symbol.
We
have
that
namespace
available
to
us
via
NPM,
tc39
and
I've
mentioned
this
before,
but
tc39
is
looking
into.
Namespaces
is
something
that
could
exist
as
a
language
level
feature
I
brought
up
the
fact
that
node
was
very
interested
in
namespaces
at
B.
D
I
think
this
would
have
been
the
March
meeting,
and
the
advice
that
I
received
from
the
committee
was
for
us
to
not
block
on
tc39.
There
are
no
proposals
right
now
for
it,
although
it
is
something
that's
been
discussed,
it's
something.
I
could
also
bring
to
tc39
myself
and
try
to
push
through,
but
even
if
I
brought
it
to
the
next
meeting,
which
I
won't
be
at
even
if
it
came
to
the
July
meeting,
he
would,
it
would
likely
be
I
mean
the
fastest.
D
We
would
probably
see
something
like
this
land
would
be
9
to
12
months,
and
that
would
be
very
aggressive,
so
I
I
don't
think
that
it
makes
sense
for
us
to
block
for
more
than
a
year
out
and
I
think
with
the
knowledge
that
another
namespace
could
be
coming
from
the
language.
Our
best
bet
is
to
move
forward
with
what
our
eco
system
is
already
using
and
to
participate
in
the
conversation
around
what
the
namespace
would
be
at
the
standards
body,
and
you
know,
move
forward
more
wholesale
at
that
point.
D
Matteo
had
had
given
some
pushback
about
us.
You
know
moving
full
forward
into
the
new
namespace
and,
due
to
that,
I
think
it
makes
a
ton
of
sense
for
us
to
alias
the
old
API
is
in
the
namespace,
but
to
not
make
that
like
what
we
document
so
like
still
keep
our
document
to
the
non
names
based
api's
for
all
the
api's
that
didn't
start
in
the
namespace,
but
to
only
move
new
api's
into
the
namespace
and
kind
of
like
moving
forward.
D
We
would
probably
want
to
look
at
back
porting
that
to
our
LTS
branches
so
that
those
aliases
are
available,
but
again
not
the
default
or
the
expected
default.
We
can't
simply
make
it
a
folder
due
to
security
reasons,
because-
and
this
is
one
of
the
things
that
we
would
primarily
have
to
think
about
what
the
@
nodejs
slash
namespace-
is
that
it
would
very
much
be
possible
on
versions
that
don't
have
the
namespace
api's
for
people
to
potentially
have
modules
that
could
take
advantage
of
that.
D
So
there
is
a
security
concern
there
and
that's
kind
of
my
high
level
view
on
all
of
this.
I
know
that
we've
been
discussing
this,
for
you
know
over
six
months,
is
something
that
we
want
to
do
I'm
more
than
happy
to
help
champion
and
push
this
forward.
But
I
do
think
it's
something
though
we
need
to
kind
of
get
moving
on.
I
heard
that
there
might
be
a
pull
request.
Open
I
tried
to
find
it,
but
couldn't
does
anybody
know
if
there
is
currently
a
pull
request
open
for
namespaces
I.
D
Makes
sense,
does
anybody
have
any
thoughts
or
concerns
about
kind
of
like
the
proposal
that
I
just
made
of
how
we
should
approach
this
I
know
Jeremiah,
you
had
vote
you
we
on
Twitter
we're
kind
of
going
back
and
forth
about,
like
you
know
the
potential
other
namespaces
being
you're
concerned
even
thoughts.
Yeah.
B
So
I
put
some
thoughts
into
that
thread.
Basically,
I'd
really
like
to
only
move
two
namespaces
once
and
I'd,
rather
just
keep
doing
things
I'm
mostly
normal
way
until
we
get
to
namespaces
and
then
have
namespaces,
probably
return,
either
use
modules
that
use
module,
compatible,
stuff
and
also
return
promise
fide
async
API
is
by
default
so
that
we
can
just
do
a
single
move
into
essentially
future
stuff,
rather
than
I've
like
three
or
four
or
five
in
the
end.
B
A
C
That's
my
addition
to
that
conversation
is
a
really
like
the
idea
of
making
it
easier
for
us
to
add
extra
stuff
into
core,
like
broadly
mine,
but
these
things
can
exist
in
New
Zealand
and
they
should
do
that's
how
we
do
node
and
just
push
to
add
more
and
more
stuff
to
core.
It's
really
concerning
and
I'm
I'm,
not
a
huge
fan
of
making
that
easier.
C
I
like
they're,
being
friction
to
that,
like
the
use
case
for
this,
for
some
kind
of
extension
to
our
loading
is
for
promises
and
other
other
ways
to
interact
with
existing
api's.
That's
what
I
find
most
compelling,
but
I
actually
don't
even
think
that
needs
proper
namespaces
I.
You
know,
FS
slashed
promises,
make
sense
to
me
and
that's
enough
for
that's
kind
of
support.
I.
A
D
Mean
I'll
be
honest
if
we
don't
think
that
we're
gonna
reach
consensus
easily
and
it
sounds
like
we
have
like
legitimate
objectors.
Is
this
something
that
we
should
just
push
to
a
vote
in
a
future
TSE
meeting?
Or
is
this
something
that
we
should
get
an
implementation
together
on
and
try
to
drive
consensus
in
the
issue?
Tracker
and
I'm
just
trying
to
figure
out
like
if
it
makes
sense
to
try
to
move
this
forward?
If
we
have
enough
people
who
just
don't
even
think
that
this
should
happen
to
begin
with,
I
guess.
C
My
question
to
you
Maas
would
be:
do
you
think
that
there's
been
enough
engagement
from
TRC
members?
Aside
from
this
meeting,
has
it
been
covered
in
other
meetings?
Where
has
there
been
enough
engagement,
broad
engagement
for
the
TSV
on
the
Asian
tiger
yeah?
If
not,
then
let's
keep
it
on
the
agenda
and
keep
the
discussion
going
so
I
mean
it's
not
bad.
To
have
this
discussion
repeating
the
same
in
in
the
meeting
next
week,
when
there's
a
difference
lap
times
lot
from
different
people,
whip
in
yeah.
D
Think
that
that
the
rod
like
what
you
hinted
at
and
perhaps
there's
a
bigger
issue
for
us
to
come
up
with,
is
like
our
core
principles
around
API
surface.
It
sounds
like
you
have
legitimate
concerns
there
about
the
direction
that
we're
going
and
that
perhaps,
as
a
committee,
we
need
to
make
a
decision
about
what
we
want
to
do
with
the
platform
in
X
number
of
years
regarding
API
surface,
and
it
sounds
like
that
decision
will
be
a
key
indicator
as
to
like
whether
or
not
we
need
space
right
now.
D
D
C
Possibly
but
I
don't
I,
don't
see,
I
mean
it
might
be
a
way
to
drive
the
discussion
constructively.
I'm,
not
I'm,
not
sure
how
you
would
drive
up
to
an
a
workable
outcome.
The
way
I've
approached
that
in
the
past
and
simply
been
you
have
many
stakeholders
at
the
decision-making
level
with
different
values
and
those
values
get
to
have
a
discussion,
and
you
come
up
with
an
outcome
from
that
and
it's
it's
sort
of
it.
C
E
Yeah
thanks
so
I
kind
of
feel
like
it
might
make
more
sense
to
ask
the
reverse
question
of
like
do.
We
have
enough
engagement
from
people
who
are
not
inside
our
bubble
and
who
like
buy
it
like
for
actual
users
of
note
and
what
they
want
and
think
about
this.
It's
like
I,
don't
really
having
I.
Don't
think
I
have
a
good
feeling
for
that.
Regarding
this
issue,.
A
D
D
I
was
just
gonna
like
a
rod
as
a
caveat
to
the
way
that
you
framed
it.
I
just
want
to
say,
like
I
think
like
for
myself,
for
example,
I
still
value
the
idea
of
small
core
I.
Think
I
just
have
a
slightly
different
idea
of
what
that
small
course
should
be
and
what
it
should
accomplish
and
I.
Think
broadly,
is
a
really
good.
D
D
But
but
I
do
think
you
know
discussions
around
some
of
those
core
ideologies
and
where
we
draw
those
lines
and
how
we
make
those
decisions
would
be
really
at
least
to
me
useful,
because
I
don't
think
it
does
anyone
a
service
to
have
it
be
something
that
happens
on
a
per
pull
request
basis
based
on
whoever
signed
in
that
day
and
very
much
to
what
you
were
saying
rod.
No
one
can
keep
track
of
everything.
So
when
these
things
start
to
feel
arbitrary,
that
isn't
really
fair
to
the
collaborators
or
the
project.
I.
C
Like
I,
like
that,
but
I
think
about
I
like
about
that,
is
that
what
you're
saying
is
that
there
is
a
there
are
different
ways
to
even
think
about
small
chords.
It's
not
enough
to
just
say
I
believe
in
small
core,
and
so
maybe
what
we
need
is
some
kind
of
forum
to
have
that
discussion,
or
at
least
have
people
present
what
their
ideas
of
small
core
are
not
necessarily
to
reach
some
kind
of
resolution
where
we
agree.
This
is
the
outcome,
but
to
just
raise
those
ideas
because
that
it
sounds
like
that's
what
we're.
C
C
There
are
those
of
us
that
care
about
small
core,
though
even
within
that
is
a
splintering
of
different
ideas
about
that
and
to
you
to
your
point,
it
sounds
like
your
idea
of
small
core,
probably
leans
more
towards
serving
the
primary
use
case
of
node
applications
which
is
serving
the
web.
So
it's
more
core
should
being
able
to
focus
on
that.
I
think
that's
all
the
general
perspective
and
it
would
be
worth
having
that
enunciated
in
some
way
that
that
others
could
refer
to.
C
And
so,
when
we
talk
about
small
core,
it
actually
means
these
different
things
to
different
people.
So
some
kind
of
way
they
at
least
have
that
discussion
and
raise
those
ideas
would
be
great
because,
like
I'd
like
to
talk
about
small
core
in
the
sense
of
UNIX
philosophy
and
that's
another
way
to
approach
it,
but
that's
kind
of
different
to
you
so
I
don't
know
what
that
is,
but.
D
And
there
may
be
other
ways
of
approaching
this
where
it
doesn't
have
to
be
in
court.
I
mean
one
of
the
things
that
I
personally
am
really
passionate
about.
Right
now
is
trying
to
see
how
we
can
better
engage
in
different
standards,
efforts
around
the
language
and
us
having
implementations
at
least
that
we're
responsible
for
allows
us
to
really
engage,
but
if
we
don't
have
stake
in
the
game
we
don't
have
like
if
we're
not
actually
implementing
these
things.
It's
really
hard
for
us
to
engage,
inform
and
influence
these
decisions,
which
do
eventually
affect
us.
A
Right
so
maybe
I'd
suggest
we
take
that
as
something
as
a
to
do.
Maybe
next
collaborator
summit
or
something
we
should
try
and
see.
If
that's
a
good
topic,
unless
somebody
pushes
it
earlier,
I
did
want
to
loop
back
to
Anna's
point,
though,
because
she
was
basically
saying
like
on
the
front
of
namespaces:
do
we
need
more
external
input
or
have
we
had
enough
external
input
to
really
be
able
to
make
a
good
decision
here?
A
A
E
A
A
A
A
Basically,
it
the
PR
takes
language
from
the
one
of
our
other
governance
documents.
That
basically
says
you
know.
If
you
disclose
things
from
the
moderation
team
discussion,
there
will
be
confident.
You
know
basically
says
the
details
of
the
issue
discussed
within
are
expected
to
remain
confidential
and
are
not
to
be
discussed
in
a
public
forum
or
social
media
service.
Any
collaborate
found
to
be
violating
the
privacy
of
it
by
repeatedly
sharing
or
discussing
the
details
and
discussions,
public
forums
or
social
medias
risk
being
permanently
removed
from
the
no
Jess
getup
organization.
A
So
it's
basically
extending
the
expectations
of
keeping
things
confidential
from
the
moderation
repo
to
the
node.js
collaborators
team,
discussion
board
and
the
question
that
I
think
I
forget
who
I
see
who
exactly
added
it
to
the
to
the
agenda,
but
I
think
you
know
the
goal
was
to
get
more
of
the
TCS
input
on
like
do.
We
want
something
like
this
or
do
we
think
that
that's
not
reasonable.
D
A
D
Yeah,
you
may
be
right
about
the
org
and
so
I.
Think
specifically
and
like
this
happened
in
particular
case
was
where
someone
who
is
on
another
working
group
was
nominated
as
collaborator
and
that
conversation
was
public
for
them
to
see
and
there
at
was
potentially
notifying
them
because
it
was
made
public
by
default.
So
it
wasn't
explicitly
made
private
and
it
pained
other
people
in
New,
York.
A
Okay,
well,
the
I
guess
at
this
point
you
know
the
the
final
discussion
is
that
we
should
have
a
policy,
but
it
doesn't
sound
like
Benjamin
was
necessarily
gonna
push
it,
but
hopefully
they
were
looking
for.
Somebody
feel
strongly
enough
about
it
or
one
of
us.
You
know
the
TCR,
the
calm
calm,
to
feel
strongly
enough
about
it
to
either
accept
this
one
or
propose
something
else.
D
To
be
to
be
honest,
I
almost
think
that
the
policy
that
we
need
more
of
is
around
like
what
topics
are
appropriate
to
use
the
collaborator
board
for,
because
I
think
99%
of
the
time
we
are
not
wanting
to
have
private
conversations,
rod.
I
know
you
have
some
thoughts
and
feelings
around
that
from
conversations
in
the
past,
when
I
had
talked
about
making
a
private
collaborators
repo
specifically
for
this
purpose-
and
we
had
you
know
kind
of
aired
on-
we
don't
want
to
be
having
private
conversations
as
much
as
possible.
Oh.
C
A
I
SPECT,
it
may
just
end
up
being
closed.
If,
if
you
know
it
seemed
to
me
like
it
was
a
last
ditch
anybody
interested
in
actually
pushing
it
one
way
or
the
other,
and
if
not,
you
may
not
go
anywhere,
but
we'll
see
we'll
see.
Maybe
that'll
trigger
a
different
discussion.
Anything
more
on
that
topic
before
we
close
it
for
today.
C
C
C
Yet
because
it's
low
severity,
I
I,
believe
the
reason
it's
low
still
of
severity
is
because
it's
it
requires
a
malicious
server,
not
a
malicious
client,
and
so
it's
it's
less
of
a
case
of
being
able
to
take
down
major
servers.
It's
just
a
matter
of
denial
of
service
of
a
client.
However,
I
think
that
client
SSL
is
a
pretty
heavy
use
case
of
node,
and
maybe
we
want
to
consider
floating
this
patch
until
the
next
open
SSL
was
released.
I
I'm
not.
You
know,
I'm
I
could
drop
this.