►
From YouTube: Ethereum Core Devs Meeting #111 [2021-04-23]
Description
A
A
A
A
So
I
can
just
run
through
that
very
quick
to
hopefully
frame
the
conversation,
because
there
was
a
lot
of
things
where
everybody
was
in
agreement
on
the
first
of
which
is
basically
everyone
said
they
would
rather
see
a
smaller
sized
london
rather
than
kind
of
a
larger
one.
The
only
team
that
wasn't
you
know
100
in
favor
of
a
smaller
london
basically
was
in
favor
of
just
less
upgrades
in
general.
So
I
think
you
know
they.
They
don't
necessarily
want
a
much
larger
london.
A
With
regards
to
the
timeline
for
the
upgrades,
so
I
had
proposed
like
two
timelines,
one
where
we
forked
my
net
around
mid
july,
one
where
we
fork
around
mid-august.
Two
teams
said
they
would
prefer
the
mid-july
one
one
for
signing
the
difficulty
bomb,
so
around
mid-july.
I
think
the
difficulty
bomb
should
be
off
to
the
extent
that
blocks
are
about
two
percent
larger
and
then
around
mid-august.
A
I
guess
thing
that
came
up
is
obviously
if
we
keep
london,
small
in
scope,
there's
a
bunch
of
other
eips
that
people
have
brought
up
have
discussed
that
they'd
like
to
see
on
mainnet
and
given
the
focus
on
the
merge,
there
was
a
fear
that
maybe,
if
we,
if
we
keep
london
small,
then
we
won't
see
those
eips
on
mainnet
for
at
least
another
year.
So
I
asked
all
of
the
team.
A
B
C
A
Okay,
okay,
good
and
let
me
just
check
the
comments
on
youtube.
Okay,
no,
weird
comments
on
youtube,
so
I
think
we're
good
okay,
so
yeah!
So
sorry
I
was
saying
yeah.
So
if
we,
if
we
keep
london
small,
obviously
there's
a
bunch
of
eeps
that
won't
make
it
in
so
I
asked
the
teams
if
we
could
work
on
another
kind
of
feature
upgrade
in
parallel
to
the
merge
and
whether
that
would
delay
the
merge
or
not.
It
seemed
like
it
for
most
teams.
A
It
wouldn't
kind
of
like
we're
doing
right
now,
where
we
had
berlin
and
london
in
parallel,
then
right
now
we're
gonna
have
london
in
the
merge
and
once
london
is
out,
then
potentially
we
could
have.
You
know
the
merge
and
shanghai
in
parallel.
There
wasn't
like
a
hundred
percent
certainty
on
this,
though,
and
you
know,
people
said
that
realism
would
help
figure
out
how
how
possible
this
is,
but
it's
definitely
an
option
that
we
can
explore
and
then
yeah
regarding
the
specific
eips.
So
there
were
four.
We
talked
about
eip2677.
A
A
If
we
were
to
do
that,
then
then
it
would
probably
kind
of
grow
the
scope
for
london
significantly
and
we
could
either
you
know
either.
We
could
include
it
in
london,
as
is
without
changing
the
libraries
with
the
implementation
that
clients
have
or
we
could.
If
we
wanted
to
do
those
changes,
it's
something
we
could
prioritize
shortly
after
and
even
if
there
wasn't
another
feature
fork
some
people
mentioned.
We
could
maybe
do
this
at
the
same
time
as
the
merge.
If
there
was
a
strong
desire
for
it.
A
Third,
one
was
3403,
so
I
think
this
one
and
the
last
one
were
the
two
most
discussed
but
3403.
Basically,
no
one
opposed
to
it.
If
we
think
it
will
help
the
network
security
alongside
1559,
but
at
the
same
time
you
know
it
felt
like
a
solution
where
a
lot
of
people
had
quibbles
with
it.
So
some
people
thought
it
added
too
many
edge
cases
and
it
should
just
go
ahead
and
we
should
just
go
ahead
and
remove
all
the
refunds
all
together.
A
Like
the
original
proposal,
other
people
said
we
should
kind
of
come
up
with
a
more
elegant
mechanism
and
and
and
kind
of
have
a
broader
overhaul,
and
that
would
obviously
take
much
more
time
and
couldn't
be
included
in
london.
It
didn't
seem,
like
anybody's
kind
of
quibbles,
were
strong
enough
to
block
it.
If
we
think
that
you
know
this
is
valuable
to
have
in
london,
but
it's
definitely
something
we
should
discuss
and
then
the
last
one
was
3074..
A
So
I
think
there
you
know
some
teams
were
strongly
in
favor.
Some
teams
were
opposed.
I
think
even
the
teams
in
favor
said
that
it
seemed
like
something
big
and
somewhat
contentious
to
include
in
london,
especially
on
a
short
timeline.
So
this
is
definitely
something
that,
like
would
be
worth
building
another
feature
fork
around
and
the
teams
that
were
kind
of
opposed
to
it.
A
The
two
main
things
were:
you
know
wanting
to
have
like
a
security
audit
which
is
already
in
progress
and
also
just
wanting
to
have
more
time
for
the
community
to
digest
it
and
kind
of
get
comfortable
with
the
changes
and
whatnot.
So
that's
kind
of
the
summary
there
I'll
stop
here.
I
don't
know
if
people
have
comments,
thoughts,
questions
about
this
martin,
I
see
your
hand,
is
up.
D
Yes,
I
would
like
to
just
make
a
brief
update
about
3403.
I
don't
know
if
I
should
do
it
now
or
later.
Yes,
so
we
have
this
peeping
call
me
and
italic
and
discuss
it
a
bit,
and
there
were
questions
and
after
that,
vitale
came
up
with
an
alternative
scheme
which
yeah
we're
iterating
on
a
bit
now,
but
the
basic
idea
is
just
lower.
Well,
it's
three
parts
lower
one
of
the
constants,
the
story
as
to
reset
gas
from
15
000
to
4
800.
D
By
doing
so
well,
that's
one
change.
Another
change
is
to
remove
the
refunds
from
self-destruct
and
the
third
change
is
to
reduce
the
so
right.
Now,
there's
maximum
there's
a
cap
on
the
refund,
you
can
only
get
refunded
half
the
gas
tube
consumed
that
would
be
lower
to
one-fifth,
so
the
first
the
change
to
to
delete
to
remove
the
refund
for
self-destruct.
This
is
self-explanatory.
D
But
if
you
are
truly
reading,
I
mean,
if
you're,
using
an
actual
story
slot
which,
which
you
are
reading
a
value
from
which
is
useful
to
you
in
your
in
your
computation
and
then
you
set
it
to
zero
because
you
no
longer
need
it.
Then
you
do
get
the
refund
because
you
paid
the
access
cost.
When
you
read
it
and
made
use
of
it.
D
And
the
third
change
to
would
simply
reduce
the
block
elasticity
so
that
you
can't
have
this
two
times
two
factor
of
what's
actually
being
executed
in
10
million
gas,
but
it
will
be
lowered
a
lot
making
the
execution
per
a
gas
in
a
block,
more
deterministic
yeah.
So-
and
I
think
one
one
benefit
of
this
version
of
the
the
refunds
would
be
that
well
for
one.
D
A
E
D
E
E
A
A
We
have
one
next
week
and
then
we
have
one,
that's
basically
mid-may,
so
I
I
feel
like.
If
we
want
to
have
this
in
london,
we
basically
just
need
to
agree
to
it
on
the
next
call.
So
if
you
know,
if
martin
you
can
have
an
e-belt
early
next
week,
then
it
gives
kind
of
the
rest
of
the
week
for
people
to
chat
about
it,
and
we
can
probably
make
a
decision
about
it
on
the
next
call.
A
Sweet,
so
I
guess
yeah
we'll
come
back
to
basically
the
refunds
on
the
next
call.
Aside
from
that,
so
you
know
for
the
three
out
of
eep,
so
26
77
25
37,
30
74.,
it
did
seem,
like
you
know,
the
the
rough
consensus
when
I
talked
to
the
clients
one-on-one
was
to
keep
them
out
of
london
to
keep
the
scope
small.
Does
any
everyone
kind
of
agree
with
that?
Does
anyone
have
a
strong
opinion
against.
F
Hey
go
ahead,
so,
yes,
I
just
had
one
question.
I
I'm
just
curious.
You
know
for
25
37.
If
there's
anything
that
you
know,
sort
of
the
core
dabs
would
like
to
see
with
that.
So
you
know
is:
is
the
plan
to
use
blast
and
if
not,
you
know
the?
I
think
there
were
some
very,
very
minimal.
Like
you
know,
gas
price
changes
like
a
couple
constants.
F
A
F
My
understanding
is
the
gas
price
changes
that
were
suggested
by
alex
were
not
they
were
they
weren't
based
off
of
blast,
so
they're
based
off
the
current
library,
it's
possible
that
they
may
be
a
a
new
release
of
that
existing
library.
But
you
know
it's
not
an
entirely
new
library,
so
I
just
wanted
to
maybe
clarify
that
the
gas
price
reductions
that
were
suggested
were
suggested
for
the
existing
library,
not
not
with
a
library
switch.
F
D
B
If
clients
are
happy
with
the
current
gas
costing,
we
can
always
in
theory,
release
bls
with
the
higher
gas
costs
and
then
at
a
later,
four
could
reduce
it
like
once,
bls
is
on
chain.
It's
pretty
easy
for
us
to
adjust
gas
costs
as
needed
to
reduce
them.
If
we
find
enough
data
that
shows
they
should
be
reduced
or
increase
them
if
we're
seeing
notice
a
denominator
attack
vector.
B
D
Yeah-
and
I
I
think
it
seems
like
a
pretty
good
approach
in
general
to
when
we
introduce
a
computational
intensive
pre-compile
to
be
moderate.
You
know
be
conservative
about
the
gas
at
first
and
then,
as
we
see
deployed
on
machines
and
people,
various
people
who
can
run
test
and
see
yeah
experiment
with
it.
Then
we
can
lower
it
like
we
did
with
the
modex
kelly.
F
A
And
just
one
thing
I
you
know
would
want
to
make
sure
I
know
I
think,
a
while
ago,
when
I
talked
to
open
ethereum
about
this,
you
all
said:
if
you
wanted
to
do
2537,
it
would
require
kind
of
an
audit
or
something
like
that.
So
yeah,
I'm
just
curious
to
hear
from
open
ethereum
about
how
that
would
work
in
your
your
roadmap.
How
realistic
you
think
something
like
that
is
for
london,
assuming
there
was
no
changes
to
the
the
current
specification.
H
B
G
Good
go
ahead
to
say
with
evm3d4
we
were
within
2x
last
time
I
mentioned
it,
so
we
had
a
bunch
of
breakthroughs
and
now
I'm
even
better
doing
even
better
than
2x.
This
is
runtime
and
gas
and
to
blast
to
the
speed
record,
and
so
worst
case.
If
you
know,
if
something
doesn't
happen
or
something
doesn't
work
out,
you
know
we're
looking
at
less
than
2x
slowdown.
If
we
just
do
it
with
evm384,
that's
it.
A
Got
it
thanks
for
sharing,
so
I
guess
you
know
it
seems
from
like
what
I'm
hearing
now
that
people
are
mostly
fine
with
bls,
but
I
do
recall
yeah
when
I
was
talking
with
the
client
teams.
Everybody
wanted
to
keep
kind
of
a
small
scope
for
london,
so
I
don't
have
to
implement
it.
I
don't
have
a
strong
opinion
here,
but
yeah.
What
are
people's
thoughts
about?
A
C
B
A
And
I
guess
that
makes
a
lot
of
sense.
The
challenge
people
had
with
determining
if
we
would
do
a
feature
fork
after
is
the
uncertainty
with
regards
to
the
work
from
the
merge,
because
we
so
even
though
the
interface
in
the
merge
you
know
is
pretty
straightforward,
some
client
teams
mentioned
they
might
have
to
do
like
performance,
work
and
stuff
to
just
get
it
working.
But
yes,
if,
if
people
I
don't
know
if
people
think
we
can
do
another
feature
fork
in
parallel
to
the
merge
that
obviously
changes.
A
D
A
E
Because
then
I
mean
the
delay
between
that
fork
and
the
the
merch
would
of
course
be
at
least
be
another
three
months,
because
it's
like
an
especially
like
big
big
fork,
of
course,
and-
and
so
I
do
think-
that
this
kind
of
implicitly
breaks
with
with
this
assumption
that
it
wouldn't
impact
emerge
at
least
while
merged
this
year,
would
still
be
possible
on
its
own.
And
so
I
was
just
wondering
like.
E
Is
there
any
room
like,
as
you
were
saying?
Historically,
it
might
might
take
about
three
months
for
the
next
focus,
or
something
like
that
as
like.
Is
there
any
chance
that
a
future
folk
in
even
something
like
september
would
still
be
some
like
possible,
because
I
think
implementation
wise,
if
it's
really
just
something
like
bls
plus
3074,
something
like
that
both
of
those
I
think
I'm
always
already
implemented.
So
the
question
is
like
how
much
effort
is
it
really
and
what's
like?
E
A
So,
there's
a
couple
comments
in
the
in
the
chat.
You
know
saying
that
an
october
feature
fork
takes
into
consideration
working
on
the
merge
in
parallel
and
that
doing
it
any
sooner
than
that
would
mean
we
can
only
ship
stuff,
that's
already
implemented,
basically
so
maybe
25
37,
but
not
like
30
74.
A
I
Yeah
I'll
just
echo
what
I'm
gonna
say
I
mean
that's
why
I
asked
if
this
is
a
one,
a
one
and
a
half
month
or
three
months.
You
know,
what's
the
delay
between
forkster,
because
then,
if
you
have
a
fork
late
october
or
november,
I
will
echo
what
andrea
said
and
that
the
coordination
overhead
of,
even
if
something
is,
is
completed
and
ready
of
doing
another
upgrade
the
merge
within
like
plus
or
minus
a
month
from
that
becomes
ambitious
at.
A
A
You
know
the
inclusion
of
something
like
25
37
before
the
merge
right,
because
I
think
if
we
start,
if
we
add
basically
more
features
to
london
beyond
1559,
which
everybody
says
is
kind
of
one
of
a
very
large
feature
already,
then
we
we
likely
are
gonna
delay,
london
and
that
means
for
sure
there's
not
the
opportunity
of
another
fort,
and
so
we
basically
have
to
make.
You
know
london
as
big
as
possible
and
that's
something
that
you
know
most
client
teams
seem
to
not
want.
A
On
the
other
hand,
if
we
keep
london
small,
we
can't
like
guarantee
that
there
will
be
a
feature
fork
now,
because
we
don't
have
enough
information
about
how
it
would
impact
the
merge
and
and
whatnot.
But,
as
that's
being
you
know,
worked
on,
there's
definitely
stuff.
We
can
move
forward.
So
you
know
all
this
conversation
around
bls
seems
like
it.
A
So
that's
also
something
that's
worth
considering
like
right.
Now,
all
the
teams
are
kind
of
focused
on
london
and
the
merge
in
parallel,
and
so
we,
if
we
had
another
feature
fork,
we
would
focus
on.
You
know
shanghai
and
the
merge,
and
then
it's
just
a
question
of
like.
Can
the
timelines
work
right
so
yeah?
Oh
gary
micah,
you
have
your
hands.
B
Thanks
yeah
in
a
similar,
similar
camp,
I
think
that
it
feels
to
me,
based
on
the
conversations
here
and
the
status
of
the
merge,
that
we
should
go
with
skinny
london,
because
that
won't
offend
anybody.
Everybody
seems
on
board
with
it
and
plan
for
a
follow-up
merge
in
october
and
then,
if
it
turns
out
that
the
merge
is
being
held
up
by
that
we
can
pivot
like.
So
if,
if
we
sorry
follow-up
fork,
if,
if
we
find
out
from
rayonism
that
oh
the
merger
is
really
easy,
we
can
do
it
right
now.
B
Then
we'll
we
can
drop
the
october
fork
and
do
the
merge
if
we
find
out
from
rainism.
Oh
there's
a
lot
of
gotchas
that
we
didn't
think
about.
This
is
going
to
take
a
while,
then
we're
already
on
track
for
an
october
fork
and
everybody's
happy
with
that
as
well.
So
I
just
I'm
worried
about
planning
for
the
merge
when
we
still
are
lacking
information,
I
feel
like
we
should
plan
for
the
information
we
have
and
then
be
prepared
to
pivot.
If
we
get
new
information.
K
A
Yes-
and
I
I
think
the
two
things
we
probably
want
to
be
mindful
of
is
like
yeah
having
a
quick
date,
and
that
means
having
a
small
scope.
So
it
seems
you
know
like
just
over
the
past
few
weeks.
The
two
kind
of
big
eeps
that
people
really
want
to
see,
but
that
clearly
are
hard
to
fit
into
london
are
25
37
and
30
74..
A
I
think
if
we
want
to
have,
you
know
a
fork,
that's
quickly
after
london
and
that
doesn't
delay
the
merge
as
much.
We
basically
have
to
accept
that
these
are
the
two
big
eaves
we'll
put
in
like
if
we
have
another
huge
feature
coming
in.
Obviously
that
delays
the
whole
thing
and
and
not
only
the
implementation,
but
just
like
the
time
to
agree
on
that.
So
I
think
yeah.
B
I
think
that's
generally,
a
good
plan
for
all
of
our
feature.
Forks
is
that
we
kind
of
try
to
get
a
rough
consensus
on
what's
going
in
it
as
much
in
advance
as
possible
unless
we're
gonna
go
with
the
exact
opposite
plan
of
work
on
things
until
they're
done
and
then
just
put
them
in
the
next
fork.
But
it
sounds
like
that's
lost
favor
lately,.
E
So
even
if
there
was
only
a
slight
delay
or
something
the
order
would
just
be
flipped,
and
so
basically
the
merge
will
just
be
done
like
it
will
just
be
executed
once
it's
ready
and
like
the
feature.
Work
will
basically
just
manage
and
just
be
kind
of
like
applied
at
the
first
kind
of
like
possible
moment
where
we
are
free
but
like
the
basically,
there
is
no,
we
would
kind
of
commit
on
on
not
impacting
the
merge
timeline
at
all.
Basically,
right.
A
I
think
that's
fine
and
obviously
so
also
to
make
something
clear
if
we
were
to
take
this
feature
fork
and
put
it
from
before
the
merge
after
the
merge.
I'm
sure
there's
some
technical
overhead
with
that.
That
seems
like
it's
kind
of
small
price,
to
pay
to
have
the
merge
earlier,
but
yeah
do
all
client
teams
agree.
This
generally
makes
sense,
so
keep
london
small.
A
You
know
plan
for
a
feature
fork.
I
don't
know
if
it's
you
know,
mid-october
or
late
september,
but
around
that
timeline.
If
the
merge
is
ready
before
we
obviously
do
it
before,
and
that
means
we'll
have
to
keep
working
on
it
in
parallel
and
then,
if
the
merge
is
ready
shortly
after
we
do
the
merge
shortly.
A
A
I
I
A
Okay,
so
I
think
we're
all
on
the
same
page,
at
least
for
london
and
for
naming
for
the
forks
and
then
the
other
thing.
I
guess
the
other
thing
I
wanted
to
ask
about
for
london
is
we
have
this
included
in
it
about
the
difficulty
bomb
3238
and
we
all
agreed
a
month
or
two
ago
that
we
wanted
this
in.
We
kind
of
don't
have
a
choice,
but
we
never
kind
of
discussed
the
the
period.
A
A
A
L
A
B
I
think
what
helmets
is
trying
to
say:
I
don't
know
if
he's
gonna
make
or
not.
I
think
what
he's
trying
to
get
at
is
that
once
the
holiday
season
starts,
it's
very
unrealistic
that
we
will
get
anything
done
so
that
usually
starts
around
thanksgiving,
which
is
third
week
of
november,
like
just
traditionally
that's
when
people
stop
being
available
to
do
anything
productive.
B
A
B
A
Range
cool,
okay,
so
I'll
leave
a
comment
on
the
on
the
eip
to
make
sure
we
update
it,
and
I
guess
so
those
were
the
two
big
things
the
other
one
was
you
know
if
we
agree
to
the
london
timeline
of
trying
to
get
it
out
mid
july,
it
feels
a
bit
early
to
set
fork
blocks
for
that.
So
does
it
make
sense
to
set
four
blocks?
A
A
A
A
So
I
guess
it
depends,
might
yeah,
I
would
say
mid
july,
and
the
main
reason
is.
It
gives
us
a
lot
of
time
on
the
test
nets
and
it
gives
us
a
good
buffer
between
the
last
test
net
and
main
net.
So
because
1559
is
such
like
a
big
change,
I
would
rather
have
kind
of
a
long
rollout
period,
but
it's
not
a
super
strong
opinion.
Thomas
also
says
mid
july.
Does
anyone
feel
like
sooner
is
better.
A
Yeah-
and
I
I
do
think
so,
you
know
there's
a
comment
about
tools
and
whatnot
like
it
is
something
that
a
lot
of
people
have
shared
with
me
that
they
felt
like
with
berlin.
We,
you
know,
we
probably
didn't
take
enough
time
for
like
29,
30
and
explaining
that
out
and
whatnot.
So
I
think
1559
is
definitely
something
that
tooling,
even
though
they
they
don't
strictly
need
to
support
it.
They
want
to
and-
and
I
think
yeah
if
we
can
give
them
time
to
get
ready
for
it.
People
will
appreciate
that.
D
A
A
H
A
A
D
C
Than
in
a
couple
weeks,
I'm
just
saying
I
think
that
people
were
saying
that
people
want
to
build
these
tools,
and
it's
good
to
know
like
when
that
deadline
is.
But
if
they
don't
get
that
deadline
until
next
week,
then
that's
one
week
longer.
It
takes
for
them
one
like
one
week
longer
of
the
period
time
they
have
to
build.
But
if
we
give
them
that
deadline
today
and
move
the
deadline
up
is
the
same
amount
of
time.
D
A
C
E
A
A
D
A
A
D
Yes,
yeah,
I
already
posted
my
comment
on
there
magicians
I
mean
in
general.
I
agree
with
what
you're
saying
and
it's
it's
ugly.
However,
I
think
that
it's
not
it's
solving
a
small
problem.
It
doesn't
solve
a
big
problem
that
if
users
like
blindly
just
add
slots,
they
may
well
when
they
submit
the
transaction.
D
It
may
fail
early
because
something
changed
from
when
they
made
the
access
list,
so
they
actually
actually
was
included
in
the
block,
which
makes
you
pay
the
full
cost
for
everything
you
were
going
to
access
in
case.
The
transaction
had
followed
the
path
that
you
thought
it
would,
but
since
it
exits
early,
yeah
you're
just
paying
for
nothing
so
whether
or
not
and
what
parts
of
the
state
to
include
what
parts
to
not
include,
and
that
is
in
a
tricky
situation,
it
becomes
slightly
less
tricky.
D
If
we
remove
this
particular
word,
I
mean
we
help
solve
a
little
bit
of
a
very
complex
problem,
but
yeah.
So
I
personally
don't
think
this
is
very
important
to
get
in
urgently,
but
I
do
agree
that
this
change
from
life
science
is
good
and
in
the
right
direction,
but
I
personally
don't
see
that
we
need
to
like
rush
it.
Then
that's
just
my.
I
have
no
really
strong
opinion
about
this.
I'm
glad
to
hear
what
other
people
think.
C
Yeah
I
mean
I
definitely
agree
with
martin.
I
think
that
I
think
it
almost
is
starting
to
incentivize
people
to
use
access
list
without
fully
understanding
the
ramifications,
and
you
know
it's
something
to
always
keep
in
mind
that
your
access
list
that
you
generated
time
t
is
not
going
to
be
the
same
transaction
list
as
needed
at
time.
T
plus
one
and
that's
a
tricky
thing
to
communicate.
A
Cool
thanks,
so
I
had
one
last
thing
on
the
agenda.
This
very
kind
of
process
thing,
but
we
have
this
considered
for
inclusion
status,
that
we
didn't
use
a
ton
for
london,
because
I
guess
1559
was
the
the
big
one
and
basically,
we
had
you
know
considered,
for
inclusion
was
the
status
where
we
would.
A
So
it's
not
like
an
extra
process
but
yeah.
I
just
wanted
to
see
if
that
was
okay
with
everybody
and
the
main.
The
main
reason
to
do
this
is
otherwise.
When
people
look
at
this
cfi
list,
they'll
see
like
a
bunch
of
old
eeps
that
you
know
someone
proposed
for
istanbul
or
whatever,
and
you
know
it's
not
actually
being
worked
on
or
being
considered
by
core
devs.
So
having
you
to
reset.
Every
fork
is
just
like
a
clear
way
to
keep
the
list
up
to
date.
A
No
objections,
okay,
so
I'll.
Take
that
as
people
are
good
with
it,
and
I
guess
for
yeah,
I
guess,
for
london
we
don't
really
have
any
cfi
eeps,
because
we
kind
of
moved
everything
into
upgrade
directly.
But
you
know
when
we
start
discussing
shanghai,
we
can.
We
can
definitely
use
that
again,
and
I
guess
one
last
thing
I
see.
Martin
has
a
comment
on
the
agenda
about
not
trying
to
make
too
many
decisions
on
the
off
schedule.
A
B
My
solution
to
that
is
to
make
the
this
an
official
a
cd
call
rather
than
an
office
call
I'm
a
big
fan
of
more
regular
meetings.
It
feels
like
our
current
bi-weekly
meeting
or
alternating
weekly
meetings
are
way
too
full
and
I
think
we're
at
a
point
where
we
need
to
have
more
frequency,
and
so
I
would
vote
for
just
saying
this
is
an
acd
call
and
we
make
decisions
on
it
or
at
least
going
forward.
We
do
that.
A
A
C
Good
start,
I
was
just
going
to
say
I
sort
of
feel
like
if
we
use
breakouts
more
liberally.
That
would
probably
reduce
the
amount
of
discussion
on
all
core
devs.
I
think
especially
the
last
few
meetings.
We
spent
a
lot
of
time
discussing
and
you
know,
going
back
and
forth
on
something
that
really
could
have
been
discussed
in
a
breakout
room,
and
then
people
get
to
come
back
and
sort
of.
H
H
B
Yeah,
so
my
I
agree
that
would
be
ideal.
We've
been
trying
to
do
that
for
like
6
to
12
months
and
just
failing
repeatedly
repeatedly
repeatedly,
and
so
I
think
that
we're
at
a
point
where
we
need
to
start
punishing
ourselves
for
not
succeeding
with
that
and
like
it's
kind
of
like
hey,
we
gave
you
guys.
We
gave
ourselves
a
chance
to
fix
this
without
more
meetings.
It
did
not
work.
B
We
are
going
to
have
more
meetings
now,
like
sucks
to
be
us,
we
should
have
done
better
and
if
we
can
start
doing
more
breakout
rooms
and
our
meetings
get
empty,
then
we
can
start
canceling
them,
which
would
be
great,
but
I
feel
like
the
current
holding
pattern
of
don't
have
more
meetings
and
also
don't
successfully
do
breakout
rooms
and
don't
successfully
do
async
is
not
scaling.
Well,
like
it
doesn't
work.
A
We
do
have
the
merge
calls,
though
right
like
so.
I
think
this
is
one
thing
and
I
don't
like
my.
I
guess
I
don't
my
opinion
is
it
feels
like
we
do
get
through
most
of
the
urgent
stuff
like
there's
always
stuff.
That's
like
lingering
and
I
think
that's
kind
of
okay.
It's
not
the
end
of
the
world
yeah.
I
would.
A
I
guess
I
would
prefer
if
we
had
more
topical
meetings
like
if
there
is
something
that
we
need
to
take
like
a
quick
or
important
decision
on.
We
probably
should,
but
I
don't.
Maybe
I
need
to
look
through
examples
of
stuff
where
we
we
didn't
kind
of
make
a
decision
quickly
enough
and
we
should
have
had
more
breakout
rooms,
but
it
feels
like
you
know,
for
london
we're
on
a
good
in
a
good
spot
where
the
decisions
are
kind
of
made
and
and
and
we
have
time
to
to
deal
with
them-
there's.
A
B
So
I
think
the
things
that
we're
struggling
on
isn't
that
we
are
struggling
to
decide
on
like
fork
blocks
or
whatever
it's
more,
that
we
don't
have
enough
time
to
actually
discuss
like
we
have
eips
they
get
held
up
just
on
discussion,
not
on
coding.
The
obvious
canonical
example
of
this
is
bls
right.
We've
had
bls
done
for
12
months,
and
every
single
client
and
the
only
thing
holding
us
up
is
just
not
spending
enough
time
coming
to
consensus
like
that's
to
hold
up
for
bls,
it's
not
code.
B
It's
not
engineering
efforts,
none
of
those
things.
It's
just
people
talking
to
each
other
and
coming
to
an
agreement
on
it
and
so
like
so
we
end
up
the
solution
we
have
to.
That
is
just
don't
implement
bls,
and
I
I
that's
just
again
canonical
example:
I've
seen
this
on
a
number
of
eips,
where
we
end
up
deciding
to
not
do
a
thing
just
because
we're
not
spending
enough
time
talking
about
that
thing
and
coming
to
agreement
on
it,
whether
it's
async
or
sync,
or
breakout
or
acd's
whatever.
A
So
I
feel
like
I
have
to
yeah.
I
have
to
think
about
that
more
off
the
top
of
my
head.
One
thing
I
feel
like
one
of
the
causes
for
that
is
also
that
we
end
up
having
stuff
that's
just
more
urgent
to
talk
about
in
a
way
and
like,
for
example,
for
bls.
When
we
knew
it
wasn't
gonna
make
it
into
berlin.
A
Then
you
know
all
the
berlin
topics
became
kind
of
higher
priority,
and
then
I
don't
know
yeah.
The
challenge
with
london
was
like
the
1559
was
already
such
a
big
change,
and
do
we
actually
want
to
put
anything
else
in
and
you
know
how
do
we
do
that
in
parallel
to
demerge,
and
I
guess
yeah
like
thomas
says
it
seems
like
we're
pretty
much
in
agreement
on
bls
today.
B
B
I
see
you
having
an
extra
meeting.
Definitely
helps
like
it
solved
a
lot
of
problems
that
we've
had
for
months,
like
just
one
extra
meeting
seemed
to
do
it.
Maybe
we
just
got
lucky
coincidence,
I
don't
know,
but
it
really
feels
like
having
twice
as
many
meetings
was
a
solution
like
it
fixed
our
problems.
So.
M
I
feel
the
same.
Actually,
it's
actually
teams
calls,
and
during
the
last
week
that
caused
that
much
of
an
agreement
and
this
in
this
meeting
to
go
smoother.
It's
not
just
because
we
we
had
this
call
today
practically
went
into
the
summary.
Everybody
was
all
aware
of
the
decisions,
the
communication,
everybody
expressed
their
opinions
and
that's
why
it
was
so
smooth
today.
So
I
was
just
a
great
thank
you
to
team
for
for
that
work.
It
was
fantastic
effort.
A
Thanks,
I
mean
I'm
happy
to
do
that
every
you
know
between
every
call
with
every
client
team,
but
sometimes
I
feel
like
it
might
have
too
much
overhead.
I
can
definitely
I'll
definitely
do
it
like
when
it
feels
like
we
need
to
figure
out
a
lot
of
stuff
between
the
next.
The
calls
like,
for
example,
before
next
week.
I
don't
think,
there's
a
lot
we
need
to
do,
but
yeah
I'm
happy
to
keep
doing
that.
My
only
concern
I
had
while
doing
that
is
I
don't
want
it
to
seem.