►
From YouTube: 2022-05-25-Node.js Technical Steering Committee meeting
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
So
welcome
to
the
node.js
technical
steering
committee
meeting
for
may
25th
2022
we'll
follow
the
agenda,
as
was
posted
in
the
issue,
which
was
issue
number
30..
A
I
guess
just
worth
mentioning:
opengs
world
is
coming
up
and
we
have
a
collaborator
summit.
I
think
there's
at
least
six
or
seven
like
node
specific
sessions
planned
for
the
collaborator
summit
so
far,
so
if
you're
available
and
able
to
make
it
there,
keep
that
in
mind
just
something
it
could
be
good
to
do.
A
I'm
also
thinking
like
the
one,
the
collaborator
sessions
that
I'm
in
you
know
we'll
try
at
least
the
zoom.
You
know
the
zoom
link
where
so
people
can
join
as
well,
so
don't
necessarily
have
to
be
there
for
to
participate
in
some
of
that
as
well.
A
A
A
The
key
thing
is:
was
just
around
wording
and
like
there's.
No,
the
wording
there's
concern,
it
might
lead
to.
You
know
the
cross
project
enforcement
versus
individual
project,
which
is
not
not
the
intention
at
all,
but
that
was
mostly
what
the
discussion
was
on.
Otherwise
yeah,
nothing.
I
I
don't
think
anything
else
jumps
out
in
mind
in
terms
of
things
to
mention
yeah.
A
In
terms
of
the
board
meeting,
just
the
heads
up
that
typically
the
board
meeting
is
the
third
friday
of
every
month.
That's
not
the
case
this
time,
because
we're
doing
it
live
and
in
person
the
monday
of
the
week
of
opengs
world,
so
that
will
be
june
6th.
I
think,
instead
of
what
you
might
be
expecting,
and
otherwise
I
don't
have
anything
on
the
board
front.
A
The
first
one
is
revert:
the
change
of
network
interfaces,
family
from
string
to
integer
and
there's
sort
of
an
issue
and
a
pr
related,
43054
and
43014.
A
I
think
the
latest
on
that
is,
you
know,
we've
discussed
it
before,
and
there
was
agreement
in
a
previous
meeting
to
do
the
revert.
There's
been
some
challenges
with
that
revert
because
tests
were
failing.
The
last
comment
I
saw
from
antoine
was
that
he
had
to
revert
to
the
behavior
of
17,
which
is,
I
think,
if
you
pass
in
ipv4
or
ipv6,
it
ends
up
being
zero,
and
I
just
looked
at
this
not
too
long
ago,
so
I
didn't
quite
understand
the
implication
of
that.
A
This
is
the
particular
comment.
If
anybody
wants
to
take
a
quick
look,
where's
the
chat
here
we
go,
it
says
for
some
reason:
interpreting
ipv4.
I
think
the
string,
s4
and
ipv6
the
string
is
the
number
six
was
not
working
on
some
hosts.
So
now
it's
interpreted
as
zero,
as
was
the
case
in
note,
17
and
below,
obviously
that's
far
from
ideal,
but
it
seems
to
be
the
only
way
I
could
find
to
revert
the
change
on
on
node.net
and
have
all
the
tests
pass.
C
Yeah,
I
think
the
issue
might
be
that
the
tests
are
not
I'm
not
fully
resilient
on
all
all
of
our
ci
setup.
So
with
the
old
behavior,
with
with
the
strings,
when
it
was
closed
to
zero,
you
would
effectively
be
running
in
an
ipv4
only
mode,
so
the
tests
that
were
trying
to
do
things
with
network
interfaces
were
always
then
picking
up.
Ipv4
interfaces
with
what
antoine
was
originally
doing,
which
was
to
you
know,
theoretically
correctly,
have
ipv6
mean
ipv6.
C
We
were
then
finding
tests
were
failing
on
systems
because
they
were
now
running
on
network
interfaces
that
they
weren't
running
on
before,
whether
that's
because
the
tests
are
you
know,
make
making
incorrect
assumptions
about
so
ipv6
is
not
just
ipv4
with
different
addresses.
Ipv6
has
other
differences
and
changes,
and
especially
for
things
like
when
you're
doing,
network
interfaces.
There
are
differences
in
terms
of
things
like
broadcasting
or
even
whether
you're
allowed
to
connect
connect
to
like
the
the
wild
card
address.
So.
C
Yeah,
so
I
think
I
think
it
shall
going
back
to
that.
Zero
is
odd
on
the
surface,
but
it
is
consistent
with
behavior
we
had
before.
So
it's
kind
of
resetting
us
back
to
the
the
behavior
in
node
17,
even
if
that
behavior
is
probably
not
technically
correct,
but
maybe
maybe
we
do
that
and
then
sort
of
look
at
looking
at.
Maybe
fixing
fixing
the
actual
behavior
later
on.
But
the
issue
is
that
we
we
haven't
been
able
to
get
a
clean
ci
run
without
going
fully
back
with
that
revert.
A
C
C
It
it
is
the
test
passed
addresses
between,
like
the
the
the
server
being
created
and
the
client
said,
the
client
connected
the
server
and
it's
it's
it's
getting
values
out
of
that.
So
I
think
it
is
getting
ipv6
if
the
server
thinks
it's
got.
An
ipv6
address.
A
D
So
I
believe
I
understood
the
issue
here
because,
as
far
as
I
see
it,
it's
actually
a
different
change
in
between
and
the
dns
lookup
became
a
little
bit
different.
D
I
I'm
not
certain
that
it
does
not
do
any
coercion
anymore
and
if
you
do
a
conversion
with
like
any
string
and
then
I
do
a
binary
shift
by
zero,
you
will
receive
zero
and,
and
that
could
have
been
the
the
piece
that
was
in
there.
You
know
like
it
didn't
matter
if
you
had
ip4
version
4
or
6
before,
because
that
string
would
always
be
coerced
to
0
when
it
was
not
a
number,
we
would
create
a
deprecation
warning,
but
that's
it
and
what
does
zero
mean?
A
zero
is
it'll.
D
I
believe
it
is
choosing
the
first
one
which
is
returned
by
the
network,
I'm
not
certain
anymore.
I
have
to
look
it
up
on
my
own.
A
A
D
A
A
E
Part
of
me
thinks
we
just
need
more
eyes
on
it
as
many
people
as
we
can
to
go
in
and
weigh
up.
A
Was
added
to
the
agenda
by
darshan?
I
don't
know
if
anybody
else
is
kind
of
up
to
date
on
the
discussion
in
there
has
comments
or
thoughts.
A
A
And
the
commits
are
the
ones
that
would
be
hidden
are
like
ones
that
are
mostly
like
you
know,
hey
you've,
added
commas
or
something
like
something
formatting
that
kind
of
stuff.
I
see
I
see
reuben,
you
have
some
thoughts.
D
D
Yes,
they
are
just
probably
trivial
changes,
but
I
personally
always
like
to
have
100
of
what
has
actually
happened
and
not
skipping
anything,
and
we
have
to
go
through
multiple
blame
steps
anyway,
pretty
much
when
we
want
to
check
for
things
so
having
these
big
ones
in
between
is
something
that
we
stumble
upon
with
former
commits
anyway,
and-
and
I
don't
really
think
that
we
yeah
benefit
a
lot
from
it
at
the
moment.
That's
my
personal
take
on
it
without
like
having
a
really
strong
opinion.
D
E
I
kind
of
share
similar
sentiment
to
ruben,
like
I
often
take
a
look
in
the
blame
when
back
porting
and
things
for
release
lines
and
for
something
to
be
missing
I
can.
I
can
imagine
I
will
trip
over
that
at
some
point
and
I
think
I
think
this
only
applies
to
the
github
ui.
Is
that
correct
when
using
blame
in
the
github
ui?
Is
it
I.
E
C
E
Yeah
yeah
still,
I
do
use
the
github
ui,
but
that's
just
one
workflow
and
I
wouldn't
want
to
hold
up
that-
and
there
was
another
comment
in
here
that
made
me
think,
which
was.
Would
this
give
the
green
light
to
massive
co-chairs.
E
Like
I
hope
not
because
that
can
cause
other
challenges,
not
just
with
git
bling.
C
C
It's
the
fact
that
the
churn
is
causing
differences
between
what's
on
the
sort
of
development
branches
versus
what's
in
the
release
branches
and
it
sort
of
makes
back
porting
or
cherry
picking
commits
between
releases
incredibly
hard.
So
you
know
the
main
objection
to
churn.
Isn't
that?
Oh,
it
makes
it
harder
to
to
blame,
or
you
know,
blame
keeps
fingering.
This
particular
commit
it's.
The
code
base
is
fundamentally
different.
C
Yeah,
but
that
I
mean
that's
going
off
from
the
tangent,
but
in
terms
of
that
particular
commit
comment
about,
does
that
give
the
green
light
to
changes
that
introduced
massive
churn?
No,
it
does
not,
at
least
not
from
my
point
of
view.
You
know
I
I
will.
I
will
object
to
changes
that
introduce
massive
churn
unless
it's
demonstratively,
you
know
that
there's
sort
of
the
convenience
of
the
huge
churn
out
weighs
the
pain
it's
going
to
cause
for
managing
releases.
A
I
think
maybe
we
can,
you
know,
leave
on
the
agenda
until
you
know
we
have
a
meeting
where
darshan
is
is
in
attendance
since
he
added
it,
but
it
sounds
like
nobody's
like
enthusiastically
saying
yeah.
We
should
go
ahead
and
do
this
right.
A
A
A
I
know
he's
sick
this
week,
so
I
I'm
not
sure
we
need
to
block
on
mateo,
like
I
think
the
fundamental
question
is,
you
know
global's
when
we
add
something
to
a
global,
that's
got
the
potential
to
clobber
polyfills
and
you
know
we
may
run
into
the
same
problem
and
our
fundamental
decision
is,
you
know:
do
we
do
we
stay
consistent
and
make
what's
global
in
the
browser
global
or
do
we
avoid
that
and
put
it
non-global?
C
I
don't
know
if
anybody
has
any
thoughts
or
opinions
on
that
yeah
do
don't.
We
typically
add
things
as
a
sort
of
experimental
you,
you
don't
get
it
unless
you
turn
the
flag
on
and
then
like
in
the
next
major
or
subsequent
major
sort
of
make
it
one
by
default,
which
is
kind
of
what
happened
here
except
the
for
the
fetch.
It
was
a
very
short
window
between
it,
going
into
note,
17
and
then
node
18,
coming
out
where
the
default
was
flipped
to
being
enabled.
C
Well,
I
don't
know
because
it's
sounding
like
part
of
the
problem
with
this
particular
module,
is
it
isn't
actively
maintained
or
it
was
questionable
whether
it
was
being
actively
maintained
yet
was
reasonably
sort
of
popular
in
terms
of
use,
but
I
think
typically
for
globals.
We
would
normally
have
to
have
it
in
a
current
release
and
then
like
the
next
major,
would
then
make
it
visible
by
d.
You
know
visible
without
a
flag.
C
A
A
A
A
Some
more
people,
so
maybe
we
can,
you
know,
talk
about
it
again
next
time,
but
at
least
in
my
understanding,
it's
sort
of
our
decision
is
like
well.
Would
we
consider
not
making
it
a
global
because
of
this
issue
or
or
you
know,
if
it's
global
in
the
browser,
it
should
be
global
and
that's
you
know
yeah,
it's
back
then,
to
what
richard
said
like
we
just
flipped
the
switch
to
look
too
quickly
this
time
right.
A
A
Okay,
so
the
next
one
is
rename
default
branch
from
master
domain.
We
talked
about
la,
we
did
talk
about
this
last
time.
There
were
no
objections
to
proceeding.
Obviously,
some
some
concern
slash.
A
I
don't
know
what
you
would
call
where
we
know
there's
some
risk
here,
but
we
know
we
need
to
proceed
so
the
next
step
really
is
just
to
plan
to
do
the
rename
to
node
repo.
So
you
know
myself
and
richard
will
figure
that
out
and
we'll
do
that-
I'm
not
sure
that'll
be
you
know
immediately.
A
C
A
C
Even
knowing
about
it-
and
you
know,
we
did
the
build
repo
and
I
know
I
we
did
the
build
river
because
I
did
it
and
I'm
still
occasionally
logging
into
environments
and
forgetting
that
I
haven't
updated
them
and
find
it
finding
the
upstream's
on
picking
up
changes.
So
I
can
quietly
see
it.
You
know,
but
yeah
that
it
is
what
it
is.
Yep.
A
Okay,
the
next
one
process
add
clay
actually
on
that
one
I
I'm
gonna.
A
E
A
And
I've
been
trying
to
ping
people
there
with
no
lock
and
I'm
not
so.
The
comment
is
that,
like
crowding,
is
somehow
linked
to
that
and
if
we
rename
it
it's
going
to
mess
up
crowding,
but
I
can't
seem
to
find
anybody
who
is
active
or
is
you
know
knows
anything
about
proud,
and
I
I
looked
in
our
in
our
secrets
and
I
don't
know
richard
if
you've
seen
it
somewhere
that
I
missed
but,
like
I
couldn't
find
info
for
how
we
would
like
log
into
crowdin.
B
Dormant,
let's
say
for
node.js,
I
don't
think
I
think
iat
i18n
is
also
like
the
the
internationalization
part,
not
the
icu
part,
but
the
like,
let's
you
know,
get
translations
thing
is
also
like,
has
also
withered
and
died.
It
was
a
valiant
effort
at
this
point.
All
of
our
translations
are
done
via
direct
pull
requests
to
the
nodejs.org
repository,
which
I
think
is
appropriate.
A
A
E
A
A
C
C
C
It
said
no
no
invokement
from
build,
they
said
there
won't
be
anything
in
secrets
about
it
because
it
wasn't
it
wasn't
the
build
initiative,
it
wasn't
the
tsc
initiative
right.
I
don't
even
know
who
who
had
the
keys.
A
Yeah
I
tried
to
kind
of
ping
the
people
who
I
thought
might
have,
but
I
I
know
they're
you
know
haven't
been
able
to
been
active
lately.
I
think
I
think
we've
arrived
at
a
decision
on
this.
So
basically
you
know
that's
where
I
was
leaning
and
I'm
just
looking
for
a
little
bit
more
support
in
terms
of
like
yeah
I'll
go
ahead
and
do
it
and
if
people
scream
I'll
say
at
least
asked
and
yeah
okay.
So
it
sounds
good.
So
I'm
going
to
just
take
a
note
to
cover
me.
A
A
Okay,
thank
you
so
yeah
we
can
move
on
to
the
next.
One
then,
which
is
process
add,
ply,
opt
to
hide
experimental
warnings,
so
this
is
number
31,
31
000..
I
went
to
look
to
see
who
added
it
and
realized.
I
added
it.
So
the
reason
I
did
that
was
the
discussion
seems
to
kind
of
stalled
out
and
you
know
so
it
you
know.
There's
been
some
discussion
and
you
know
the
the
complaint
is
especially
in
some
of
your
dependent
things.
You
can.
A
You
can
get
a
lot
of
the
experimental
warning
things
and
you
know-
and
it
can
be
quite
quite
quite
annoying-
slash
challenging
if
you
know
and
it's
something
you
can't
turn
off
the
other
flip
side
is
you
know,
there's
some
people
saying
well,
we
you
know,
there's
objections
to
an
option
which
would
turn
them
all
off,
because
of
course
we
don't
want
people
to
not
know
that
they're
using
experimental
things.
A
A
So
I
think
that
you
know
why
the
reason
I
added
to
the
agenda
was
to
see
if
we
can
get
an
opinion
from
the
tse
that
says
you
know,
would
we
would
we
be?
You
know
receptive
to
an
option
that
I
think
my
question
would
be.
Would
we
be
receptive
to
an
option
that
disables
individual
experimental
warnings
and
have
it
be
usable
in
node
options.
A
C
I
mean
the
argument
for
allowing
it
node
options.
Is
the
the
warnings
may
be
coming
from
dependencies
that
you
have
no
direct
control
over?
So
you
know
I
I
can.
I
can
understand
people
wanting
to
perhaps
turn
them
up
if
they,
if
they,
you
know,
look
for
things
that
they
they're
using,
but
they
they
can't
influence
in
terms
of
what
it's
actually
doing
on
the
recovers.
C
I
would
favor
if
there
was
mechanism
for
doing
individuals
over
a
blanket.
Is
there
not
already
there
is
already
an
option?
Isn't
it
to
turn
up
all
warnings?
I
mean
it's
a
it's
a
it's
an
all-or-nothing
thing.
I
thought
I'd
have
to
look
at
cli.
C
Have
to
look
at
that
in
a
in
a
particular
case.
I
think
it
was.
It
wasn't
just
warnings
that
turned
off.
No
sorry,
I
think
it
was
all
warnings,
so
not
just
experimental
ones.
It
just
was
a
binary
on
or
off
could
be
wrong,
but
yeah.
I
I
do
think
if
you
could
turn
up
individual
ones.
What
I
don't
know
is,
I
know.
For
example,
we
have
deprecation
codes
for
deprecations,
but
I
don't
think
at
least
I'm
not
aware
that
we've
got
codes
on
x,
individual
warnings.
A
There's
some
discussion
that
makes
me
hope
we
do
like.
I
see
like
one
of
the
examples
there
says
like
node,
2159
experiment,
that's
the
process
id
okay!
So
there's
some
confusion
because
then
it
would
be
like
ignore
warning.
Two
thousand
was
right:
it's
okay.
C
Yes,
I
think
I
would,
and
if
the
worry
is
that
people
can
slip
things
into
node
options.
Well,
I
mean
you
on
one
hand
you
should
have
control
over
your
environment
and
then,
on
the
other
hand,
and
the
other,
you
know
we
have
tooling.
We
have
things
like
report
that
will
dump
out
the
environment
variables
that
are
in
in
use
in
the
process.
So
I'm
not
overly
concerned
about
adding
things
to
your
lap.
A
B
A
That's
where,
like
I,
I
get
the
I'm
also
like
not
a
just
turning
them
all
on
is
not
something
I'd
want
to
make
too
easy
or
sorry
to
off
too
easy,
but,
like
the
individual,
one
seems
like
a
reasonable
compromise
and
then
I
I
can't
see
that
excluding
from
node
options
actually
helps.
It
just
makes
it
harder
and
yeah.
So.
E
A
I
guess,
like
you
know,
if
that
was
the
proposal,
would
anybody
here
object
to
that
proposal
and
say
no,
we
don't
want
to.
We
don't
want
to
do
that.
A
A
So
you
know
a
smallish
subset,
the
from
the
discussion.
There,
no
objection
from
the
group
from
those
those
who
were
there
if
there
was
an
option,
if
if
there
was
an
option
to
disable
disable
specific
experimental
mental
warnings-
and
that
was
also
supported
in
node
options-
is
that
is
that
fair
everybody
happy
if
I
add
that
as
a
comment
to
possibly
get
this
moving
again.
C
A
That
moves
us
on
to
the
next
one,
which
is
end
of
life,
dates
for
note,
16
and
open
ssl
1.1.1
do
not
align
number
one.
Two,
two
two
two
richard.
I
know
you
were
looking
at
that.
So
if
you
want
to
bring.
C
Us
up
to
date,
yeah.
I
need
to
update
the
issue.
I
I've
spent
the
last
week
looking
at
so
so
I
had
it.
A
suggestion
was
put
to
me
last
week
about.
Could
we
take
openness
to
sell
updates
from
the
the
central
state
history,
mate
project
or
basically
upstream
rail
date,
because
red
hat
maintain
openness
cell
in
for
real
for
l8?
C
C
So
it's
not
as
easy
as
the
current
openness
cell
update
process
that
we've
got
with
the
quick
talk,
but
the
main
sort
of
conclusion
was
that
there
are
very
visible
differences
between
the
open
source
code,
that
red
hat,
maintain
versus
the
sort
of
upstream
open
ssl
that
we're
currently
using
in
or
sort
of
the
four
could
be
upstream,
like
an
ssl
that
we're
currently
using
note
16..
So
it's
not
really
something
I
think
we'd
I'd
be
comfortable
recommending.
C
We
do
because
it's
such
a
visible
one
of
the
things
that
that's
done,
for
example,
is
as
some
sort
of
some
of
the
algorithms
are
removed
from
the
openness
cell
code.
C
That's
in
centos
extremely
so,
for
example,
the
list
of
available
cryptographic
curves
is
is
much
less
in
that
sort
of
version
of
openness
cell
than
than
what
we've
currently
got.
So,
if
we're
going
to
end
up
in
that
scenario,
where
effectively
there
are
breaking
changes
anyway,
then
I
much
prefer
that
we
went
to
episode
3
and
I'm
not
really
in
favor
of
doing
that
either.
Given
that
you
know,
we
know
that
that's
causing
compatibility
issues
already
so
yeah,
I
sort
of
had
a
look
at
it
explored
it.
C
I
kind
of
feel
that
we
can
rule
it
out
so
yeah.
I
think
we
sort
of
go
ahead
and
make
I
guess
I
can
try
and
put
some
words
together
and
pr
up
into
the
website,
and
then
we
can
sort
of
review
that
get
that
out
there
and
just
sort
of
put
the
message
out.
I
guess
I'm
open,
you
know.
C
If
people
come
along
later
on
and
say,
you
know
hey
how
about
how
about
we
do
this,
or
maybe
some
of
the
compatibility
issues
working
with
sort
of
three
could
be
worked
out,
but
where
we
are
right
now,
I
think
the
sensible
course
is
to
just
go
ahead
and
shorten
the
shorten
that
date.
It
is
unfortunate,
I
know
I've.
B
And
I'd
rather
announce
that
we're
shortening
it
now,
rather
than
waiting.
You
know
a
year
and
then
announcing
it.
You
know
like
give
people
absolutely
the
maximum
and
then,
if,
if
something
comes
up,
something
happens
such
that
we
can
in
fact
extend
the
life
to
the
original
end
date.
Great,
you
know,
but
it's
probably
not,
and
so
let's
just
tell
people
now
and
not
not
not.
A
Yep,
so
that
that's
what
I've
taken
in
the
minutes
is
like
you
know,
based
on
the
investigation,
it's
unfortunately
more
complicated
and
there's
visible
differences.
So
it's
based
on
that.
It's
really
not
can't
be
recommended
as
an
alternative
source
and
we've
had
no
objections
to
shortening
in
the
issue.
We
agree.
A
We've
agreed
that
we
can
move
forward
on
that
and
that
if
somebody
came
forward
with
a
good
alternative
support
like
if
somebody
came
to
us
and
said,
hey,
we'll
support
openssl
for
you
for
that
seven
months
and
they
made
it,
you
know
they
were
credible.
We'd,
probably
say:
okay,
great,
we
can
extend
the
lifespan,
but
in
absence
of
that
you
know
we're
doing.
We
can't
commit
to
to
maintain
openness,
sell
right
like
that.
A
Okay,
so
richard
were
you,
volunteering
to
pr
and
yeah.
A
Yeah
and
and
thanks
for
taking
the
time
to
to
investigate
that,
if
it
had
panned
out,
might
have
been
a
good
thing.
But
so
it's
worth
exploring
and
shows
that
you
know
we're
looking
at
our
options.
But
we
need
to.
B
A
Okay,
well
thanks
for
that
update
and
all
the
work
there
we'll
move
on
to
the
next
one
tc
chair
election.
So
basically
the
elections
concluded
I
was
re-elected
as
chair.
Matteo
is
co-chair,
so
I
don't
think
there's
anything
further
to
discuss
on
that
one
until
next
year,.
A
Okay,
the
last
thing
we
have
on
the
the
agenda
is
strategic
initiatives.
I
think
next
10
is
the
only
one
we
have
somebody
here
to
to
talk
to.
A
I
don't
really
have
an
update
on
that
other
than
you
know
the
reminder
that
our
next
deep
dives
are
at
opengs
world
and
they're
on
esm
and
on
observability,
and
you
know
what
we
what
we
need
to
do
between
now
and
then
is
just
make
sure
anybody
we
think
that
would
be
would
be
good
to
have
in
that
conversation
or
be
interested
in
those
conversations
are
aware-
and
hopefully
you
know,
participate
either
locally
or
virtually
we've
started
some
of
that
in
the
issue.
E
A
E
Question
there
yeah,
and
I
know
virtual
participation
is
the
aim.
Do
you
know
what
that's
going
to
look
like
yet?
Are
we
going
to
be
using
the
node
zoom.
A
I
think
it's
going
to
be
informal
like
I
don't
know
that
the
the
collaborator
summit
you
know
that's,
I
haven't
heard
anything
some
planning
for
that.
What
I
had
in
mind
is
you
know
somebody
who's
who's
there.
We
can
open
up
a
zoom,
I'm
I
in
terms
of
what
zoom,
what
link
I
haven't
really
thought
about
that.
You
know
worst
case.
I
think
what
I
was
waiting
to
do
is
to
wait
to
look
at
the
schedule
to
see
how
much
overlap
there
is.
If
there's
not
that
much
overlap,
I
think
we
can.
A
Just
you
know,
create
a
zoom
link
that
we'll
use
for
all
of
them.
A
E
A
Yeah
yeah,
so
I
don't
know
when
the
plan
was
to
finalize
that,
maybe
by
the
end
of
this
week
I'll
take
another
look
and
and
we'll
it
doesn't
look
like
you
know.
If
it
looks
like
one
is,
then
it's
pretty
simple.
If
it's
more
than
one,
then
I'm
not
quite
sure
what
we
do.
But
let's
hope
for
the
simple
case.