►
Description
A
B
B
That
means
that
they've
gone
through
the
silent
period,
the
CPC
has
reviewed
their
application
and
there's
no
glaring
issues
and
they're
gonna
work
through
our
onboarding
checklist.
It's
pretty
exciting
I
think
it's
you
know
like
I,
obviously
have
a
bias
as
a
Google
employee,
but
I
think
that
it
is
a
great
move
for
the
amp
project.
I
think
will
help
us
it'll
bring
more
members
and
you
know,
get
more
coverage
of
the
foundation
as
a
whole
and
help
us
grow.
I.
A
Guess
it's
another
large
project
which
it
should
it
should
bring
more
people
participating
across
the
board.
I
guess
the
other
thing
to
mention
if
I'm
not
sure
it
was
called
out
specifically
in
past
meetings,
but
nvm
was
also
in
the
same
category.
So
just
for
awareness,
people
weren't
already
aware
and.
B
C
B
C
A
I
guess,
while
we
add
we
wait
to
see
if
he
manages
to
connect
back
up,
we,
you
know
13
dot.
X
is
slated
to
go
out.
I
forget
the
exact
date
off
the
top
of
my
head,
but
this
month
fairly
soon
Bethany's
been
cutting
release
candidates
and
it
would
be
very
helpful
for
people
to
be
testing
with
those
release
candidates
and
giving
us
feedback
in
advance
of
the
formal
release
of
that
new
version.
Never
expected.
A
Tuesday,
ok
and
go.
F
A
G
One
quick
one,
a
quick
one
for
me:
there
is
the
collaborator
summit
is
happening
and
in
at
non-interactive,
so
you
should.
You
should
send
your
sessions
so
that
you
can,
you
know,
come
and
speak
and
collaborate
at
the
summit
and
Duke
in
your
flights
and
so
on
using
the
travel
fund.
Just
doesn't
that.
F
A
A
G
A
Think
the
you
know,
as
Matteo
said:
that's
where
lots
of
the
activity
is
for
getting
applications,
which
is
great.
Some
of
the
pin
outs,
which
is
good
other
work,
is
really
around
documenting
and
clarifying
that
processes.
The
first
people
come
through.
We
have
some
PRS
to
help.
Add
more
detail
to
you
know
how
we
go
through
the
process,
how
we
you
know
in
the
silent
period.
How
does
that
work?
What
kind
of
checklist
should
we?
Who
should
be?
We
following
there
other
things
which
are
we've
already?
A
You
know
how
we'll
handle
internally
I
have
to
double-check.
You
know
with
that.
That's
gonna
be
landed
soon
and
then.
Finally,
some
updates,
as
we
were
talking
about
to
the
project
progression.
Otherwise
there
is
some
discussion
on
infrastructure
for
the
open,
J's
foundation.
So
if
you
have
an
interest
on
that
level,
there's
there's
a
certainly
opportunity
get
involved,
as
well
as
there's
work
on
standards.
So
the
the
standards
group
is
meeting
regularly
so
via,
and
you
have
an
interest
there.
You
can
get
involved
and
I
guess.
A
Finally,
just
the
the
reminder
that
you
know
that
everybody
is
welcome
to
join
the
CPC.
If
you
have
an
interest
in
that,
you
know,
we
definitely
invite
you
to
come
and
participate
any
regular.
Any
member
of
the
projects,
including
all
the
members
of
the
open
J's
the
node.js
project,
are
free
to
no
self
nominate
as
a
regular
member
and
get
fully
involved.
I.
D
A
H
Yeah
we
we
used
to
accept
vulnerability
reports
and
manage
them
in
a
private
github
repo,
so
we
needed
to
get
CVS
for
them
and
we
needed
to
ask
ourselves
now
we're
using
knocker
one.
We
don't
need
to
manage
CVS
or
ask
for
them
anymore.
So
my
knowledge,
we
have
no
purpose
to
our
CV
process.
It's
just
something
that
somebody's
gonna
have
to
report
on
every
year
and
get
new
ones
and
get
back
the
old
ones,
so
complete
overhead,
but
James
you-you-you
spoke
up
for
them,
so
I
mean
I,
don't
know!
H
F
Really
it
just
comes
down
to
just
when
we
need
to
use
it
right
being
able
to
do
it
directly
without
having
to
rely
on
but
their
party.
Actually,
she
does
and
then
the
intent
was
also
to
be
able
to
eat
our
own
TV
TVs
on
behalf
of
the
ecosystem,
so
the
work
that
the
security
worker
group
is
doing-
I
just
don't
know
if
they've
actually
made
use
of
it.
F
Okay,
right
there
approach
doing,
it
seems
good.
We
also
have
the
option
of
using
github
as
a
CV
in
the
internet
right
they
are.
You
know
offering
that
so
there's
I'm,
not
gonna
block
it
I,
just
I,
would
prefer
not
to
have
that
reliance
on
a
third
party
to
these
following
processes
that
we
don't
necessarily
that
aren't
necessarily
open
to
us
all.
H
So
I
don't
I,
don't
mind,
I
mean
we
can
leave
it
there
until
it's.
You
know
until
maybe
until
it's
been
completely
computers
for
a
year
and
then
maybe
reconsider
right,
I
I
understand
the
kind
of
in
general.
Like
do.
We
really
want
to
rely
on
a
commercial
entity,
but
I
mean
if
github
kicks
us
off
to,
but
when
we're
lost
some
blocks
so
yeah.
A
I
guess,
but
when
you
say
unused
for
a
year,
I
mean
I,
think
it's
either
where
the
CNA
and
we
issue
CDs
or
we
ask
hacker
one
to
do
that.
I,
don't
I'm,
not
sure
we
can,
like
I,
don't
get
the
unused
part,
because
if
we
have
a
we
have,
if
we
have
a
CV,
we
need
to
do.
I
am
I,
am
I
thinking
it
wrong.
Is
it
can
we
use
hacker
one
and
our
own
assignment
I.
B
Was
actually
just
something
just
like
that,
Michael
I,
don't
know
if
this
would
be
a
conflict,
it
should
be.
But
saying
like
what
could
be.
A
good
thing
to
do
is
like
go
through
the
whole
process
of
doing
a
CDE
via
hacker
one
go
through
the
whole
process
of
doing
a
CD
via
github
and
just
kind
of
comparison,
comparing
the
experiences,
my
guess
as
being
our
own
CNA
has
more
upfront
effort,
but
maybe
a
lower
cost
throughout.
B
But
if
github
or
hacker
one
have,
you
know
like
a
really
great
user
experience
from
end
to
end,
and
we
don't
need
to
like
you
know,
follow
up
on
things.
We
just
need
to
press
a
button.
Maybe
that
is
preferable,
but
I
think
that,
like
if
we
had
like,
have
you
gone
through
the
hack
one
CDE
process,
it
all.
H
F
A
H
A
H
I
don't
know,
maybe
we
should
loop
it
around.
I
mean
there
hasn't
been
a
security
release
for
a
while
I
I.
Think
if
we
do
another
security
release
again
and
these
things
are
not
predictable,
we
don't
know
any
vulnerabilities.
Who
knows
when
we'll
have
them
again
then,
and
we
go
through
that
release
and
we
go
get
all
the
CVS
from
the
hacker
one.
H
A
The
thing
that
the
thing
that
struck
me,
my
last
comment
would
be
I
think
what
was
missing
from
the
proposal
of
dropping
it
was
enough,
like
I,
still
think
we
need
something
that
says:
here's
how
we
manage
TV
ease,
it
may
be
updated
to
say
we
manage
them
through
hacker
1.
Here's
how
you
request
one:
here's,
how
you
know,
here's,
how
the
turnaround
time
you'd
expect
well.
H
Whatever
documentation
we
have
for
interacting
with
doctor
one
that
should
be
there,
okay,
you
know
it's
throw
I
think
from
the
feeling.
I
just
withdraw
it.
It's
one
for
Bosworth
right
now,
we'll
we'll
do
another
security
release,
and
after
we've
done,
it
will
evaluate
our
see,
be
precise.
A
little.
I
F
I
think
that
approach
works,
yeah
and,
like
I,
said
they're
coming
I'm,
just
I'm,
not
gonna
block
it
I
just
I
do
have
that
reluctance
I'm.
What
if
we
go
to
the
process-
and
it
seems
like
you,
know,
hey,
you
know
this
is
easier,
it's
better!
That's
fine,
but
it
you
know,
but
let's
at
least
make
sure
we
have
a
backup
option
right
so
for
if
we're
going
to
rely
on
the
180,
let's
have
a
backup
choice,
just
in
case
that
you
know
doesn't
work
that
long
man.
A
D
Jeremih
fees
here,
probably
is
a
better
grip
on
it,
and
James
Anna
Mateo
are
all
in
favor.
This
is
are
in
favor
of
reverting
and
Anatole
Jeremiah
and
Michael
also
are
as
far
as
I
can
tell
opposed,
and
that's
kind
of
the
crux
of
you
know:
I
think
I
haven't
checked
this
morning
to
see
if
other
people
have
weighed
in
which
might
have
might
tip
the
balance.
D
There's
a
bunch
of
people
who
use
the
emoji
to
indicate
that
they
hadn't
yet
arrived
a
decision,
and
one
to
have
this
wanted
to
have
this
conversation
I'm
personally,
like
abstaining
I,
think
either
way
is
fine.
I
know
which
way
I
slightly
prefer,
but
I
don't
really
care
enough
to
actually
argue
for
it.
But
if
we're
going
to
get
this
reversion
in
213,
you
know
we
have
to
like
make
a
decision
like
today
or
tomorrow.
Probably
so
that's
where
that's
at.
J
I'm
also
happy
to
provide
the
context
for
Maya.
Well,
I,
don't
know
if
it's
opposition
really
I
just
I'm,
not
convinced
that
the
branching
that's
gonna,
result
by
reverting
it.
The
December
major
is
worth
it
and
I
don't
know
if
we
can
regard
it
as
an
on
some
of
her
major
but
okay,
so
in
theory
I'm
and
they
were
ready
for
whatever
it's
worth
but
I,
don't
like
the
idea
of
that.
There's
gonna
be
an
LCS
line
that
still
has
this
behavior.
So
that's
the
that's
my
objection
here.
B
B
B
That
we
could
engage
it.
What
working
group
tried
to
specify
behavior
and
then,
if
we
find
were
you
know
no
longer
compliant
with
the
spec
in
various
versions,
then
we
could
potentially
fix
it
in
LTS
as
a
nonce
Ember
major,
if
we're
doing
it
for
spec
compliance.
Or
would
this
still
be
like
consider
December
major
if
we
were
fixing
it
for
spec
compliance.
F
A
Guess
side
you
know,
is
there
a
easy
set
of
pros
and
cons
to
reverting
versus,
not
reverting
like
our
people,
you
know.
Do
we
expect
that
you
know
people
are
gonna,
start
complaining
when
12
goes
out,
you
know,
or
is
it
that
they're
going
to
get
used
to
it
and
then
complain
when
13
comes
out
and
it's
different.
D
H
F
F
F
D
H
H
H
Set
of
our
major
this
of
it,
we
haven't
yet
broken
any
rules.
I
guess
the
problem
is
more
than
people
are
asking
themselves.
Do
we
really
want
this
behavioral
change,
I,
don't
again,
I,
guess
that
didn't
get
enough
visibility
or
advertising
on
that
landing.
Yeah
nobody's
fault
it
just
you
know
it's
yeah,
that's
the
way
our
processes,
yeah.
F
A
F
F
F
B
D
C
L
Yeah
I
I
missed
the
first
20
minutes
of
meetings,
so
I
missed
most
of
the
discussion.
In
my
opinion,
adding
a
flag
doesn't
sound
that
reasonable.
As
I
said,
it
seems
like
overkill
for
such
a
relatively
simple.
H
Think
the
current
behavior,
like
the
12,
the
current
12
directs
behavior,
is
more
consistent
and
better.
It's
only
slightly
better
I,
don't
know
if
I
would
have
approved
the
original
PRF
I'd
actually
paid
attention,
but
given
that
it's
a
behavior
now
we
can't
get
it
out
of
12x
without
doing
something
that
really
breaks
our
process.
The
flopping
doesn't
seem
like
it's
gonna
help.
Anybody
that
I
I
think
we
should
stick
with
attorney
here
in
12,
dot,
X
and
not
reverted
for
13
dot.
X
just
keep
keep
keep
on
going.
What
we're
doing.
F
F
F
D
E
Can
you
hear
me?
Yes,
okay,
unfortunately,
you
know
I'm
not
able
to
make
up
my
mind.
I
was
hoping
that
I
would
get
a
better
insight
about
the
problem,
but
I
still
need
some
more
time
to
you
know
understand
the
actual
background
and
the
pros
and
cons
of
returning
it
was
promoting
it.
So
if
you
want
a
vote
or
a
opinion
right
now,
I
don't
have
it.
Unfortunately,.
D
D
M
F
M
F
M
F
A
B
B
As
of
12.2,
export
maps
are
no
longer
behind
their
own
flag,
they're
still
flagged
behind
the
equi
script
modules.
Flag,
export
maps.
Allow
you
to
add
a
new
field
to
the
package.json
called
exports
in
which
you
can
specify
the
exports
of
your
module.
This
is
a
way
of
creating
kind
of
a
public,
/
private
interface
for
modules,
so
you
can
specify
the
deep
imports
that
can
be
accessed
by
your
module.
B
If
we
think
about
something
like
lo
and
you're
able
to
do
like
require
low
/fp
I'm,
just
putting
an
example
of
that
into
the
chat
right
now
to
get
low
as
functional
programming
interfaces
right
now
as
it
works,
is
you
can
deep
search
into
a
module?
It
always
starts
at
the
root
of
the
module
and
you
can
kind
of
reach
in
and
grab
any
file
when
you
use
the
export
map,
unless
you
use
syntax
to
specifically
make
folders
available,
only
the
exports
that
are
explicitly
included
in
the
export
map
will
be
available.
B
One
of
the
challenges
to
this
is
being
able
to
test
these
interfaces,
and
so
one
of
the
one
of
the
enhancements
that
we've
been
discussing
in
or
proposing
for
export
maps
and
have
consensus
around
in
the
issue
is
making
the
ability
to
self
reference.
So
you
would,
if
you
were,
writing
lodash,
be
able
to
do
something
like
I'm
just
typing
it
into
the
chat,
require
tilde
/fp,
and
that
would
be
self
referential.
Referring
to
the
exports
in
your
own
map.
The
tilde
character
today
is
not
a
valid
specifier,
so
this
is
a
non-breaking
change.
B
This
is
arguably
semver
minor
export
maps
will
also
have
the
ability
of
setting
a
dot
slash,
which
would
be
the
equivalent
to
Main.
It
would
shadow
the
main
in
a
package,
but
you
would
be
able
to
specify
both
a
main
and
an
export
dot
which
allows
fallbacks
to
older
versions
of
node
that
don't
support
export
maps.
So
this
issue
in
particular,
primarily
has
consensus
right
now.
The
modules
team
is
Pro
landing
it.
The
high-level
question
is
which
sigil
to
use
as
the
specifier
for
self
referencing,
specifically
we're
debating
between
at
or
Kilda.
B
B
So
since
we
do
generally
do
full
paths,
people
were
thinking
that
it
could
be
confusing
that
that
doesn't
refer
to
the
home
directory
of
your
of
your
system,
there's
also
prior
art
of
the
tilde
being
used
to
reference
home
in
in,
like
certain
Babel
and
webpack
plugins,
although
inside
of
those
plugins
tilde
is
generally
meant
to
use
to
refer
to
the
root,
but
it
can
also
be
like
kind
of
meta
program
that
told
it
could
be.
You
know
a
deep
directory
now,
arguably
the
behavior,
that's
in
the
ecosystem
would
be
reproducible
via
export
Maps.
B
That's
doing
import
maps,
which
is
a
way
of
allowing
for
bear
imports
inside
of
the
browser,
and
essentially
we
want
to
make
sure
that
this
behavior
will
be
replicable
to
make
sure
that,
like
we're,
not
creating
large
ecosystem
divergencies,
so
independent
of
which
sidwell
we
pick
today,
the
intent
right
now
is
to
put
it
behind
a
flag,
and
so
we
could
still
change
it
at
any
point
in
the
future.
If
people
are
playing
with
it
and
find
it
to
be
inconsistent
or
confusing
so
I
guess
the
high-level
question
would
be.
B
D
Because,
like
I
was
I
was
thinking
that
since
there's
prior
community
art
for
the
tilde,
that
that
would
be
a
via
paved
the
cowpats
kind
of
thing
a
little
bit.
But
regardless
I
do
think
that,
especially
for
an
experimental,
API,
I
think
I,
don't
think
the
TSC
is
is
the
place
to
make
the
decision.
But
if
the
modules
team
can't
come
to
agreement,
then
sure
let's
make
a
decision,
but
I
prefer
to
Pont.
So.
B
F
Had
people
on
the
for
the
FS
module
who
had
talked
about
the
potential
of
adding
tilde
to
actually
point
to
home
directory
and
I
and
I,
really
just
think
that
it
would
end
up
being
confusing
if
at
some
point
down
the
future,
you
know
in
the
future,
FS
read
tilde,
whatever
ended
up
coming
up
with
something
different
then
required
tilde.
Whatever.
E
I
You
know
doing
work
with
node
now,
so
so
yet
I
can
see
that
contention,
but
but
till
that
doesn't
necessarily
have
such
a
strong
standing
right
and
we
don't.
We
don't
have
an
instance
where
Till
does
being
replaced
by
dollar
home
like
it
is
in
bash
right,
so
I
you
know
and
on
the
other
hand,
tilde
tilde
being
the
home
of
this
particular
module
does
also
make
amount
of
sense
right.
But
now
I'm
not
strong
on
either
one
I'm
just
saying
this
is
this
might
be
an
aspect
we
might
want
to
consider.
You
know
I.
B
Think
that
was
a
Gabriel
to
your
point.
Exactly
the
tilde
being
the
home
of
the
module
was
absolutely
the
reason
why
it
was
landing
on
as
a
symbol.
It
has
prior
symbolic
meaning
to
people
and
would
likely
be
easy
from
an
educational
perspective.
Although
I
also
understand
that
it's
like
it
breaks
expectation
if
you
expect
tilde
slash
thing
to
resolve
to
your
home
directory.
Another
thing
that
had
been
suggested
was
just
literally
using
the
name
of
the
module
itself
as
self-reference,
but
that
was
pushed
back
against
because
it
was
like
a
refactoring
hazard.
B
Anyways
I
think
that
at
this
point
to
Rich's
point
I've,
just
I've
drafted
something.
The
suggestion
from
the
TSE
is
to
Lana's
PDR,
that
if
this
PR
lands
behind
a
flag
allowing
more
time
through
the
sessions
from
the
TSE
is
tool
and
this
PR
behind
a
flag
to
allow
more
time
to
work
with
semantics.
There
were
strong
opinions
regarding
both
existing
signal
suggestions.
B
But
overall
sentiment
was
that
this
is
something
for
the
modules
team
to
work
out
not
for
the
TSC
to
decide
and
if
we
want
to
come
up
with
more
suggestions
and
ask
the
TSE
for
advice
or
to
chime
in
in
the
future.
We
absolutely
can,
but
you
know
it's
something
for
for
the
people
working
on
this
to
kind
of
work
through
and
reach
consensus
on.
Does
that
seem
reasonable
to
folks.
D
A
A
D
A
H
No
huge
apes
on
Python
hey.
It
takes
me
less
time
to
update
the
fast
update
as
NPM
is
landed.
It's
got
a
new
version
of
ode.
No
chip,
we've
got
some
Travis
green
builds,
looks
like
we
can
land
some
stuff.
If
we're
lucky,
we
might
even
be
working
with
Python
3
right
now
that
I've
had
time
to
check
since
NPM
landed.
So
that's
three,
it's
tooling
along
and
let's
go
back
modules.
Okay,.
A
B
Take
it
so
there's
there's
a
couple
different
things
that
are
going
on
here.
This
is
also
tied
closely
to
the
unflagging
of
modules.
So
at
a
high
level,
a
number
of
people
from
the
modules
team
feel
like
we're,
ready
to
unflagged
modules
in
in
note
13.
It
would
remain
experimental.
It
would
remain
flagged
in
12
for
now
we'd
begin
to
gather
ecosystem
feedback
on
the
implementation
in
13.
We
would
back
port
and
keep
the
implementation
in
12
up
to
date
and
then,
essentially
at
the
point
that
we
feel
it
is
rather
stable.
B
We
would
back
port
the
removing
of
the
flag
to
12.
The
hope
would
be
that
this
could
be
in
like
a
three
to
six
month
time
line
now,
one
there
are
individuals
in
the
team
who
do
not
feel
that
we
are
ready
to
unflagged,
yet
specifically
there's
the
case
of
dual
mode
modules,
so
this
is
specifically
being
able
to
publish
a
package
to
NPM
and
being
able
to
require
the
package
and
import
the
package
with
the
package
name
specifier
and
have
it
work
in
both
module
systems.
B
There
is
strong
disagreement
about
whether
or
not
this
is
a
feature
that
should
ever
be
enabled.
Specifically,
it
introduces
a
hazard.
That's
what
this
issue
is
about.
The
divergent
specifier
hazard
issue,
with
the
way
in
which
the
cache
works
in
Commons
is
an
DSM.
If
you
import
the
module
that
ends
up
in
an
ESM
cache,
if
you
require
a
module
that
ends
up
in
a
common
j/s
cache,
if
you
import
a
common
j/s
module,
it
gets
created
in
the
common
jeaious
cash
and
then
reflected
into
the
ESM
cache.
B
B
The
common
Jas
cache,
on
the
other
hand,
has
no
idea
of
what's
going
on
in
the
ESM
cache,
so
the
hazard
that
exists
here
is
that
if
you
have
a
large
graph
and
you
import
a
module
such
as
react
and
you
get
the
ESM
implementation
of
it
and
then
later
somewhere
in
your
glass
graph,
someone
requires
requires,
react
and
gets
the
common
J's
version
of
it.
You're
gonna
have
two
different
instances
of
the
singleton
in
the
graph
and
there'll
be
no
way
for
the
consumer
of
that
second
singleton.
B
To
know
that
they've
gotten
the
second
singleton,
which
then
puts
the
onus
and
module
authors
essentially
to
protect
against
this
now.
This
is
a
hazard
that
we've
already
seen
exist
in
our
ecosystem,
especially
when
packages
are
not
be
due
in
very
large
graphs.
It's
arguably
an
anti-pattern
to
be
relying
on
these
Singleton's
begin
with,
but
we
did
see
in
early
implementations
of
node
prior
to
12,
where
we
have
the
specify
a
resolution.
B
Algorithm
people
could
put
a
main
that
was
just
index
and
have
an
index
mgs
and
have
an
index
J
s
and
and
get
this
dual
mode
behavior
and
we
saw
breakages
in
graph
QL.
We
saw
breakages
in
webpack
and
we
also
saw
breakages
and
create
react
app
of
people
kind
of
getting
bit
by
this
hazard
in
ways
that
were
unexpected,
so
kind
of
to
two
of
the
high
level
bits
that
we
can't
really
seem
to
agree
upon.
B
There
are
there's
individuals
from
the
modules
team
who
object
to
us
unflagging
until
this
behavior
is
fixed.
The
other
question
was
do
folks
on
the
TSC
find
that
this
hazard
is
something
that
node
should
be
protecting
against,
or
is
it
something
that
we
should
allow,
but
document
best
practices
around?
More
specifically,
we
do
have
a
PR
open
right
now
called
conditional
exports
with
to
allow
using
the
export
map
to
create
this
behavior
we're
debating
export
maps
right
now.
B
It
will
likely
land
behind
a
flag,
I'm,
potentially
even
suggesting
that
we
land
versions
with
like
two
different
Flags
one
flag
with
the
hazard
one
flag
without
the
hazard.
So
we
can
actually
get
user
feedback
from
the
ecosystem
on
this
rich
to
your
question,
flagging
would
not
be
taking
it
out
of
experimental,
but
the
the
high
level
concern
that
people
do
have.
Is
that
the
second
that
we
unflagged,
the
behavior
of
the
module
system
is
going
to
mass
adopted,
and
so
the
biggest
concern
with
not
having
the
dual
mode?
B
Is
that
without
dual
mode
there
isn't
a
clear
path
for
module
authors
to
easily
upgrade
from
common
jst
SM
in
a
non
semver
major
way,
well
still
supporting
their
module
consumers,
whereas
you
know
I'm
strongly
of
the
opinion.
It's
switching
the
module
systems
should
member
major
I
don't
see
that
as
a
problem,
I
think
there
are
paths
for
to
module
authors,
it's
not
as
good
of
the
user
experience,
but
I
do
think
that
we
should
be
guarding
against
against
this
hazard.
B
So
the
two
high
level
questions
to
the
TSE
and
also
you
know
if
you
have
any
more
clarifying
questions.
I'm
happy
to
ask
would
be
you
know:
do
people
feel
as
strongly
about
this
hazard
as
I
do
because
if
I'm
the
only
one
on
the
TSC,
then
perhaps
you
know
I
should
re-evaluate,
but
then
the
second
one
would
be.
Does
anyone
have
a
problem
with
us
unflagging
without
this
kind
of
dual
mode
approach
for
people
and
enough
to
yell.
B
M
B
Rich
to
your
question
on
time
frame,
honestly,
you
know
if
TLC
does
not
have
a
problem
with
us
unflagging
before
we've
reached
a
solution
on
on
how
we're
gonna
handle
do
a
little
packages,
or
if
we
will,
we
could
unflagging
soon
as
like
next
Wednesday,
otherwise
we're
probably
looking
at
you
know
at
minimum
another
couple
weeks,
while
we
kind
of
bike
shed
on
something
that
honestly,
you
know
we've.
We
have
been
talking
about
and
disagreeing
upon
for
months
now
when.
B
D
B
B
Guess
like
are
people
going
to
take
the
time
to
get
ramped
up,
or
do
you
just
defer
to
the
team?
One
of
the
things
that
I
did
you
know
kind
of
try
to
persuade
the
team
about
was
hey.
We
are
the
experts
in
this
and
if
we
defer
to
the
TST,
they
might
likely
just
punt
it
back
if
they
don't
have
time
to
ramp
up
or
make
a
worse
make.
B
D
B
D
But
my
inclination
is
to
I
mean
again
like
I'm,
not
you
know
this.
This
is
not
a
deeply
informed
opinion,
but
it
seems,
like
you
know,
resolving
differently.
Yes,
M
versus
common,
that
the
singleton
seems
like
something
that
is
acceptable
to
me,
but
obviously
it's
not
acceptable
to
you
so
I
would
I
would
absolutely
take
you
up
on
the
on
the
one
to
one
session
to
hash
that
out.
I
guess.
A
My
only
thought
was
along
the
same
lines,
except
that
it
was.
It
should
be
consistent
so
like
if
you're
gonna
get
a
different
one.
Sometimes
you
should
always
get
a
different
one.
Yeah
right
like
that.
That
might
be
okay,
because
then
you
don't
have
a
well.
You
know
you
don't
know,
what's
gonna
happen,
but
I
don't
know.
If
that's
a
reasonable
answer
to
just
say
sorry,
every
time
it
probably
didn't
validate
something
about
the
caching
in
the
first
place
right,
but
the
unpredictable
behavior
is
at
least
anyway
against.
B
H
B
B
Guess
one
thing
one
thing
just
to
add:
really
quick
to
this
Sam's
comment
about
fracture.
This
is
completely
separate
from
the
ability
to
import
common
jeaious
modules.
We
support
that
100%
right
now.
It
also
would
not
introduce
the
ability
to
require
ESM
module
would
make
a
single
specifier
load
to
different
modules
and
that's
the
hazard,
and
there
are
solutions
that
can
work
that
are
less
the
develop
developer
experiences
and
is
good
I'll,
try
to
maybe
put
together
a
little
bit
of
a
write-up
that
summarizes
this
as
well.
A
Sounds
good
okay,
so
we
are
at
time
there's
a
couple
more
issues.
Collaborator
summit,
montréal,
2019,
I,
think
Matteo
had
that
on
the
issue
on
the
agenda
for
awareness
and
I
think
we
covered
that
in
the
announcements
I,
don't
think
we
still
have
made
it
Matteo.
Anybody
else
have
any
context
on
that.
One.
H
It's
not
urgent,
it's
completely
stalled
the
there's
an
upgraded
one
with
a
better
license,
but
it's
not
working
or
not
passing
tests.
So
somebody
who
has
the
energy
has
to
figure
that
out.
The
easy
thing
still
remains
well
I
mean
easy
for
my
perspectives.
Just
ask
the
note
foundation
to
bless
our
current
code.
H
A
F
I
think
like
for
me
personally,
I
need
to
look
at
it
more
before
making
that
decision.
I
am
concerned
about
removing
the
flag
prematurely,
because
this
is
something
that,
as
soon
as
we
remove
that
people
will
start
using
it,
whether
experimental
or
not
right,
and
then
after
that,
oh
one,
more
thing,
even
while
it's
still
external,
so
I
think
I
would
rather
be
conservative.
One
okay.
B
A
F
It's
it's
gonna
end
up,
meaning
that
quick
will
only
work
in
the
statically
linked
version
of
open
SSL
that
we
have
the
ship.
It
won't
work
with
like
the
shared
open,
SSL
option,
and
there
is
some
there's
patches.
We'd
have
to
float
until
we're
able
to
move
up
to
a
version
of
openness
l3
that
actually
has
those
api's
landed.
It
works.
There
are
some
concerns
there
and
if
anybody
is
concerned
about
the
approach
problem
to
take
on
there,
please
reach
out
and
can
talk
me
I
guess.
F
F
F
H
Also,
it's
important
it's
it's
I'm,
like,
unlike
all
of
the
open
SSL
releases,
we've
smoothed
in
the
last
years
necessary,
is
explicitly
binary
compatible.
It's
not
ati
compatible
though
they
are
shooting
for
api
compatible,
which
means
that
it
would
be
a
number
of
major
for
us,
so
we
can't
dump
it
into
twelve
decks.
F
It
quick
is
gonna,
be
experimental
for
a
while.
It's
gonna
be
sitting
there.
It's
a
criminal,
it
won't
land
in
in
node
without
the
configure
time
flag.
So
you
actually
have
to
you
know,
turn
on
experiment,
experimental,
quick.
While
you
can
figure
it's
right,
get
it
in
there.
So
it'll
be
like
that,
for
probably
at
least
through
thirteen
I
guess.