►
From YouTube: London Infrastructure Readiness (Breakout #8)
Description
A
Okay,
hi
everybody
welcome
to
first
infrastructure
call.
We
have
yeah.
This
is
the
first
time
we
do
this
to
try
and
align
basically
the
different,
tooling
layers
and
infrastructure
layers
with
the
work
that
we're
doing
at
the
protocol
level.
Yeah
trent
has
some
set
this
up.
I
don't
know
if
you
want
to
give
a
quick
overview
trend
of
likes
yeah.
How
sure.
B
Yeah
sure
so
we
wanted
to
just
start
early,
and
we
know
that
there's
a
lot
of
complexities
with
ecosystem,
tooling
and
libraries
that
need
to
adapt
for
1559.
So
we
just
wanted
to
start
this
process
early
instead
of
having
everybody,
you
know,
try
to
figure
it
out
on
their
own,
so
this
call
will
be,
like
tim
said
in
experiment,
we're
trying
to
get
people
to
just
have
a
quick
synchronous
discussion
and
hopefully
we'll
iron
out
some
issues
together
and
come
to
consensus
on
what
things
should
be.
B
B
This
is
the
a
one-off
for
now
we're
not
planning
to
have
this
every
two
weeks
or
anything,
but
we'll
see
you
know
what
the
need
is
going
forward
after
this
call,
I
dropped
the
agenda
in
the
chat.
So,
if
you'd
like
to
see
that
it's
pretty
short,
so
we
have
a
lot
of
leeway
on
what
we
can
actually
discuss.
B
A
Yeah,
actually
I
I
guess
just
there
were
like
yeah
three
things
on
the
agenda,
so
there's
just
an
ipc
just
getting
general
updates
from
the
projects
which
we
can
probably
do
at
the
end
and
then
also
the
change
between
gas
target
and
gas
limit.
It
might
make
sense
to
start
by
the
last
one
just
because
this
is
one
that'll
change
kind
of
the
consensus
rules
and
we
want
to
make
sure
yeah,
that's
kind
of
agreed
upon.
A
B
Yeah,
I
was
just
gonna
say
you
reminded
me:
I
should
probably
mention
the
tracker,
so
the
the
other
component
to
this.
In
addition
to
the
call
to
this
london
readiness,
the
london
infraredist
initiative,
is
that
there's
a
tracker
that
we
put
together
so
similar
to
how
tim
tracks
the
clients
to
see
where
they
are
at
with
implementing
each
of
the
eips.
We're
also
experimenting
with
this
tracker
for
libraries
and
tooling.
A
But
as
we
were
implementing
that
and
testing
it,
we
realized
that
breaks
a
bunch
of
things,
and
so
there
was
a
proposal
this
week
to
kind
of
switch
that
to
instead
use
still
the
gas
limit
in
the
header.
But
that
means
that,
on
the
fork
block,
we
would
have
to
bump
the
gas
limit
2x.
So
it
would
basically
go
from
you
know:
50
million
to
30
million.
A
If
that's
the
numbers
were
at,
but
then
at
least
the
the
field
in
the
header
would
still
return
the
maximum
amount
of
gas
that
a
block
can
can
consume.
I
think
martin
or
peter
had
written
kind
of
the
formal
proposal
for
that
light.
Client
wrote
the
pr
to
the
to
the
eip,
so
I
don't
know
if
any
of
you
have
thoughts
on
it
or
anything.
You
wanted
to
add.
D
So
I
think
the
one
question
that's
outstanding,
for
that
is
miners.
When
they
set
up
to
configure
their
nodes,
they
can
figure
what
gas
limit
they're
going
to
target,
and
so
every
time
they
produce
block
they
bump
up
or
down
towards
their
gas
target.
If
a
miner
has
the
gas
limit
set
via
command
line
to
15
million,
all
of
a
sudden
as
soon
as
the
ip1559
lands,
they
will
start
pushing
the
gas
limit
down,
because
the
block
will
have
30
million
and
their
miner
is
configured
to
try
to
target
15
million.
D
So
we
have
a
couple
options
to
address
that
we
can
try
to
just
communicate
with
miners
and
tell
them
hey.
You
know
right
at
the
fork
block.
You
need
to
reconfigure
your
client
that
kind
of
sucks,
because
reconfiguring
your
client
right
at
a
fork
block
is
dangerous
and
hard
and
whatnot
we
can
just
accept
the
block
gas
limit
is
going
to
be
volatile
for
a
bit
around
the
fork
and
it
also
kind
of
sucks.
D
The
other
option
is
to
include
like
a
second
option
that
you
can
add,
which
says
you
know.
While
this
option
is
present,
gas
limit
is
actually
2x
what
I
set
after
the
1559
fork
block
and
the
last
one
is
we
can
make
it
so
that
command
line
option
does
something
different
than
it
says.
So
it
says
gas
gas
limit,
but
really
it's
the
gas
target.
D
All
these
have
disadvantages.
Of
course,
I'm
personally
partial
to
the
second
option
that
says:
hey
just
temporarily
2x
this
after
the
one,
five
five
nine
block
and
then
the
user
can
remove
that
and
it
can
be
deleted
from
guess
later.
But
that's
that's
the
current
thing
that
we
need
to
address
to
move
forward.
I
think-
and
I
guess
technically
we
don't
have
to
address
those,
so
each
client
can
address
it
separately,
since
I
think
almost
all
minors
run
guess
really.
This
is
a
guess.
E
I
personally
don't
really
like
these
magical
flags,
because,
first
up
we
need
to
implement
them.
Then
we
need
to
convince
everybody
to
use
them
and
then,
when
we
delete
them,
we
again
need
to
convince
everybody
to
meaningfully
reconfigure.
So
it's
I
mean
we.
We
either
way
need
miners
to
do
something
so
might
as
well.
Keep
it
simple
and
have
them
do
the
right
thing
from
the
get-go,
for
example.
A
So
I
can
definitely
try
and
communicate
with
miners
and
and
and
like
see
see
if,
if
they
think
that
makes
sense
how
I
guess
assuming
so
my
fear
is
not
that
minor
say
that
this
doesn't
make
sense.
But
it's
that
there's
not
really
an
answer,
so
we
don't
kind
of
hear
back
from
them.
Assuming
we
didn't
hear
back
from
miners
and
we
kind
of
don't
know
what
they'll
do.
Would
it
be
possible
to
add
this
yeah?
I
guess:
what's
the
latest,
we
could
add
kind
of
a
flag
like
this.
E
But
also
at
least
we
do
keep
in
touch
with
two
mining
pools,
or,
I
will
discuss
say,
keep
in
touch
what
we
every
couple
months.
We
maybe
just
exchange
a
message,
and
they
are
generally
I
mean
if
we
contact
them,
that
hey
there's
something
screwy
and
get
or
there's
something
that
you
need
to
take
care
of
that
you
should
respond.
E
E
A
F
A
Okay,
so
the
next
big
topic
was
basically
the
renaming
of
the
json
rpc
fields.
I
know
there
were
a
lot
of
different
threads
on
that,
so
there
was
the
eat
research
thread.
Originally,
then,
the
get
team
put
out
a
proposal
this
week
to
have
basically
shorter
names
and
and
try
to
match
the
current
terminology
with
gas
gas
limit
gas
used
and
what
not,
I'm
not
sure
exactly
where
to
start.
But
this
one
it
feels
like
there
were
various
different
threads
on
it.
A
E
F
E
It
is
super
important
to
signal
this
that
some
field
is
per
gas
and
not
not
a
total,
and
the
interesting
thing
was
that
the
spec
didn't
mention
at
all.
There
are
the
json
rpc
aspects,
so
the
the
1559
vip
focuses
fully
on
the
consensus
things
and
defining
the
variables
and
constants
and
algorithms
and
whatnot,
but
it
absolutely
no
mention
on
whatsoever
on
how
these
things
will
be
named
for
the
user
and
and
essentially
that's.
E
That
was
the
reason
why
we
wanted
to
bring
it
up,
because
when
implementing
it,
it
needs
to
be
surfaced
out
of
the
user.
Obviously,
it
needs
to
be
in
consensus
across
different
clients,
because
every
wallet
and
everything
needs
to
implement
this
and
and
then
the
question
is
how
do
we
name
these
fields?
If
we
were
to
go
with
just
inherently
what's
in
the
eip,
then
these
fields
would
be
named
max
fee
per
gas
and
max
priority
fifa
gas.
E
E
These
are
fields
that
the
currently
the
api
sends
and
receives,
and
then
it
will
be
weird
that
okay,
we
have
gas
price
and
we
have
max
priority
fee
for
gas,
which
is
essentially
almost
the
same
thing,
and
then
our
suggestion
was
to
simply
call
the
tip.
I
mean
call
it
this
priority
fee.
We
can
call
it
gas
tip
cap
or
anything
if
somebody
has
a
better
idea
and
for
the
for
the
base
fee,
which
is
actually
paid
by.
E
I
mean
the
total
that
the
gas
that
the
transaction
campus,
who
previously
got
gas
priced
and
that
would
be
kind
of
renamed
to
gas
fee
cap.
So
it's
it's
just
a
slightly
shorter
version.
You
could
also
call
it
max
paper,
gas
or,
but
that
doesn't
really
fit
in
with
the
rest
of
the
variable
naming,
and
that
is
why
we
kind
of
suggested
gas,
speaker
and
yeah.
The
tip
was
just
something
similar
to
the
gas
sticker,
but
all
in
all
the
reason
why
you
kind
of
brought
it
up.
A
A
E
D
G
Sorry,
apologies
mika
yeah.
I
I
think
from
our
perspective,
in
terms
of
when
it
comes
to
implementing
the
json
rpc
calls
it's
it's
certainly
easier.
If
everything's
in
one
place,
I
you
know,
we
didn't
say
the
the
original
eip.
You
have
an
explicit
clause
that
calls
out
the
json
rpc
changes.
The
risk,
of
course,
with
having
separate
json
rpc
eips,
is
that
then
you've
got
to
link
from
the
ones
that
affect
the
clients
back
to
them,
and
then
they
might
not
stay
in
sync.
G
A
E
You
know
so
personally,
I
would
be
happy
if
there
was
a
single
paragraph
saying
that
these
two
fields
should
be
exposed
as
such
as
such
on
the
apis
and
that's
fine,
okay.
So,
basically,
so
it
doesn't
need
to
be
some
conclusive
spread.
The
idea
is
to
just
give
a
hint
on
so
that
every
client
is
on
the
same
page
on
the
naming
convention.
A
E
J
There
was
one
other
question
that
was
being
discussed.
I
think,
which
was
so
you
you
do
have
these
two
fields
of
the
gas
cap
and
the
tip
that
the
sender
specifies
and
there's
a
question
of
whether
the
json
rpcs
would
expose
the
actual
values
chosen
like
the
actual
fee
paid
and
the
the
actual
tip
paid
or
whether
it
would
be
up
to
clients
to
calculate
them
themselves.
E
So
I
guess
this
is
similar
to
to
the
gas
use
used
and
gas
limit
for
transactions.
So,
for
example,
if
you
retrieve
a
transaction,
then
the
gas
limit
is
not
the
amount
of
gas
that
was
actually
used,
but
it's
the
amount
of
gas
the
user
specified
and
I
think
you
need
to
actually
retrieve
the
receipts
to
get
the
true
gas
usage.
D
So
the
five
1559
actually
originally
had
receipt
changes.
If
I
remember
correctly,
and
then
I
think
we
took
them
out
because
we
didn't
want
to
include
derived
data
in
the
receipt.
That
being
said,
we
can
return
additional
information
in
the
json
rpc
receipt
request
beyond,
what's
actually
in
the
receipt,
and
I
think
we
already
do
that.
E
Yeah,
I
mean,
of
course
that's
I
I
didn't
mean
to
change
the
consensus
field
because
these
obviously
can
be
just
calculated.
So
when
you
retrieve
the
receipt
you
know
which
block
it
was
in,
so
you
have
the
base
key
and
then,
if
you
have
the
base
key
and
have
the
the
these
limits
set
by
the
transaction,
you
can
just
specify
the
bit
that
was
used.
So
you
don't
need
to
store
anything.
It's
just
about
exposing
it.
D
E
E
But
I
think
this
so
the
legitimate
question
is:
are
callers
expected
to
have
access
to
this?
I
would
say:
probably
yes,
because,
for
example,
if
you
just
look
up
your
transactional
interest-
and
you
probably
want
to
know
how
much
you
paid
for
it
so
yeah,
I
think
people
would
expect
this
to
be
available
somewhere.
A
Quite
a
bit
okay,
so
I
think
if
we
can
expose
it,
we
should
at
the
client
level
and
so
okay
and
then
there's
a
couple
comments
in
the
spec
about
that
where
the
spec
should
live.
Saying
you
know
having
a
full
diff
would
be
good.
Maybe
if
that's
something
we
want
to
start
the
new
kind
of
json
rpc
repo
with
that
that
would
be
valuable,
so
I
think
for
sure
we
can
commit.
You
know
to
adding
the
the
fields,
the
the
actual
new
fields
in
the
1559
specs.
D
This
gets
into
I'm
trying
to
avoid
bringing
this
up,
but
this
conversation
is
rapidly
driving
us
towards
this
there's,
currently
a
dis
disagreement
on
what
should
be
in
the
ips
repo
and
it's
kind
of
coming
to
a
head
of
notice.
In
the
last
couple
of
weeks,
we're
seeing
a
lot
more
clashing
between
the
editors
and
authors,
I'm
hoping
we
don't
need
to
resolve
that
before
london
and
so
it'd
be
nice.
D
J
D
Rapidly
bleeding
away
from
here's
the
consensus
changes,
everything
you
need
to
know
for
a
consensus.
Client
is
right
here
into
oh
and
also
you
know.
This
is
the
command
line,
parameters
that
we
use
in
geth
and
here's
what
parity
does
and
then
like.
This
is
a
big
can
of
worms
that
we
need
to
solve.
I
just
I
I
don't
want
to
get
too
distracted
by
that
if
we
can
avoid
it
as
all
so,
I
think.
A
E
Yeah,
so
I
just
want
to
say
that,
from
my
perspective,
it's
totally
fine
to
just
have
a
link
that
from
1559
link
to
eipd
whatever,
which
defines
all
this
information.
But
my
point
really
is
that
we
are
currently
entering
the
point
where
we
want
to
have
a
test.
That's
where
all
clients
talk
to
each
other,
and
I
mean
if
you
want
to
test
that
it
would
be
nice
if
clients
would
also
share
the
same
apis.
So
I
mean,
if
somebody
wants
to
do
it
over
the
weekend
great.
E
D
A
I
think
yeah
at
least
if
the
fields
are
there,
then
we
know
all
the
clients
will
return
like
yeah.
You
know
the
same
value
in
in
their
in
their
implementation
and
that's
probably
pretty
valuable.
With
regards
to
like
the
full
json
rpc
diffs,
you
know
that's
something
we
we
definitely
should
not
put
all
in
1559
and
we
can
either
open.
You
know
new
weeps,
like
we
had
already
done
for
the
base
fee
diffs
on
the
blocks,
or
we
can
add
that
directly
in
the
eth1
specs
repo.
K
K
E
E
And
if
you
specify
the
gas
price,
then
it
will
be
interpreted
as
a
legacy
transaction
where
the
gas
price
will
be
used
as
both
the
maximum
fee
primitives
to
be
paid
by
transaction
and
also
the
maximum
tip.
So
it's
essentially
there's
a
little
trick
in
1559
so
that
all
all
currently
existing
tooling
will
continue
to
function
perfectly
without
needing
an
upgrade
whatsoever.
F
E
F
E
L
Quick
question:
since
we
are
introducing
different
types
well,
it
was
introduced
in
the
previous
release,
different
types
of
transactions,
and
we
is
putting
now
transaction
to
type
two.
Are
there
any
plans
or
are
we
thinking?
This
is
a
good
time
to
put
you
know,
to
enable
having
the
capability
to
have
transaction
type
three,
and
so
mainly,
we
all
the
json
rpcs
to
be
able
to
be
able
to
return
the
transaction
type
and
all
the
information
in
a
generic
way
so
later
on.
L
When
we
decide
to
change
something
else,
and
will
it
make
it
much
easier
so
that
way,
all
the
tooling
that
we
are
creating,
maybe
like
recovering
signatures
or
whatever,
building,
rlps
and
and
and
so
on,
using
the
json
rpc
information.
What
allows
us
to
yeah
just
plug
in
other
types
of
transactions
as
well
and
yeah,
but
the
in
the
chats.
I
think
they
are
the
rpc
returns
transaction
type
yeah,
but
we're
going
to
introduce
more
fields
and
more
information.
L
D
Your
answers,
but
so
I
think
what
juan
is
getting
at
here
is
the
we
have
a
new
transaction
type
and
it
looks
very
similar
to
the
previous
transaction
types
mode.
Access
list
looked
very
similar
to
legacy
transactions,
and
so
so
far
we've
been
able
to
get
away
with
just
kind
of
adding
fields
here
and
there.
But
as
we
get
more
transaction
types
in
the
future,
it's
very
likely
they're
going
to
diverge
more
and
more,
and
so,
rather
than
trying
to
just
kind
of
keep
hacking
little
bits
and
pieces
on
at
some
point.
D
We're
gonna
need
to
make
a
transition
to
you
know.
Transactions
can
be
very
different
and
we
need
like
an
envelope
or
some
some
mechanism
for
dealing
with
transactions
that
are
widely
divergent,
like
maybe
using
different
signature
types.
Different
encoding
types
stuff
like
that,
and
so
is
now
the
right
time
to
make
that
cut
over
to
having
some
sort
of
enveloping
system
or
some
sort
of
typing
system.
D
C
E
I
don't
really
want
to
solve
this
problem.
Rather,
I
don't
think
we
know
what
we
want
to
envelope
properly.
So
as
long
as
the
transactions
are
kind
of
almost
the
same,
it's
super
hard
to
create
an
abstract
envelope
that
will
properly
really
be
useful,
so
I
would
suggest
let's
wait
until
we
have
a
transaction
type.
That's
that
really.
A
So
I
think
that's
like
mostly
what
we
had
already
on
the
agenda.
I
guess
the
one
thing
we
still
haven't
figured
out
is:
where
do
we
track
the
full
json
rpc
diffs?
That
is
kind
of
a
can
of
worms
so
yeah?
I
I
want
to
see.
Is
there
anything
else
that,
like
especially
from
the
tool
in
your
infrastructure
side,
you
all
wanted
to
bring
up,
and
I
think
that's
kind
of
higher
priority
to
discuss
on
the
call
and
we
can
figure
out
the
yeah,
the
json
rpc
elsewhere,
yeah.
I
D
D
The
only
thing
will
change
like:
if
a
tool
doesn't
do
anything,
then
it
just
means
you
will
not
be
able
to
properly
kind
of
parse
and
handle
new
transactions
that
show
up
in
a
block.
So
otherwise
you
can
still
function
fully,
so
you
can
send
in
the
legacy
transaction.
You
can
get
it,
it's
get
it
by
transaction
hash.
You
can
get
its
receipt
and
all
those
things
will
look
the
same
for
you,
so
so
really
from
a
tooling
standpoint.
I
don't
think
there's
anything
that
absolutely
must
be
changed
with
london.
D
D
So
far,
we've
been
able
to
always
maintain
like
legacy
transactions
continue
to
work,
and
I
don't
think
we
have
anything
on
the
docket
for
the
future
that
will
cause
legacy
transactions
to
stop
working.
All
the
new
transaction
types
that
have
been
talked
about
and
proposed
are
additives
it'll
be
a
new
type
of
transaction
which
you
will
be
able
to
send
in
addition
like
or
alternatively,
to
the
legacy
transactions,
but
the
legacy
transactions
will
still
work.
Does
that
answer
your
question
or
do
they
misunderstand.
I
D
See
so
I
think
this
is
what
peter
is
getting
at.
Is
that
we're
not
quite
sure
enough
on
what
future
transactions
will
look
like
to
know
whether
they're
all
going
to
have
the
same,
like
gas
limit,
mechanics
or
not
like,
for
example,
account
abstraction
changes,
a
lot
of
assumptions
and
some
of
those
assumptions
may
change
kind
of
how
gas
works,
maybe
in
a
future
transaction.
E
E
There
will
be
a
push
to
phase
out
these
fantastic
transactions
and
by
these
legacy
transactions,
meaning
that
from
1559
onward,
both
the
current
privacy
transactions
and
also
non-1559
access
transactions
would
probably
be
phased
out
eventually.
So
there's
not
really
no
reason
to
keep
that
complexity
forever,
but
yeah,
that's
probably
not
in
the
next
couple.
E
A
A
M
M
N
A
M
But
I
thought
here
we
should
get
a
bit
of
consensus
on
this,
because
otherwise,
if
you
use
this
web
3
stuff-
and
you
want
to
send
these
transactions
that
you
can
do
with
because
some
clients
might
force
you
to
send
rop
encoded
so
dope,
basically
doubly
rp
encoded
transactions
over
rpc
and
other
clients
would
not,
but
I
think
like
how
bisho
solved
it
at
this
point
is
like
very
nice
and
they
can
agree
later
like
what
the
actual
consensus
should
be.
So
that's
that's
fine,
too
yeah.
E
F
B
Tim
stepped
away
for
a
second,
but
I
just
want
to
give
a
quick
plug
for
the
ether
r
d
discord.
If
you
haven't
joined
there,
that's
where
a
lot
of
this
discussion
is
happening
through
a
couple,
different
channels,
there's
one
specifically
related
to
1559
and
then
there's
you
know
the
general
awkwardness
channel.
So,
if
you're
not
already
in
there,
I
would
strongly
encourage
you
to
at
least
check
it
once
a
week
and
get
up
to
speed
on
on
where
discussions
are
heading.
B
A
A
But
if
you
do
have
the
skills-
and
you
know
money
is
the
bigger
issue-
please
pay
me
and
we
can
definitely
get
this
going
yeah
and
and
ideally,
if
it
was
somebody
that's
kind
of
adjacent
to
the
client
devs.
I
think
that
would
help
because
there's
a
ton
of
work
to
do
on
the
actual
consensus
bits
before
london.
A
So
I
suspect,
if
we
rely
on
like
geth
or
nethermind
or
baysu,
we
might
not
get
the
specs
in
time
so
I'll
be
both
reaching
out
to
folks
and
accepting
inbound
for
anyone
who
wants
to
help
try
to
inspect
the
json
rpc
diff.
We
can
probably
get
somebody.
You
know
one
of
the
core
devs
to
just
add
the
quick
paragraph
to
1559
about
the
parameter
naming
and
then
whoever
works
on
the
diff.
A
A
Fork
timelines
comment
from
eg
the
challenge
this
time
around
is
the
difficulty
bomb,
so
we
don't
really
have
a
ton
of
leeway
with
regards
to
the
fork
timeline,
at
least
for
mainnet.
You
know
test
nets
can
come
basically
whenever
before
maintenance,
but
mid-july
is
kind
of
when
we
have
to
fork
on
mainnet.
A
So
this
is
kind
of
the
main
constraint
here
and
realistically
we
probably
want
you
know
the
last
kind
of
tested
fork
to
be
at
least
two
three
weeks
before
that.
So
if
you
have
like
late
june
for
the
last
test
net
fork
yeah,
I
have
an
actual
dock
with
with
dates,
but
I
think
it
was
like
yeah
july
14th
was
mainnet
july.
Let
me
let
me
try
to
find
the
timing
dot
july
14th
was
main
net
june.
30Th
was
the
last
test
net.
A
F
F
C
N
D
D
D
C
I
think
everybody
right
now
is
is
setting
the
bait
the
default,
the
initial
base
fee
at
the
fork
block,
and
I
think
the
spec
technically
says
that
you
should
treat
blocks
before
the
fork
block
to
have
the
initial
base
fee.
So
technically,
on
the
fork
block,
we
should
have
calculated
a
base
fee,
but
at
the
moment
all
clients
just
use
default
base
fee.
For
that.
D
A
C
C
E
A
Okay,
thanks
cool
and
we're
at
time,
but
I
just
had
a
final
question
about
baikal.
It
seemed
in
the
chat
that
basu
had
one
eight
missing
open.
Ethereum
was
missing
refunds
that
their
mind
was
missing
refunds.
Does
that
mean
people
have
the
utter
eep,
which
was
3541
like
the
basically
disabling,
the
contracts
being
deployed
with
the
starting
byte
code.
Q
O
A
B
I
don't
wanna,
I
don't
wanna
keep
people
too
long
yeah.
I
just
wanted
wanted
to
say
really
quick.
So
this
this
call
itself
was
seems
it
was
pretty
in-depth
or
in
the
weeds
on
jason
rpc
stuff.
So
thank
you,
for
you
know
libraries
who
libraries
and
tooling
that
joined
and
maybe
didn't
have
a
direct
contribution,
but
it's
probably
still
valuable
to
listen
in
and
see
where
these
changes
are
headed
in
the
future.
B
We'll
probably
have
more
of
a
stand-up
type
thing
where
clients
and
and
libraries
can
just
give
their
brief
updates.
So
apologies
if
we
didn't
get
to
that
part,
but
in
the
future
we
could
probably
arrange
something
more
like
that,
and
then
that
leads
to
the
next
question,
which
is
when
or
if
should
should,
should
we
have
a
next
call.
B
A
B
A
A
Yeah,
I
guess
my
preferred
option
would
be
see
on
all
core
devs
next
week,
where
we're
at
and
if
we
feel
like
this
is
necessary.
I
think
in
the
meantime,
you
know,
if
folks
have
like
specific
issues
or
concerns
that
come
up,
raising
them
either
on
the
discord
or
on
each
magicians
is
pretty
good
and
we
can
kind
of
you
know.
B
Awesome,
yeah
and
then
I'll
just
point
everybody
back
to
that
tracker.
So
if,
if
you
do
have
an
update
or
work
that
started,
I
know
things
are
a
little
still
up
in
the
air,
but
once
you
do
start
that
work
like
the
javascript
team
has,
I
know
they've
started
some
things,
just
pull
a
pr
to
that
and
or
dm
me,
and
I
can
update
it
for
you.
That
would
be
a
great
help.