►
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
A
Sounds
good?
Okay,
if
we
don't
have
any
other
announcements
and
let's
moved
on
to
the
issues
which
were
tagged
for
the
agenda.
The
first
three
I
guess
are
the
three
quick
issues.
There
were
some
discussions
in
the
the
issue
itself,
so
we
should
probably
talk
a
bit
about
this
I'm.
Just
looking
to
see.
I
don't
think
James
is
on,
though
right,
but
we
could.
We
could
discuss
there
when
some
concerns
discussed
about
the
size
of
the
patches
fulfilment
having
to
float
those
four.
B
D
A
B
F
Is
that
the
quick
implementation
involves
floating
a
patch
a
fairly
large
patch
on
OpenSSL,
and
that,
if
we
want
to
land
this
in
node,
14
were
more
or
less
committing
to
having
a
heavily
patched
open
ssl,
which
creates
a
number
of
different
complexities?
One
being
with
people
who
dynamically
link,
which
include
downstream
distributors,
which
was
debian.
H
F
It
also
creates
complications
in
the
case
of
security
vulnerabilities
if
they
involve
code
that
the
patches
touch.
So
this
isn't
yeah.
Perhaps
we
can't
talk
about
it
extensively
without
James
here,
but
I
am
genuinely
concerned
about
the
timeline
of
landing
this,
even
if
it's
arguably
semver
minor,
if
we
want
to
put
it
into
14
with
the
with
the
release
coming
out
soon.
Well,.
D
A
F
Yeah,
that
might
be
the
context
in
that
I
think
was
timely
to
discuss
and
I.
Don't
want,
like
I
want
James
to
have
the
opportunity
to
be
able
to
speak
about
it.
So
maybe
we
can
all
kind
of
reach
consensus
or
be
okay
with
maybe
next
week,
being
kind
of
like
a
cut-off
for
having
that
discussion
for
14.0.
If
James
has
strong
reasons
that
it
should
be
in
there,
but
I
just
wanted
to
raise
that
like.
That
is
the
one
thing
that
I
think
is
time-sensitive.
F
G
Needs
to
be
promoted,
X
I,
don't
think
it's
ready
for
14-0
I'm
I'm,
pretty
the
I
think
it's
worth
the
plus
side
of
the
patch
is
the
patch
is
not
deeply
intrusive.
It's
very
much
like
a
little
word
on
the
side
of
OpenSSL.
It
kind
of
floats
there.
So
it's
not
it's
not
a
very
unstable
patch,
but
it
is
a
sizable
patch
and
it's
not
only
that
I
believe
it
for
luck.
I
think
pouring
SSL
is
complete
unity
to
modify
get
our
very
eyes,
and
the
patch
is
trying
to
track
that.
G
G
C
Am
to
some
extent
I
am
so
the
only
thing
that
concerns
me.
It's
the
OpenSSL
changes
I
would
say
that
the
rest
is
pretty.
I
would
not
be
I'm
happy
to
LG
TM.
The
rest
I've
been
following
up
what
James
was
doing
on
the
JavaScript
side
and
so
on?
So
I
am
you
know
not
that
any
of
that
is
going
to
be
enabled
and
go
to
to
users
and
it
I'm
soon
it's
going
to
stay
as
a
compile-time
flag
right
now,
which
is
kind
of
needed
to
get
a
little
bit
more.
You
know.
C
Officially
tones
is
and
be
able
to
build
somehow
and
get
it
in
front
of
people
to
check
what
to
get
feedback.
So
the
only
real
hard
part
is
what
happens
if
it
breaks,
because
you
know
some
open,
SSL
incompatibility
and
other
things.
So
if
we
want
it,
I
did
I
would
I'm
not
even
convinced
that
we
should
even
announce
it
as
a
feature
that
blended
in
14,
even
if
it
lands
like
it's
to
some
extent.
It's
a
compile
time
flag
like
it's
not.
H
C
F
C
F
This
evening,
specifically
for
the
OpenSSL
change
yeah,
that's
that
may
like
alleviate
a
would
at
least
alleviate
my
concerns
about
us
floating
the
patch,
and
it
would
also
mean
that,
like
if
we
needed
to
do
anything
and
open
SSL,
there
would
be
no
conflicts
in
the
openness.
It's
all
part
of
our
tree.
Yeah
I
break
like
the
part
of
the
build
pipeline
that
floats
that
patch.
But
then
we
can
fix
that
in
a
future
release.
Yeah
I
example.
C
C
So
from
from
my
point
of
view
that
that's
fine
like
as
doesn't
again,
if
we
don't
need
to
ship
it
in
14,
you
can
ship
later
the
more.
The
quick
question
is
landing
it
in
the
first
place
so
and
once
it
lands.
If
it's
if
it
gets
into
a
release,
good
is
wise.
It
can
be
built
from
master
to
some
extent,
but
it
needs
to
be
a
the
development
of
that
needs.
To
start
happening
on
tree
otherwise
is
is
going,
is
not
going
anywhere.
So
that's
at
least
my
my
point
of
view.
I.
A
Liked
the
idea
of
having
the
patch
be
separate,
because
the
other
thing
I
thought
we'd
want
to
have
is
that
agreement
that
miles
outlined
is
like.
If
we're,
if
we're
doing
a
release.
This
is
not
a
blocker,
for
you
know,
for
release,
and
and
even
for
like
somebody
doing
an
open,
SSL
update,
they
shouldn't
necessarily
have
to
struggle
with
rebasing
that
patch.
A
It's
like
just
apply
the
open,
SSL
update
and
the
people
who
are
looking
after
quick,
we'll
fix
that
patch
up
later
on
when
they
test
with
that
compile
like
it
should
it
should
only
it
shouldn't,
make
any
difference.
If
you
don't
have
that
compile
file,
and
so
you
shouldn't
even
notice
it
when
you're
doing
that
open
SSL
update
so.
G
Speaking
of
someone
who
does
updates
I
having
a
dynamically
applied
patch
on
our
search
tree,
it
seems
I,
get
more
complexities
and
it's
worth
having.
There
is
no
other
part
of
our
build
process
as
that
type
of
thing,
so
cherry
picking
a
patch
in
when
you're
doing
the
updates
is
as
close
to
criminal
as
you
can
get
now.
F
Like
to
push
back
on
that
soon,
because
if
the
patch
is
touching
any
parts
of
OpenSSL
that
aren't
related
just
to
that
patch,
then
that
means
we're
shipping
non-standard,
open
ssl
in
node,
with
parts
that
aren't
necessarily
tested,
aren't
necessarily
going
through
the
security
vetting
process.
I'm,
not
saying
that
it's
not
okay,
but
I'm,
slightly
uncomfortable
in
the
idea
that,
like
to
support
this
feature,
we
would
be
shipping
a
different
version
of
open
SSL
than
anyone
else
dynamically
linking
would
be
using
and
I
know.
We
do
generally
float
patches.
F
So
it's
not
like
it's
totally
out
of
line
from
how
we've
done
things,
but,
but
for
this,
for
something
that
wouldn't
even
be
on
by
default.
I
am
uncomfortable
with
it
and
I
understand
that
that
having
something
in
the
build
pipeline
would
be
non-trivial
from
like
an
implementation
standpoint,
but
I
would
even
be
willing
to
spend
my
time
some
time
myself
to
see
if
we
can
get
it
in
there.
If
we
assume
that
machines
have
get
installed
as
like
a
prerequisite,
it
is
kind
of
just
shelling
out
to
a
single
get
command
to
do
this.
F
A
G
Describing
it
as
a
modification
of
OpenSSL
is
technically
true,
I
mean
it's
changing
the
source
code,
but
people
should
be
really
clear
on
the
change
that
it's
making
to
TLS.
It's
essentially
sticking
callback
hooks
in
a
particular
points
in
this
in
state
machine
and
if
the
callbacks
are
there
open
a
file
called
what
consents
a
here's,
some
internal
state,
you
can
look
at
it,
don't
change
it.
G
So
there's
two
places
during
the
TLS
exchange
or
better
I
understand
it,
but
that
that
happens
so
it
just
it
tells
the
user.
The
quicks
implementation,
this
state
transition
has
occurred
in
the
protocol.
Take
a
look
at
this
internal
stuff,
so
it's
it's
not
if
the
hooks
aren't
present
I
mean
is
the
code
that
still
there
on
the
path.
Yes,
but
the
code
on
the
path
is
a.
Is
that
hooks?
Oh,
it's
not,
okay!
G
Keep
on
going
so
they
in
terms
of
safety,
it's
about
as
safe
the
patches
you
can
from
from
that
point
of
view
and
the
and
the
other
issue
about
whether
or
not
like
what
what
the
effect
is
on
our
downstream
users
of
having
a
feature
and
no
that's
that's
not
possible
on
RedHat
on
debian
on
any
of
the
linux
distros
because
they
use
upstream
open
ssl.
That
is
a
that
is
a
serious
concern.
It
doesn't
really
have
anything
do
with
floating
this
patch.
It's
really
a
question.
G
J
I
I
want
to
say
missing
something
about
what
did
the
actual
problem
that
we're
trying
to
solve
here.
I.
Think
that
if
I
got
everything
right,
then
we
won't
yet
quick
in
production
before
the
open,
SSL
purchased
went
upstream,
and
we
update
to
that
openness
salvation.
So
is
this
whole
problem
that
we're
trying
to
solve
now
related
to
testing
the
quick
implementation
in
node.js
before
the
shackles,
so
we
can
edit
in
production
later
makuhita
or
worse.
The
latest
problem
that
were
solving
right
now
with
this
I.
C
C
I
C
D
C
I
I
A
I
think
I
think
if
I
understand
the
suggestion
is
there
could
be
a
separate,
open,
OpenSSL
repo,
with
the
changes
which
you
could
you
know,
compile
and
build
and
then
have
that
and
then,
if
you
built
node
to
dynamically
link
against
that
it
could
include
the
changes
in
core,
and
that
would
be
a
way
to
get
just
sort
of
decouple
the
two
of
those
without
bringing
the
OpenSSL
changes
into
core.
Yes,.
H
A
Guess
summarize,
as
there's
concern
over
landing
the
OpenSSL
component
due
to
the
potential
impact
to
people
who
don't
you
know,
need
that
there
were
suggestions
that
potentially
it
could
be
added
as
a
separate
patch.
So
like
not
floated
but
a
separate
patch
that
then
you
know
the
build.
When
you
turned
on
that
build
option,
it
would
apply
that
patch,
on
top
on
a
top
of
openness,
sell
separately,
chakra
has
also
remained
of.
E
Integrated,
let
me
summarise
we're
right
now
the
way
that
it
builds
right
now,
if
you
do
not
use
the
experimental
click
option,
the
none
of
the
quick
changes
are
built
into
the
open,
SSL
version
at
all.
There
is
a
configure
flag
that
we
set
on
the
by
default.
That
says,
you
know
basically
no
quick
on
the
OpenSSL
side,
so
none
of
those
changes
are
compiled
in
unless
the
experimental
click
option
is
turned
on
so
by
default,
release
builds
would
not
have
the
OpenSSL
changes.
E
A
F
So
I
mean
so
James
to
follow
up
one
of
the
things
that
I
had
suggested
and
it
seems
like
it's
kind
of
what's
happening,
but
just
in
a
slightly
different
way,
as
I'd
suggested
that
perhaps
we
dynamically
applied
the
patch
when
we
run
configure
it
sounds
essentially
you've
done
something
similar,
but
just
that
requires
less
mechanics.
Yes,.
E
You
know
I
just
went
through
the
process
yesterday
because
of
the
open
SSL
one
one,
one
F
change.
There
were
no
changes
to
the
quick
patch
required
whatsoever.
All
I
all
I
basically
had
to
do
was
it
was
cherry-pick
the
patch
and
rerun
the
open,
SSL
config
and
it
worked
yeah.
You
know
there
was.
There
was
no
change
with
the
one-one-one
II
because,
because
of
the
include
path,
changes
that
they'd
open
Excel
made
there
were
there
were
some
changes,
but
it
ended
up
being
maybe
about
20
minutes
with
the
work.
E
F
H
Sorry
for
the
interruption,
sorry
to
disturb
Michael,
just
a
quick
question
on
the
Diagnostics
front,
we
have
a
conflicting
meeting
at
the
moment,
so
people
is
asking
whether
the
the
same
account
is
shared
between
all
the
meetings
in
the
node.js
foundation.
Or
is
there
any
alternative
account
which
he
can
start.
A
H
A
F
B
F
Quickly
on
the
OpenSSL
thing,
if,
if
James's
statement
regarding
like
the
bite,
accuracy
of
open
us
so
and
essentially
that
at
compile
time
with
the
way
the
flag
is
set
up,
that
open,
SSL
itself
will
be
like
bike
to
bite
comparable
and
the
changes
that
are
quick,
specific
are
all
kind
of
compiled
out
at
compile
time.
I
am
NOT
concerned
about
the
approach
with
open
SSL,
especially
if
everyone's
okay
with
us
essentially
dropping
that
patch
in
openness
cell
updates.
If
it's
not
working
yeah,
it
seems
to
accomplish
the
same
goal.
That
I
was
outlining.
F
It's
just
a
different
solution
that
I
had
initially
suggested
into
Stan's
point.
He
said
in
the
chat
minimizing
the
amount
of
hacking
that
we
need
to
do
to
our
build
/
configure
system,
you
know,
is
a
reasonable
goal,
and
so
this
seems
like
a
decent
compromise
between
what
I
was
asking
for
and
the
eventual
goal.
A
A
E
E
You
know
and
if
anything
looks
off,
that
it's
not
bite
for
bite
exact
without
the
guard
right.
The
card
in
place
then
point
that
out
and
I'll
get
that
fixed
right
and
I
do
understand
like
like
the
third
PR.
It's
large
there's
a
lot
there
it's
hard
to
review.
We,
you
know,
extend
the
offer
that
I've
made
before
I'm
happy
to
jump
on
in
phone
for
an
hour.
Anyone
to
go
through
it
in
detail
to
give
folks
the
kind
of
the
the
lay
of
the
land
on
it
know
where
to
start
the
review
and
then.
J
A
I
A
B
A
A
I
One
wrote
that
the
exact
order
of
the
transfers
can
be
adjusted
to
avoid
conflicts.
Also
me
and
material
mentioned
may
be
different
order,
but
it's
just
one
is
the
reverse
of
that
there.
So
any
of
those
two
should
work.
Okay,
yeah,
like
mm-hmm
like
I'm
supposed
to
put
it
on
whoever
makes
leading
his
calendar.
So
that's.
A
A
No
future
directions:
I,
don't
think
I've
seen
too
much
more
discussion
there.
You
know
I,
there's
an
agenda
but
I
think
really.
The
logistics
is
the
key
things
haven't
seen
any
more
discussion.
So
I,
don't
know
that
there's
anything
for
us
to
talk
about
here.
Unless
anybody
has
some
thoughts
that
they
want
to
bring
up
and.
C
I
was
in
the
summit
meeting
collaborators
summit
meeting
for
yesterday,
and
there
is
like
it's
really
related
to
this.
To
some
extent,
and
not
related
to
it
seems
the
most.
The
organization
of
the
summit
is
assuming
it
would
be
a
remote
event
at
this
stage,
and
so
we
are
really
exploring
the
remote
the
possibility
of
the
r-mo
of
running
it
remotely
and
just
so
that
you
are
aware.
C
So
that
is
the
current
and
we
are
asked
as
nodejs
how
much
slots
Owen
slots
we
would
like
and
how
we
would
like
them
to
be
to
some
extent,
so
essentially
in
terms
of
time
zone
problems
in
terms
of
scheduling
in
terms
essentially
going
through
all
the
logistics
problems
that
you
we
mentioned,
the
Radian.
We
cover
the
REA
in
your
in
your
discussion
right.
C
Yeah,
essentially
I
just
wanted
to
well.
We
will
need
to
do
some
session
there.
So
yeah
we
are
discussing
having
one
day
for
projects
to
start
with.
I
have
to
have
a
first
day
of
a
pre-conference
a
day
to
some
extent
remote
where
we
can
do
some
talks
about
each
one,
the
project
present
themselves
and
for
like
new
contributors,
type
of
thing,
yeah.
A
A
C
A
J
C
That's
it
because
it's
so
the
idea
is
they.
The
message
from
the
conference
is
that
if
they
ran
the
conference
is
run
virtually
it
will
be
run
on
osteen
like
timezone,
but
we
can.
That
collaborations
can
actually
shift
to
whatever
time
zone
we
wanted
to
shift
to
some
extent.
So
all
of
that
is
Apple
is
up
in
the
air
right.
A
A
No,
it's
it's
good
to
know
cuz.
If
there's
something
that
comes
out
of
that,
like
some
great
idea
or
some,
maybe
we
just
need
to
try
something.
You
know
if
there's
the
best
we
can
do,
or
maybe
we
just
delay
this
until
we
you
know.
Maybe
we
say
that
it's
better
to
do
this
session,
3
months,
4
months
from
now
or
whatever
time
it
makes
sense
to
be
able
to
get
together.