►
Description
A
A
If
nobody
else
has
announced
the
one
thing
I
will
add
is
just
a
reminder
to
people
that
the
submissions
for
the
collaborator
summit
and
the
community
corner
at
no
Plus
Jess
interactive
are
open,
so
just
a
reminder
to
submit
any
issues
there
and
we
looking
forward
to
see
you
there.
Moving
on
to
the
next
thing
on
the
agenda,
is
the
CPC
and
board
meeting
updates
in
terms
of
the
board
side
of
things?
A
B
Sorry,
environment,
yeah,
no
fine,
there's
a
lot
of
attention
to
how
the
boarding
process
isn't
going
to
happen
for
new
projects
that
are
coming
in
a
lot
of
questions
that
CPC
is
working
on
and
both
for
new
product
as
well.
It's
all
projects,
so
one
of
the
important
thing
is
that
we
are
asked
to
complete
a
checklist
to
do
with
the
transition.
Change
then
opens
a
yes
foundation.
B
A
I
think
that's
good,
the
you
know,
as
you
said,
the
focus
is
on
working
through
them.
The
applications,
the
process
and
then
onboarding,
including
the
existing
project,
so
I
took
the
minutes.
I
said
this:
you
know
that
you
and
Joe
will
be
leading
that
effort
and
letting
people
know
what
what
needs
to
be
done.
B
A
C
Sure
so
we
all
chatted
about
modules.
Last
week,
specifically,
we
were
talking
about
some
of
the
things
we're
still
trying
to
reach
consensus
on
specifically
dual
specifier
hazard.
We
had
only
about
10
minutes
last
week
and
that
was
kind
of
enough
time
to
you
know,
get
people
curious,
but
not
enough
time
to
really
get
them
up-to-date.
So
between
then,
and
now,
when
the
modules
came
put
together
an
explainer
doc
to
share
with
the
TSC,
giving
kind
of
like
a
high
level.
C
We
have
a
couple
members
of
the
team
on
the
call
right
now,
including
tsum,
nan
TSE
members,
so
there's
myself
from
the
TSE
there's
myself
Matteo
and
Michael's.
Oh
so
90s
member
TSE
members
were
on
the
call
right
now
include
jeffrey
booth
and
young
krebs,
so
I'm
not
sure
if
everyone
from
the
TSE
has
had
time
to
review
that
doc.
A
C
It
you
sent
out
in
an
email
to
the
TSC
list
on
Monday
I
just
dropped
it
into
oh,
no
I
think
I
just
copied
the
actual,
never
mind.
That's
the
meeting
notes
there.
The
the
jock
had
just
went
now
is
the
explainer
doc.
Okay.
So
it
seems
to
me,
then
that
we
are
not
in
a
position
to
really
hold
this
conversation
right
now.
C
I
think
the
next
thing
that
we
can
do,
then,
is
to
kick
this
back
to
the
module
team.
We
have
a
meeting
this
afternoon
at
3:00,
we'll
continue
to
work
on
trying
to
get
towards
consensus
on
what
we're
working
on
I
think
that
at
the
very
least,
the
exercise
of
summarizing
all
of
this
and
trying
to
explain
it
to
y'all.
That's
also
us
work
some
stuff
out.
So
we'll
kick
it
back
to
the
modules
team,
we'll
work
on
our
thing
and
then
you
know
we'll
come
back
to
the
TSC.
C
C
People
aren't
super
engaged,
and
we
have
some
folks
who,
like
showed
up
so
I'd,
prefer
to
not
repeat
that
unless
you
know
people
are
explicitly
like,
we
really
want
to
talk
about
it,
because
if
it
because
I
think
it's
a
very
reasonable
response,
is
a
modules
team
you're
the
experts
on
this,
and
we
trust
you
to
make
a
good
decision
which
is
kind
of
the
impression
I'm
getting
a
little
bit
through
the
silence.
I.
D
C
I
think
the
team,
for
the
most
part
is
moving
forward,
potentially
with
trying
to
do
self
reference,
so
you
would
just
use
the
name
of
the
package
that
you're
in
to
reference
to
itself,
but
I
think
we
got
enough
feedback
to
kind
of
move
forward
on
that.
This
is
more
about
the
divergence
fest
fire
hazard
Jeffrey.
You
have
your
hand
up.
Was
there
something
you
wanted
to
add.
E
F
Okay,
like
if
you
look
at
this
package
that
does
X
and
package
and
the
other
package
does
the
other
behavior
and
like
which
of
these
things
is,
is
like
what
we
want
to
be
correct
because
understanding
it
purely
from,
like,
unfortunately,
understanding
like
how
how
those
details
work
is
like
enormously
complicated
and
like
unreasonably
so,
unless
you're
very
involved,
it's
very
difficult
to
understand
what
what
the
thing
is
and
what
that's
actually
going
to
impact
like
I
know.
This
is
not
really
the
fault
of
the
modules
team,
but
yeah.
C
Yeah
I
also
think
for
what
it's
worth
that
between,
like
the
last
meeting
and
now
and
other
conversations
that
have
happened,
I
think
we're
actually
getting
as
a
team
really
close
to
a
solution
that
finds
a
balance
between
developer
experience,
edge
cases
and
documentation.
So
genuinely
I.
Think
that,
like
if
the
response
that
we're
getting
from
the
TSE
right
now
is,
you
know
not
jumping
at
having
an
opinion
because
of
the
depth
and
like
how
much
onboarding
there
is
to
do
from
getting
to
know.
C
What's
going
on,
I
think
that
we
may
be
able
to
actually
even
reach
some
level
of
consensus
in
the
next
week
within
the
modules
team
anyways.
So
let's
just
get
back
to
the
modules
team.
If
anyone
from
the
TSE
has
questions
or
concerns,
please
you
know
reach
out
open
issues.
Let
me
know
or
let
other
modules
teams
members
know
and
if
we're
still
unable
to
reach
consensus,
we'll
come
back
to
the
TSC
once
again
to
see
if
you
know
anyone's
had
time
to
ramp
up,
let's
seem
reasonable
to
folks.
Yes,.
A
G
Does
I
actually
have
one
one
question
I
mean
if,
if
I
understand
this
do
I
understand
this
correctly?
The
problem
here
is
that
when
you
call
require
for
common
J's
module,
it's
effectively
a
singleton,
the
module
that
you're
getting
so
different,
JavaScript
files
calling
required
get
the
same
singleton,
but
that
with
import
and
require
you
can
actually
get,
did
a
different
underlying
object
with
your
require
and
with
an
import
that,
yes,.
C
So
we
either
need
to
support
the
developer
experience
where
package
authors
can
publish
a
package
that
can
be
both
required
and
imported
with
full
support
for
both
interfaces
or,
alternatively,
we
need
to
have
separate
entry
points
for
common
jsn
dsm.
Now
we
do
support
common
GS
and
the
ESM
loader.
So
if
you
publish
a
common
J's
package,
you
will
be
able
to
require
it
and
import
it.
You
just
won't
be
able
to
do
named
exports,
so
you
won't
be
able
to
do
kind
of
like
D
structuring
or
the
the
named
imports.
C
The
way
that
you
would
with
an
ESN
module
is
not
the
best
from
a
developer
experience,
but
it
kind
of
works,
but
the
flipside
would
be
if
a
package
has
its
main
or
its
export
dot
set.
As
in
SM
entry
point,
there
is
no
way
to
require
it
to
enable
that
we
can
do
it
and
we
have
a
proposal
that
would
be
able
to
do
this.
G
All
right,
I
actually
do
have
an
opinion
about
that.
I
think
the
so
even
with
commonjs.
The
singleton
assumption
is
very
hazardous
and
does
get
broken.
I
mean
it
is.
It
is
true
that
if
you
require
the
same
package,
it
is
some
singleton.
But
what's
not
true
is
that
a
particular
string.
Fubar
will
always
be
the
same
package
fubar
because
you
can
have
nested
modules,
so
I've
definitely
seen
people
get
into
head,
correcting
Rios
where
they
like,
but
it's
always
a
singleton.
C
G
H
Yeah
I
agree
that
that
this
is
not
a
new
problem
in
general
like
yes,
then
it
isn't
the
system
that,
for
example,
graph
QL
or
react
if
you
have
two
copies
of
it
in
your
graph
and
two
different
libraries
are
using
the
two
different
copies
things
break.
The
new
thing
is
that
all
the
ecosystem
practices
around
monitoring,
MP
MLS
and
making
sure
that
you
don't
have
two
copies
and
as
long
as
everyone's
using
the
same
major
version,
everything's
fine.
H
So
you
would
need
to
shift
the
entire
ecosystem
opera.
Here.
All
the
entire
exhibit
of
react
add
ones
to
the
different
module
format.
Now
that
it's
the
same
as
a
complete
major
version
change,
but
it
means
that
it's
not
only
some
avi
is
deprecated.
It's
you
have
to
change
the
way
that
the
entire
code
is
written
and
parted
from
require
two
years
M,
which
is
a
much
bigger
change
even
for
major
version.
G
And
you
don't
necessarily
control
all
uses
of
a
module,
I
mean
so
so.
So
what
is
what
is
the
debate
in
the
module
group
as
I
so
again
trying
to
wrap
my
head
around
us?
It
sounds
like
it
basically
boils
down
to
some
people
want,
but
it's
so
important
and
so
useful
to
be
able
to
require
an
es6
module
that
people
really
want
that
beat
there.
G
C
Specifically
about
allowing
two
entry
points
and
a
package.json
so
that
you
can
specify
different
entry
points
for
the
different
loaders.
That
is
the
feature
that's
being
debated,
the
semantics
of
it.
We
have
some
different
semantics
of
how
to
do
it
and
like
the
primary
reason
to
allow
it
would
be
from
like
an
upgrade
path
and
like
module
author
standpoint,
so
I'm
a
module
author,
I'm
I,
have
an
a
module.
C
Experience
that's
being
unlocked
by
the
conditional
exports
proposal,
so
I'm
still
doing
some
more
research
and
thoughts,
but
with
how
much
I've
seen
the
existing
hazards.
Kind
of
break
people
in
all
sorts
of
unexpected
ways
and
break
expectations,
I
would
be
I
was
very
hesitant
to
introduce
a
new
variant
of
it
and
Tobias
for
your
point.
Yes,
with
two
different
entry
points
in
the
same
package
on
an
import
and
a
require
would
have
two
different
instances.
The
thing
that
gets
particularly
confusing
here,
too,
is
the
way
in
which
the
caches
work.
C
So
if
you
import
a
common
jeaious
module,
it
first
gets
created
into
the
common
J's
cache
and
then
gets
reflected
into
the
ESM
cache.
If
you
import
a
module
that
goes
directly
into
the
ESM
cache,
if
you
require
or
something
it
goes
directly
into
the
common
J's
cache
so
introducing
dynamic
import
into
this
equation
and
modules
that
have
a
mix
of
both
es
m
and
comma
J.
C
S
now
creates
a
race
condition
if
you
require
it
first
and
then
import
it
later,
import
will
actually
check
the
common
J's
cash
before
instantiating
it
and
use
the
one
that's
in
the
common
J's
catcher.
If
that
makes
sense.
Alternatively,
if
you
import
it
first
and
it
creates
the
version
in
the
ESM
cash
and
then
require
it
later,
require
we'll
know
nothing
about
the
ESM
cache
and
actually
go
ahead
and
create
another
instance
of
it
and
you'll
have
the
two
different
instances.
C
That
was
actually
quite
good
in
documenting
best
practices
that
module
authors
could
use
to
help
avoid
this
hazards,
such
as
you
know,
if
you
do
want
to
have
Singleton's,
hiding
things
on
a
global
with
a
symbol
and
then
sharing
that
instance
between
both
the
ESM
and
common
genius
versions
of
it
ways
in
which
there's
also
ways
in
which
having
two
entry
points
could
allow
for
named
exports
for
common
jeaious
modules
by
creating
wrapper
DSM
modules.
So
there's
like
DX
benefits
to
it
as
well
and
I.
Think
I.
C
Think
kind
of
the
two
attitudes
at
a
very
high
level
are
hey.
We
already
have
this
hazard
and
people
already
need
to
work
around
it
and
it's
not
nodes
job
to
be
paternal
to
be
paternal
on
this,
and
we
should
kind
of
allow
the
good
developer,
experience
and
educate
people
on
how
to
avoid
the
hazards
and
the
other
attitude
is.
This
hazard
is
really
bad
and
it's
caused
lots
of
problems.
We
want
less
of
it
not
more,
and
we
should
not
enable
a
variant
of
this
hazards
for
the
purpose
of
a
better
developer
experience.
G
Think
I
think
it
does
and
actually
I
yeah
I
I
think
it's
much
the
singleton
yeah
much
worse
than
the
singleton
problem.
I
I,
just
posted
in
the
channel
but
hi
I-
think
that
in
the
the
packages
that
are
perhaps
most
older
to
offer
first-class
ESM
and
requires
support,
minimal
disturbance
are
also
there's
also
a
good
chance,
they're,
the
ones
that
are
likely
to
be
depended
on
by
sub
dependencies.
G
So
it's
not
I
can
see
why
a
single
application
like
a
single
codebase,
you
could
just
say,
listen
suck
it
up,
you
know,
use,
require
or
use
import,
don't
require
and
import
the
same
dependency.
That's
just
mining,
and
that
would
make
sense,
but
it
doesn't
does
it
doesn't
fix
the
story
of
your
sub
dependencies
and
sub
sub
dependencies.
Some.
G
A
A
C
That
seems
fair
and
if
anyone
wants
to
just
even
have
some
one-to-one
time,
I'm
happy
to
just
check
through
it.
I
myself
like
to
be
very
blunt,
I've
been
trying
to
be
kind
of
as
even-keel
about
this
I
should
not
allow
the
hazard
but
honestly
and
potentially
erring
towards
allowing
it
based
on
where
the
conditional
export
proposal
is.
So.
If
anyone
has
questions
just
reach
out-
and
let
me
know.
A
I
A
I
Actually,
I
have
something
to
add
which
might
be
in
there
ready,
I'm,
pretty
sure,
I'm
pretty
sure
the
removal
landed
in
13.0
and
this
deprecation
did
not
so
I
think
we're
I
think
we're
pretty
well
set
on
the
we're,
not
gonna
land.
This
path,
I
would
prefer
to
have
James
involved.
In
that
conversation,
though,
he
last
I
checked
was
the
only
person
who
felt
that
there
should
be
a
deprecation,
but
that,
but
he
seemed
flexible
on
that
I've
already
been
removed.
That
is
my
understanding,
I
believe
it
landed
in
13.00.
I
I
A
That
yeah
I,
don't
guess
I,
don't
quite
understand
how
you
can
deprecated
something
that
was
already
removed,
but
the
the
other
comment
that
I
think
it's
worth
bringing
up
is
that
Ana
mentioned
that
you
know
her
suggestion.
Was
it
and
this
kind
of
in
this
kind
of
situation,
the
preference
her
preference
would
be
actually
just
subbing
out
like
if
we
can
make
something
a
stub
and
I
know.
Aa
person
is
removing
it.
A
We
should
probably
just
do
that
because
it's
gonna
be
less
work
than
runtime
deprecating
or
you
know,
yeah
it'll
be
less
work
than
runtime
deprecating.
It
doesn't
hurt
anything
and
in
terms
of
maintenance,
it's
really
not
much
to
just
leave
an
empty
stuff.
That's
doing
nothing
they're
going
forward,
and
that
definitely
seems
like
a
reasonable
approach
to
me
and
it's
so.
I
Mean
I
think
it's
a
sensible
approach,
but
I
don't
know
that
we
necessarily
need
to
document
it
Anna
we're
on
I,
guess:
we'd.
Ask
her
her
feelings.
I!
Do
think
that
this
particular
issue
can
kicked
back
to
the
issue
tracker,
but
I
should
stop
talking
and
let
other
people
say
something
if
they
have
anything
to
say
about
it.
A
E
I
A
G
There
yeah
I'm
here
time,
yeah
I,
talked
to
Chris
a
good
person
yesterday,
there's
an
ongoing
problem
with
no
chip
on
with
OSX
catalinus
and
Mac
weirdness
/
bug,
but
that's
not
directly
related
to
the
Python.
It's
just
in
the
Python
code.
The
Python
situation
seems
to
be
okay.
The
the
first
step
with
python
2
is
still
preferred
in
nodejs
Belvin
in
no
chip.
However,
if
it's
not
present,
python
3
will
be
used.
So
that's
the
situation
of
the
various
like
it.
No
chip,
npm
and
nodes,
but
process
itself
right
now.
G
The
expected
situation,
we're
pretty
sure,
that's
the
situation
everywhere.
We're
running
Python
3
tests
and
Travis
sokrat
mr.kekada
3.
Everything
else
in
our
CI,
since
we
do
have
time
to
write
now,
should
be
doing
Python
2,
it's
possible.
You
know,
as
new
machines
come
out,
they
might
only
have
Python
free,
so
see
that
so
you
know
the
situation
is
like
step.
One
good
I
think
we're
right.
Right
now
were
in
a
wait-and-see
phase,
so
we
should
be
keeping
our
eyes
out
for
any
issues
reported
in
the
community
or
any
experience.
G
Anybody
hears
on
the
street
and
I
have
their
hallways
of
issues
if
there
are
issues-
and
you
can
fix
them
if
there
aren't
probably
another
month
or
two
we'll
we'll
consider
making
this
lip.
So
the
Python
3
is
preferred
over
Python
2
if
it
exists,
but
we're
not
in
a
we're,
not
in
a
super
hurry
to
do
that,
and
that
is
the
next
step.
So
as
it
is
now
we're
in
pretty
good
shape
in
sunlight,
I.
C
G
So
I
would
I
would
base
our
transition
not
so
much
on
what
the
Python
does
is
farted
under
life
in
it,
but
as
what's
what
we
think
will
be
most
disturbing
for
our
community,
so
I'm
I,
don't
think
we
have
to
coordinating
but
I'm
I.
Don't
have
really
strong
feelings,
and
if
anybody
does
other
feelings-
or
you
know-
is.
F
G
Into
internal
problems,
please
tell
me
I
think
the
main
thing,
which
is
a
companies
that
say:
okay
at
the
end
of
life,
we
are
banning
27
everything,
one
of
our
missions
and
only
a
Python
3.
Our
belief
is
that
those
systems
won't
work
right
now
with
Python
3.
If
you
just
deleted
Python
2
7,
which
is
the
main
goal
for
us,
and.
G
This
say
the
safe
thing
has
an
ollie.
The
safest
thing
would
be
to
consider
senator
made
here.
On
the
other
hand,
if
like
if
new,
OSX
or
Linux
mission
distros
come
out
in
the
fall
or
spring
that
don't
have
any
Python
2
and
we
hear
absolute
radio
silence,
nobody
makes
any
complaints
all
those
machines
I
only
started
using
Python
3
everybody
will
find.
Well,
then
maybe
we
could
make
the
case
that
it's
not
some
ver
major,
that
it's
basically
unnoticeable
and
nobody
should
care.
G
C
G
A
C
C
I
think
that
would
be
a
good
reason
to
start
pushing
for
it
at
least
to
land
it
on
master,
but
I
think
Sam.
We
could
land
it
on
master,
assembler,
major
and
then
discuss
about
landing
on
13
as
minor
and
then
potentially,
even
if
we
want
a
backcourt
at
212,
although
I
doubt
that
we'd
want
to
do
that
during
LTS.
So
you
know
I
think
since
the
fallback
is
there
on
12
and
it's
reasonable
fixing
this
on
master,
you
know
before
the
end
of
life
date
would
be
a
good
time
line.
In
my
opinion,
I.
G
A
A
Okay,
so
I've
removed
the
tag.
I
think
I've
removed
the
TSC
tag
from
the
issue
and
we'll
move
on
to
the
next
one.
The
next
one
is
under
the
nodejs
admin,
and
this
is
the
collaborator
summit
which
I
think
I've
already
mentioned,
I
think
Matteo.
You
had
added
this
to
the
agenda
I'm
thinking
we
can
probably
remove
unless
you
want
something
else
wanted
to
leave
it
on
for,
for
some
reason,
I.
B
A
A
G
F
G
A
A
A
A
J
Can
say
something
about
the
eight
yep
so
I'm
working
on
the
integration
of
the
87.9
into
master
and
almost
everything
is
fine.
Now
we
just
have
a
problem
on
Mac
OS
and
it's
probably
again
a
compiler
bug
in
Xcode,
8,
so
I
think
miles.
You
helped
us
last
time
with
that
or
some
colleague
of
you
hurt
us.
J
C
A
Is
is
helping
is
working
with
our
interns
on
that
it
there
is
a
fair
amount
of
complication,
though
so
I
don't
think
it's
gonna.
Be
it's
not
reasonable
to
expect
it's
this
week
or
next
week,
or
even
necessarily
this
month,
it
could
be
not
saying
it
can't
be,
but
in
terms
of
the
different
things
that
need
to
happen
to
get
a
machine
there,
it's
not
clear
that
it
will
be
within
that
time.
That
kind
of
time
period
is.
A
You
can
get
in
and
are,
you
know,
can
understand
how
ESX
works
and
because
I
that
there's
two
things
going
on
one
is
at
our
existing
infrastructure
provider.
When
refactored
looked
at
it
before
it
sounded
like
we
couldn't
just
spin
up
new
machines,
10.14
machines,
which
is
what
we
need.
It
might
need
an
ESX,
upgrade
and
and
so
forth.
So
Sam
is
starting
to
look
at
that,
but
you
could
probably
get
together
with
him
and
understand
better.
You
know
what
would
need
to
happen
on
that
front.
On
the
other
side,
we
do
have
some
machines.
A
We
were
ramping
up
at
near
Forum,
but
they're
starting
from
scratch.
So
you
know
we've
got
to
get
the
virtual
vmware
on
there
and
so
we're
doing
that.
I'm
may
happen
faster
than
I'm
saying.
I,
just
don't
want
to
set
any
expectations
on
that
actually
coming,
you
know
being
in
place
in
a
fast
amount
of
time.
Okay,.