►
From YouTube: 2023-06-29 Node.js Release Working Group 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
Okay
welcome
everyone.
This
is
the
release
working
group
for
the
node.js
project.
Today
is
the
29th
June
2023
and
we're
here
to
talk
about
follow
along
with
the
agenda
for
the
release
working
group,
but
before
we
get
to
that
21
have
any
announcements
they'd
like
to
make
anything
you'd
like
to
share.
A
A
So
let
me
get
started
with
this
first
one
here
with
this
I
was
asking
the
question
about
the
session
on
the
collaborator
Summit.
There
is
another
node.js
collaborative
Summit
coming
up
in
Spain
in
September,
18
and
question
is:
do
we
do
we
want
to
have
a
session
there
right,
I
know.
Last
time
in
Vancouver,
I
was
expecting
to
have
more
of
kind
of
a
regular
worker
working
group
meeting
there
and
kind
of
didn't
work
out
the
way
that
I
planned
since
no
no
I
was
the
only
releaser
there.
A
Yeah
present
present
there
in
the
conference.
So
I
would
like
a
little
bit
more
planning
this
time.
So
I'd
like
to
add
this
to
gender,
so
that
we
can
start
discussing
it
and
like
yeah,
because
maybe
we
also
want
to
do
a
different
type
of
session,
maybe
more
of
a
presenting
time
to
trying
to
get
people
engaged
excited
about
the
working
on
the
releases.
B
In
person
due
to
travel
issues
but
yeah
I,
don't
know
I
guess
it
depends
on.
If,
if
you
know
you
get
enough,
people
or
other
people
that
are
are
intending
to
go,
I
saw
Michaels
also
said
he
wouldn't
be
attending
in
person.
But
you
know
if
there
was
any
remote
facilities
we
could
probably
attend.
Although
I
think
there
was
some
discussion
that
the
previous
thing
that
the
remote
stuff
was
one
way
only
so
it
was
not
really
conducive
to.
A
Yeah
yeah,
so
yeah
I
think
I
comment
that
in
the
issue
so
yeah
unfortunately
like
well
I
mean
I
think
for
some
of
the
sessions
there
it's
better,
but
for
some
other
ones
where
we
just
want
to
be
able
to
collaborate
with
the
remote
folks.
This
it
was
less
friendly
right
like
because
they
set
up
a
streaming,
and
so
they
kind
of
like
bought
into
one
way
like
it
was
hard
to
get
the
two-way.
A
Maybe
maybe
that's
something
we
can
also
work
on,
like
just
ask
for
them
like
to
figure
out
that
setup
so
that
we
can
have.
We
can
have
the
remote
people
participating
right
like
as
much
as
the
people
that
are
there
in
person,
but
yeah.
B
I
suppose
the
other
question
is:
what
do
we
want
to
use?
You
know
if
we
had
a
session?
What
we'll
do
we
want
to
use
it
for
yeah,
so
I,
don't
know
whether
this
was
just
a
sort
of
more
sort
of
call
for
ideas,
kind
of
thing,
where
yeah.
A
Yeah
I
yeah-
maybe
maybe
you
can
you-
can
share
your
thoughts
on
this
too,
but
I'm
getting
the
impression
that
we're
we
start.
We
start
to
get.
You
know
we
need
to
start
getting
people
more
people
excited
about
joining
like
I
feel
like
we're,
probably
on
the
verge
of
another
kind
of
turnover
in
the
group
like,
and
it's
normal
right
like
and
due
to
various
factors
right
like
life
happens
and
and
I
think
we
it
would
be
good.
A
A
C
I
would
like
to
discuss
a
little
bit
more
about
LTS.
You
know
all
the
esm
worker
thing
that
happened.
It
doesn't
break
it
didn't
break
noticers,
but
the
rest
of
the
competition
did
there's
no
FB
npm
APM
working
right
now,
which
is
really
stuck
because
it's
an
LTS
release.
C
A
I
mean
that
that
can
be
a
session
on
its
own
I.
Don't
think
it
needs
to
go
and
release
working
group
slash
and
that
that
can
be
a
because
I
know.
Yeah
I
know
that
something
yeah
it
was
a
big
discussion
happening
going
on,
and
maybe
the
timing
is
good
well
well,
good
enough
that
it
might
make
sense
to
have
that
discussion
there.
It.
B
B
Right,
it's
probably
too
late
to
make
changes
in
September.
If
those
changes
aren't
already,
you
know
there,
or
the
Imperial
rpr
in
I
mean
a
month
doesn't
sound
like
a
lot
of
time
to
address
any
actual
issues
that
are
already
not
already
in
on
the
way
in
progress
to
being
resolved.
B
I
admit
that
I
don't
probably
understand
the
problem
enough
to
to
be
able
to
tell
whether
those
discussions
about
having
a
proper
way
of
doing
the
things
that
are
currently
broken,
but
I,
don't
know
how
far
along
that
is,
and
whether
that's
likely
to
be
fixed
internally
as
I
can
see
huge
resistance
from
the
loaders
group.
Reverting
The
offloading
great
deal.
B
B
Yeah,
it's
so
we're
breaking
it
and
then
re.
You
know
breaking
or
reverting
the
break,
but
I
don't
know
so
so
this
is
one
of
those
tricky
kind
of
yeah,
I
I
think
we
need
to
continue
the
discussion
or
try
and
get
you
know,
get
that
discussion
continuing
and
not
not
in
a
sort
of
echo
chamber.
B
B
That
is
a
sort
of
deeper
position
we've
had
in
the
past
four
breakages
in
release
lines:
I,
guess
the
the
tricky
bit
there
is
they're
all
equally
being
an
argument
that
it's
an
experimental
feature
but
equally
I
think
there
is
a
large
well,
you
know,
there's
a
significant
portion
of
the
ecosystem
that
are
affected
by
it.
So.
B
B
Yeah
we
can
all
recruit,
decide
to
revert
it,
but
the
question
is:
is
that
likely
to
cause
even
more
friction?
Problems
with
you
know,
internal
issues,
because
we
we,
as
a
release
group,
had
to
make
a
judgment
callers
to
all
the
releases
observing
the
purpose,
so
so,
for
example,
if
they're
breaking
the
community
well,
if
it's
a
regression
in
a
release
line,
then
normally
we
would
want
to
address
that.
This
is
a.
This
is
a
breakage
on
a
sever
major
boundary.
B
Now
the
issue
there
is
that
the
symbol
measure
is
the
boundary
you
would.
You
would
have
breakages,
but
also
we
in
the
past
we've
not
had
semba
majors,
so
we've
not
had
breaking
changes
in
several
Majors
that
have
broken
so
much
in
the
ecosystem
that
it.
You
know
we
the
project,
judged.
B
It
would
be
it's
too
early
to
make
that
change,
and
then
you've
got
the
complication
here
that
it's
in
a
thing
that's
declared
experimental
and
experimental
specifically
says
you
might
get
broken
and
I
know
there
was
something
that
landed
about
trying
to
Nuance
experimental
status,
which
I
I.
Don't
know
that
complicates
things
more
than
you
know.
It
makes
things
easier
to
understand
whether
things
can
or
cannot
break
or
be
sort
of
changed,
but
yeah.
B
It's
it's
kind
of
I
think
this
is
a
hard
judgment,
call
either
way
unless
there
is
a
sort
of
happy
path
where
an
official
sort
of
probably
still
experience,
but
probably
it
will
still
be
experimental,
but
a
sort
of
more
kind
of
approved
way
of
doing
the
things
that
have
been
broken
in
with
loaders
happens
and
I
think
that's
always
one
of
the
things
where
I.
As
far
as
I
know,
it's
been
a
goal
of
the
project,
but
I
don't
know
how
far
along
that
is
and
whether
that's
likely
to
be
done.
B
A
I
had
this
issue
here
that
we
were
discussing
in
one
of
the
TSC
meetings
and
yeah
I
I,
also
as
a
follow-up
there,
I
kind
of
wanted
to
put
this
in
the
agenda
ended
up
not
get
by
the
DRM
automation,
so
I
ended
up
nodding
the
agenda,
but
it
was
one
of
the
things
we
kind
of
wanted
to
talk
about,
but
more
of
more
on
the
this
was
a
more
high
level
discussion
like
yeah.
C
B
And
I
think
part
of
that
issue,
which
has
been
a
long-standing
issue
or
problem
that
we've
had
in
with
releases
is
most
people.
B
I've
spoken
to
the
cut
this
in
the
major
release
of
node
would
prefer
that
the
features
go
into
the
main
main
branch,
like
you
know
at
least
a
month
before
we
do
the
release,
preferably
even
earlier
than
that,
but
we
always
seem
to
like
end
up
pushing
things
in
like
two
weeks
before
one
week
before
the
release
goes
out,
which
means
there's
very
little
testing
of
that
out
in
the
wild
and
yeah
I
I,
don't
know
what
the
solution
there
is
because
we've
tried
I,
think
Raphael.
B
Another
part
of
that
issue
which
I
don't
know
what
the
answer
to
Is
there's
a
lot
going
on
in
node
I
mean
node,
is
a
huge
project
and
being
able
to
work
out
who
needs
to
be
informed
of
what
changes
or
what
who
is
going
to
be
impacted
by
certain
changes.
I,
don't
think
it's
an
easy
thing
to
to
to
to
determine
it's
like
you
know,
oh
yeah
person
X
may
be
interested
in
certain
things
per
person
why
it
may
not
be,
and
again
this
this
comes
back
to
other
discussions
about
things
like.
B
What's
a
notable
change
in
the
change.
Look,
you
know
it's
something
something
that's
notable
to.
One
person
may
not
be
noticeable
to
somebody
else
and
even
the
things
we
put
in
notable
changes.
It's
like
well
it
it's
notable,
but
then
how
much
detail
have
we
've
got
access
to
that
we
can
put
in
the
release
notes
as
releases
versus
the
yeah.
B
Yeah
there's
always
things
we
could
possibly
get
better
at,
but
I
think
a
lot
of
it
is
I.
Don't
think,
there's
an
ideal
answer
to
some
of
the
questions
that
come
out
of
these
things.
So
fundamentally,
I
think
we
do
expect.
You
know
it's
not
unexpected
that
and
that
symbol
major
may
have
breakage.
The
question
is
whether
that
breakage
is
intentional
and
if
it
is
intentional,
whether
that's
proportionate
to
whoever's
being
broken,
because
you
know,
if
we
say
December
Majors,
don't
have
breaking
changes.
B
Then,
what's
the
point
of
December
later
you
never
have
this
in
the
major
you'd
continue
forever,
with
Patrick
minor
releases
and
patches.
So
there
is
a
icing
yeah
yeah
Majors
will
have
breaking
breaking
changes
in
and
the
question
then
is
well
who
is
going
to
be
affected
by
those
changes.
Now
some
of
the
changes
are
larger
than
others,
and
that
I
think
is
an
area
there
where
the
release
team
needs
help.
B
I
I
would
suspect
that
you
know
the
larger
the
change
that
is
being
dumped
into
number
major,
the
more
risk
it
will
be.
But
it's
hard
to
gauge
that
just
reading
some
of
the
code
and
the
sort
of
the
Oz.
B
B
So
yeah.
You
know
that
node
doesn't
have
a
magic
one.
That
says
this
breaking
change
is
going
to
go
out,
but
it's
not
going
to
affect
anyone.
We
try
our
best
to
detect
things
where
we
can
detect
them
and
not.
Every
module
can
be
run
in
stitching.
So
you
know
there
are,
and
then
we've
got
other
issues
with
stitching
and
situations
and
there's
always
red.
So
it's
it's
actually
hard
to
filter
out
five.
B
A
B
But
yeah
I
I
think
having
those
kind
of
things
with
General
discussions.
Maybe
I
think
the
problem
there.
Is
it
Bots
up
against
the
so
if
the
goal,
if
one
of
the
goals
is
to
get
more
releases,
I
think
the
other
discussions
are
probably
too
Specialized
or
they're
they're,
not
I,
don't
know
it's
kind
of
like
you
have
one
discussion
which
is
trying
to
get
people
in
and
then
another
discussion,
which
is
all
all
the
walks
of
the
current
challenges.
B
I
want
to
hide
them,
but
they're
not
really
the
same
audience
in
effect,
it's
kind
of
balancing,
because
I
don't
know
how
much
time
you'd
have
in
a
session,
and
it
may
be
that
it
might
have
to
be
separate
sessions.
If
we
wanted
to
talk
about
more
than
one
thing
at
the
summit,
but
definitely
as
a
more
sort
of
General
topic,
that
probably
would
be
better.
It's
just
a
summit.
B
I
think
specifics.
The
problem
with
specifics
are
I.
Think,
like
I
said,
if
you,
if
you
have,
if
it's
a
particular
thing
like
you
know
a
particular
thing
with
the
load
as
well
has
challenges,
then,
if
you're
going
to
wait
that
long
before
you
discuss
it
because
then
you're
only
a
month
out
before
the
LTS
release
right.
B
Divorced
from
you
know,
General
policy
thing
divorced
from
the
actual,
a
specific
thing
that
will
probably
be
more
useful.
To
have
I
mean
I
I,
don't
know
I,
don't
think,
there's
anything
more
to
discuss.
But,
for
example,
all
the
stuff
that
came
out
about
the
npm
releases
in
node
LTS
releases
and
when,
when
to
update
npm
I,
know
a
lot
of
discussion
that
has
happened
and
I.
B
Don't
think,
there's
more
to
do
on
that,
or
at
least
I'm
not
that
I'm
aware
of,
but
that's
the
kind
of
thing
that
you
know
might
be
good
for
summer
talks,
because
it's
a
sort
of
General
policy
kind
of
thing,
rather
than
a
specific,
a
specific
thing
for
a
specific
release
line,
but
a
sort
of
more
General
generosity
policy
discussion
probably
would
make
sense
for
Summit,
especially
then,
if
you
can
pull
other
people
in
outside
the
work
group.
B
B
A
Feel
like
that
topic,
like
especially
that
more
higher
level
topic
of
whether
that
interaction
between
okay
experimental
features
but
they've
been
out
for
so
long
like
how.
A
Now
it's
like
a
quick
return
like
now,
it
might
be
a
little
bit
disproportionate
like
right,
the
type
of
breakage
that
you
would
expect
from
experiment
or
like
it
might
be,
and
that's
a
whole
new
discussion
right
like
in
the
but
then
again
it
might
be
it's
probably
too
late
by
the
collabor
by
the
time,
the
collaboration
to
even
try
yeah
a
discussion
that
can
lead
to
us
to
any
type
of
solution.
So
yeah
I'll
definitely
keep
here.
I'll
keep
here
in
the
notes.
A
B
I
guess
one
thing
on
the
working
group
is
that
I
kind
of
feel
that
at
the
moment,
the
current
membership
of
the
working
group
or
on
those
double
actual
releases,
so
so
virtually
everyone
in
the
work
group
is
a
release,
sir
and
and
sort
of
is
on
a
ble
to
make
releases.
But
in
the
past
we
have
had
like
the
LTS
part
of
the
working
group.
B
So
at
the
moment
the
LTS
team
I
think
is
more
or
less
the
same
as
the
releases
team,
but
I
think
in
the
past
we
haven't
discouraged
people
from
joining
the
working
group,
even
if
they're
not
actually
doing
releases.
You
know
if
they
want
to
discuss
release
strategy,
or
you
know
that
that
sort
of
thing,
I,
I,
wouldn't
be
opposed
to
having
bore
people
turn
up
to
these
meetings.
B
To
to
that
are
interested
in
the
things
have
been
discussed
without
actually
you
know
having
to
do
the
commitments
and
says
yes,
I
want
to
do
this
now
we
do
want
more
releases,
the
more
people
who
can
do
releases
and
commit
to
that.
You
know
the
easier
it
is
on
everyone
else
and
the
other
theories
of
the
project,
but
equally
I,
don't
think
that
there
needs
to
be
a.
You
must
be
a
releaser
to
join
the
working
group
The.
The
working
group
is
there
to
make
decisions
over
release,
content
and
policy
and
I.
B
B
C
A
A
A
So,
let's
move
on
here
and
the
next
item
I
had
was
we
had
this
small
slack
notification
this
morning
and
I
just
wanted
to
Bubble
up
here
in
the
meeting,
and
we
start
we
can
start
thinking
about
it
right,
but
basically,
who
is
going
to
be
working
in
the
next
major
release?
Did
we
discuss
that
already
at
any
point
in
time,
return.
B
A
B
B
Don't
know
when,
but
I
suspect,
probably
definitely
before
September
to
give
them
the
chance
to
you
know
be
prepared
and
whatever
have
you
I
think
did
we
have
more
than
one
person
involved
for
the
last
couple
of
releases
well,.
A
The
19
I
paired
with
Raphael
and.
B
B
Yeah
I
mean
let's
yeah.
Now
we've
had
the
problem.
It's
continued
discussions,
maybe
either
in
slack
or
on
on
an
issue
in
GitHub
and
we'll
see
what
people's
availability
are
or
yeah
yeah
yeah.
B
A
A
A
Oh
okay
and
20:
we
only
have
Rafael's
schedule
for
next
week.
Oh
so
yeah,
okay,
and
there
is
definitely
room
for
more
people.
If
anyone
wants
to
we're
gonna.
A
A
It's
great
then
yeah,
then
there's
no
just
the
end
of
July
that
we
need
to
start
thinking
about
before
the
next.
The
next
meeting
and
okay
18.,
so
18
I
did
had
an
update
from
Danielle.
Yesterday
she
said
she's
still
working
on
it.
It
definitely
grew
too
large
right
like
because
it
kind
of
accumulated
tons
and
tons
of
comets
right
from
the
from
the
last
time
that
last
18
release
so
she's
still
working
on
it
and
Amy
next
week.
So
that's
so
it's
probably
going
to
be
out
early
July.
So
let.
B
C
A
And
and
me
I
I,
don't
know
whether
I
try
to
aim
for
end
of
July
or,
if
I
just
go
ahead,
and
how.
How
do
you
historically
like?
How
do
we
handle
these
research?
We
have
to
have
a
minimum
space
of
time
in
between
LTS
release,
lines
or
yeah.
B
I,
don't
think
we've
had
a
minimum
before,
but
we
have
tried
to
space
them
out
a
little
bit.
I
guess
it
depends
on
how
much
how
much
we
feel
would
need
to
go
out
and
I
I
guess.
The
hope
is
that
you
know
the
next
release
will
catch
us
up
enough
that
hopefully
there
will
be
then
too
much
to
land
in
the
next
one
I
mean
I'd,
probably
say.
B
That
we're
going
to
end
up
with
since
the
last
one
so
that.
B
That
is
too
long
and
it's
no
one's
fault,
but
you
know
it
is
an
indication
that
there
has
been
a
gap
and
I
know
that
I
think
some
people
have
been
pushing
for
some
fixes
in
the
18
lines.
So
you
know
it
has
been
a
while
on
the
subject
of
18
I,
think
I
did
see
some
Blackpool
PRS
with
the
people
who
are
trying
to
run
CI
on
and
I.
Think
windows
in
particular
the
Russian
test
test
issues
on
the
infra
machines
that
were
marked
flaky
on
mine.
B
So
we
probably
need
to
mark
that
we
probably
need
to
pull
back
the
myths
or
PRS
that
Mark
those
tests
play
key
onto
both
18
and
16..
B
So
just
to
get
CI
passing
on
on
the
1886,
I
think
Raphael
tripped
over
it
for
the
security
releases
that
came
out
recently
and
I
think
maybe
16.
He
did
land
one
of
the
spr
changes
to
get
the
CIS
pass.
B
If
you
are
running
CI
on
1816,
there
may
be
some
test
failures
that
are
are
remarked
as
Blake's
Upstream
on
Windows.
It's
due
to
a
it
looks
like
it's
due
to
the
version
of
git.
That's
installed
on
the
machines
and
I'm
not
aware
that
there's
a
there
is
an
upscreen
bug
for
it,
but
I'm
not
aware
that
there's
an
actual
fix
or
even
an
idea
of
what's
caused
the
the
problem.
A
C
C
I
haven't
seen
crazy
eye
on
18
since
a
while
there's
two
specific
backboards
that
only
complains
about
like
the
two
tests
on
Windows
and
a
hundred
percent
of
after
runs,
fails
on
those
tests.
So
not
not
really
sure.
If
there's
something
wrong
with
the
improper
h.
B
The
windows
machines
updated
the
version
of
git
on
them
and
that
has
caused
the
problem
with
some
of
the
tests,
two
of
the
tests,
at
least
so
on
Main
those
tests
have
been
marked
as
Blakey
and
I
think
we
can
pull
those
connects
back
to
the
the
earlier
release
lines
just
to
Mark
those
tests
display
to
let
the
CI
pass
through
there's
nothing.
We
can
do
at
note
about
it.
B
It's
some
of
the
tests
are
executing
they're
piping
things
through
commands
that
come
with
Git
and
the
new
version
of
gifs
and
windows
is
broken
that
so
it's
not
really
anything.
We
can
effects
in
the
tests
it's
so
so.
For
the
moment
for
Maine,
we've
marked
the
testers.
Those
two
testers
blakie,
but
obviously
the
earlier
release
lines
don't
have
that
in
it
at
the
moment,
so
we
should
probably
pull
those
back
into
the
staging
branches,
so
the
CIS
can
at
least
pass
if
those
are
the
only
failures.
B
Well,
it's
not
a
breaking
change
in
the
release.
It's
the
the
machines
have
updated
their
version
of
git
and
the
new
version
of
git
has
broken
a
test
or
two
tests
in
node
to
do
with
piping
things
between
commands
and
node
itself.
So
it's
trying
to
test
some
sort
of
interoperability
between
node
and
other
Pro
other
subject
outside
of
node,
and
it's
the
thing
outside
of
node.
That's
changed.
That's
broken
the
tests
so.
A
and
I,
don't
think
we
have
anything
planned
right
like
this
is
just
it's
already:
maintenance
yeah.
It's.
B
Already
Enlightenment
so
I'm
not
so
aware
of
anything,
but
it's
currently
currently
being
asked,
but
maybe
I
think
there's
another
issue
that
you've
been
about
updating
the
time
zone
database.
True
true.
A
B
Think
we've
not
done
that
in
texting.
Right
now,
I
think
there's
two
options.
Well,
there's
three
options:
one
is
that
we
don't
do
anything.
B
One
of
the
options
is
that
we,
when
I
say
we
I'm
in
the
project,
not
necessarily
us
yeah
manually,
update
the
time
zone
database
in
whatever
version
of
ICU
is
in
node,
16.
I
think
it's
71,
but
that's
memory
it
might
be
earlier.
B
The
third
option
is
to
update
ICU
I'm
very
hesitant
to
update
ICU
in
node
16,
because
node
16
is
in
maintenance.
Icu
updates
do
change
the
formatting
of
Locale
specific
strings
and
ICU
do
not
consider
that
as
a
breaking
change,
because
ICU
considers
that
Locale
formatting
is
human,
readable,
not
machine
possible,
but
we've
seen
a
lot
of
people
complain
when
the
format
of
a
message
changes
because
they
have
like
snapshot
tests
or
other
tests
that
will
break
when
the
local
information
changes.
Equally,
we
have
had
people
say,
raise
issues
saying
hey.
B
This
Locale
is
incorrect
and
produces
the
wrong
output
if
you're
in
this
Locale
and
you
print
the
string.
So
the
solution
to
that
is
to
upgrade
device
for
you.
But
updating
ICU
is
obviously
then
going
to
bring
other
local
changes
that
other
people
blame
are
breaking,
but
I
see
you
don't
soon
to
them
is
breaking
but
I
think
at
least
one
of
them
like
there
was
a
non-breaking
space
change.
So
one
of
the
ICU
changes
changed
like
a
space
character
in
messages
to
a
non-breaking
space
character
and
V8
actually
patched
around
that.
B
B
If
we
drop
that
into
their
16
maintenance
that
may
be
disruptive,
it
may
not
be
so
I'm
a
bit
on
the
fence
about
updating
ICU.
If
we
updated
ICU
in
note
16,
that
would
automatically
get
us
to
the
latest
time
zone
database.
So.
B
Just
update
the
time
zone
information,
but
that
requires
a
manual
PR
to
to
sort
of
pull
the
time
zone
database
apart
from
ICU
and
repackage
the
ICU
data
file
and
for
which
there
is
a
contributing
dock
or
a
maintaining
dock.
That
had
to
do
that.
But
it
requires
someone
to
to
do
that
and
open
a
PR
or
yeah.
B
We
just
leave
it
as
it's
on
16
I,
don't
know
if
that's
wise,
but
yeah
I
mean
that's
what
we
always
16
so.
B
B
It
will
be
either
things
that
people
were
blackboarded
that
are
I,
guess
critical
fixes
you
know,
rather
than
the
sort
of
features
and
yeah
the
things
like
the
time
zone
database,
it's
kind
of
a
I
sort
of
class
it
as
a
dependency
update,
but
it's
one
of
those
things
where
we
either
have
to
update
the
whole
dependency
or
part
of
the
dependency
as
it
sort
of.
A
C
A
B
B
Months
yeah
but
I
don't
know
when,
because
I
don't
know
how
much
I
wouldn't.
A
A
A
A
Yeah
fix.
B
B
A
Let
me
try
but
Richard
yeah
I
know
if
you
can
leave
a
few
notes
on
this.
Okay,
in
this
conversation
in
the
in
the
minutes
about
particularly
the
whole.
A
Yeah
for
16,
let
me
let
me
know
and
yeah
so
otherwise,
I
think
that's
yeah,
that's
gonna,
be
it
for
today,
So
yeah!
Thank
you.
Thank
you
all
and
see
you
next
time.
Thanks
bye,
bye,.