►
From YouTube: EIPIP Meeting #84
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/245
A
Welcome
to
eipip
meeting
84..
This
is
a
issue
number
245
on
ethereum
catheters
GitHub
repository
have
shared
agenda
Link
in
the
chat.
We
have
few
items
to
be
discussed
today.
The
first
one
is
open,
Issues,
new,
open
issues
and
pull
requests.
Then
we
will
have
discussion
continued
or
updates
from
the
past
meetings,
followed
by
some
updates
on
eips
insight
and
editing
of
this
hour,
starting
with
the
first
item
here.
A
That
is,
with
respect
to
a
meta
proposal.
7199
the
first
one
added
here
is
an
issue.
It
suggests
that
make
eipw
only
check
change
line,
except
for
changing
status.
Looking
into
the
issue
it
looks
like
this
has
already
been
responded
with
the
pr
7199
just
wondering.
Do
we
still
need
to
discuss
anything
we
would
like
to.
You
know,
come
to
a
discussion
any
further,
or
is
it
good
and
can
be
closed.
A
I
I
see
this
was
proposed
by
Victor
Victor.
If
you
have
to
add
anything
on
this
one.
A
Very
well
so
looks
like
the
other.
Two
PRS
are
also
related
to
this.
A
The
two
PRS
are
seven
triple
two
and
seven
two,
two
five,
the
seven
triple
two
suggests
that
7199
proposal
7199
should
be
moved
to
review
and
there
is
another
PR
opened
by
Sam
Wilson,
which
suggests
that
it
should
be
moved
to
withdrawn
the
first
one
is
by
Vector
Victor.
If
you
would
like
to
share
your
thoughts
on
that,
and
then
we
can
look
into
the
proposal
for
Sam
proposal
by
Sam.
C
I'm
open
either
way
so,
as
there
is
very
updates,
it
can
be
in
if
you
want
and
I
can
move
it
to
withdrawal.
If,
if
we
modify
the
ER,
if
you
want.
C
I
think
this
has
been
plot,
many
updates,
so
ideally
it
would
be,
it
will
be
fill
out.
I,
don't
think
this
is
every
small
policy
because
it
just
happens
so
often.
So,
ideally
it
will
be
spell
out.
A
A
Thank
you
all
right.
We
do
not
have
any
changes
to
final
proposal
as
the
next
item,
however,
I'm
still
wondering
if
we
have
the
bot
issue
got
resolved,
looks
like
there
was
this
PR
7240,
which
was
approved
yesterday
in
the
EIP
editing
office
hour
to
be
moved
to
final,
but
that
hasn't
been
merged.
Yet.
A
So
the
authors
they
were
inquisitive
about,
if
anything,
has
to
be
done
and
our
general
recommendation
was
to
wait
till
the
bot
gets
activated
and
it
merge
all
by
itself.
I
hope
we
stand
good.
There.
A
Moving
on
on
to
item
number
two,
which
is
discussion,
continued
or
updates
from
the
past
meeting,
so
one
big
item
that
has
been
listed
here
is
EIP
ERC,
repo
split
for
people
to
have
some
context.
We
have
been
discussing
this
topic
for
a
few
years
and
there
has
been
significant
progress
in
the
past
two
weeks,
Matt
opened
a
PR
for
repo
split,
and
it
was
also
discussed
in
the
last
all
core
Dev
execution.
Meeting
from
the
ACD
meeting
it
looks
like
most
of
the
client
deaths
are
in
favor
of
the
repo
splits.
A
Oh,
if
that's
the
way
forward,
we
must
discuss
next
steps.
There
is
a
hack
MD
proposed
by
Victor,
which
is
also
added
to
the
agenda.
Here
we
can
take
a
look
into
that
and
yeah
opening
the
flow
for
people
to
discuss
this
topic
and
propose
next
steps
for
us.
B
Okay,
oh
sorry,
I
should
probably
introduce
myself
I'm,
just
a
random
guy
who
is
trying
to
help
I
I,
don't
have
a
strong
opinion
on
this
other
than
I
would
be
more
active
after
the
split
in
one
of
the
two
editorial
boards.
That's
all.
A
C
That
was
that's
more
than
come
up
with
so
I
guess.
Whoever
added
that
can
comment.
I
just
list
a
few
tasks
feel
free
to
add
more.
B
A
So,
who
on
if
I
understand
correctly,
you
mentioned
that
you
would
be
interested
in
contributing
to
the
both
side
of
it
yeah
anything
specific
you
would
like
to
add
here
you
mean
you
would
be
helping
out
with
EIP
48
days.
Of
course,
yeah.
Please
go
ahead
and
share
that.
B
Yeah
sorry
I
mentioned
in
one
of
the
GitHub
threads
I,
can't
even
remember
which
but
like
if
these
were
distinct
editorial
boards
I
would
love
to
be
an
editor
and
volunteer
whatever
the
minimum
hourly
time.
Commitment
is
to
be
on
the
board
for
the
non-4
ones,
like
I,
really
don't
understand
how
clients
work
I'm,
not
you
know
the
rest
or
a
go
wizard,
but
I
I.
Think
that,
like
but
another
way,
what
I'm
most
interested
in
is
having
the
real
world
processes
around,
like
the
editorial
processes.
B
Split,
the
specifics
of
like
the
repo
or
the
the
documents
themselves
to
me
is
like
a
secondary
concern
so
like,
if
there's
consensus,
that's
putting
the
editorial
duties
between
two
editorial
boards.
If
there's
contents
there,
like
I,
think
everything
else
is
detailed
and
I'd
I'd
love
to
Champion.
Whatever
details
get
contented.
B
B
Yeah,
maybe
that's
a
good
place
to
start
sorry,
I'm
coming
in
apparently
years
late,
I,
don't
know
the
backstory.
So
please
help
me
understand
what
the
sort
of
blockers
are
to
consent.
This
other
than
your
most
recent
comments,
which
I
read.
F
I've
never
been
in
favor
of
splitting
the
process.
I
I
submitted
changes
to
eip1
I
thought
they
were
on
the
agenda.
I,
don't
see
the
point
of
splitting
until
we've
actually
looked
at
what
the
pain
points
are
and
I
simply
haven't
seen
that
the
split
actually
helps
the
pain
points
and
the
pain
points
I
can
identify.
I've
suggested
how
we
can
address
those
without
any
split.
E
F
E
F
H
So
one
thing
I'd
like
to
point
out
is
that
we're
really
starting
to
move
core
EIP
processes
outside
of
the
IP
process.
There
is
no
EIP
for
the
execution
engine
API
The,
Meta
eips
for
the
hard
Forks
are
no
longer
kept,
as
eips
are
kept
in
a
separate
repo.
A
lot
of
the
Json
RPC
stuff
is
done
outside
of
the
EIP,
and
a
lot
of
these
is
the
community.
Just,
doesn't
they
don't
some
of
them?
Don't
respect
the
EIP
process,
some
of
them
find
it
cumbersome.
H
Some
of
them
refuse
to
interact
with
it,
and
this
is
a
step
that
would
help
adjust
the
rules
for
the
courts
as
contributors
versus
the
application
layer
contributors,
so
that
we
could
change
the
rules
that
have
slightly.
They
have
very
different
audiences
towards
what
a
court
process
needs
from
an
EIP
than
what
an
ERC
needs
from
an
EIP
and
splitting
it'll
make
it
very
crystal
clear
that
these
follow
under
different
rules
rather
than
having
different
views
within
the
editors
and
different
processes.
H
But
I
think
the
big
problem
that
we
need
to
address
is
that
this
split
is
already
starting
to
happen,
and
if
we
don't
take
action
soon,
it
will
continue
in
a
way
that
will
fundamentally
change
eips
in
general.
So
we
should
try
and
direct
it
to
a
net
positive
solution.
Rather
than
have
coordination,
failure
and
let
it
move
away
from
it
and
destroy
an
existing
institution.
H
F
I've
suggested
a
series
of
changes
to
handle
a
number
of
the
problems.
I'm
aware
of
I
haven't
seen
I've
seen.
We
want
to
split
them,
but
then
what
I
haven't
seen
if
we
split
them?
These
are
the
ways
in
which
they're
actually
going
to
differ.
I
haven't
seen
any
ways
that
they
need
to
be
different
in
order
to
solve
the
problems,
because
the
problems
are
affecting
both
sides
in
the
same
way,.
E
I
mean
for
one.
The
thing
you've
proposed
are
things
that
have
been
proposed
for
years
and
years
that
we
haven't
actually
been
able
to
integrate
into
the
processes.
So
I'm
not
really
optimistic
that
this
time
is
different.
We're
going
to
be
able
to
change
these
things,
but
I
think.
Ultimately,
we
need
to
show
that
the
community
that
we're
willing
to
make
drastic
changes
and
help
bring
some
people
back
into
the
fold
by
showing
them
with
this
process
split,
even
if
there
isn't
something.
F
E
H
Have
a
shorter
list
to
review,
rather
than
reading
every
random
application
layer,
business
model
that
thinks
they
need
an
EIP.
So
that's
one
material
advantage
that
splitting
the
repos
will
have
to
core
developers
in.
F
E
Can
create
all
kinds
of
fancy
ways
for
people
to
better
differentiate
the
different
types
of
eaps,
but
at
the
end
of
the
day,
this
is
not
how
people
interact
with
GitHub
repos
they're
used
to
their
repos,
having
all
the
things
that
they
care
about,
and
they
just
use
the
standard
notification
tool.
They
don't
use
labels,
they
don't
use
email
and
we've
seen
for
years.
We've
had
these
RSS
feeds,
nobody
uses
them.
This
is
the
only
way
that
we're
going
to
get
people
to
interact
with
the
repo.
That's
just
the
in.
E
C
Into
very
specific
points
of
notification,
pane,
I
I
know
that's
a
like
line.
You
use
notification,
I,
don't
know
if
other
people
I
don't
I.
Personally,
that's
not
my
experience
and
also
I
haven't
come
to
know
a
handful
of
people
near
me
who
doesn't
so
I.
Don't
know
how
representative
that
is.
C
I
I
think
it's
worthy
that
we
go
through
some
of
the
policy
proposal
that
that
reg
list
out
and
see
if
that
is
where
you
want
to
go,
it's
it's
worthy
discussion,
even
if,
after
the
splits
and
for
the
record,
I
personally
have
reservation
on
this
and
then
I,
don't
wanna
I'm,
not
saying
that
I'm
going
to
block
consensus,
but
I
do
think
that
what
Greg
has
list
out
as
a
proposal
deserves
a
chance
to
be
seen
here,
and
you
can
see
how
much
improvements
or
agreement
you
have
in
the
future
of
policy
and
if
you
don't
even
the
good.
C
The
the
positive
thing
is
that
if
you
see
that
you
will
agree
together,
I
I
mean
that's
the
policy
where
it
will
go.
Then
split
split
makes
sense,
but
if
you
cannot
agree
on
a
lot
of
policy,
maybe
that's
time
for
discussing
it.
So
maybe
we
don't
see
what
Greg
proposed
in
additive
VIP
one
as
directly
related
to
ER
the
split,
but
maybe
it's
just.
This
deserve
a
a
read.
E
E
Yeah
we've
had
on
the
agenda
many
times
how
to
improve
like
getting
eaps
into
draft
like
what
should
that
look
like?
Should
they
be
numbers?
Should
they
be
letters,
should
they
be
EAP
eapd,
like
we've?
Had
these
debates
debates
have
gone
nowhere
and
it's
time
to
just
throw
the
white
flag
up
and
split
these
processes
and
then
try
and
resolve
after.
F
G
What
I'm
curious
to
understand
like
what
harm
do
you
see
coming
from
this,
because
and
and
like
I,
understand,
Sam's
Point,
that's
like
look.
The
repo
is
like
a
collective
documents.
You
can
treat
different
documents
a
different
way,
but
obviously
we
have
different
types
of
documents
in
different
people.
G
Today,
like
the
yellow
paper
eels,
Json
RPC,
they
all
live
in
different
places
so
like
what's
the
what's
the
harm
that
you
see
from
splitting
aside
from
like
sure
it's
going
to
be
a
bunch
of
work
to
do
it
the
first
time
but
yeah
beyond
that,
like
assume
the
split
is
done,
you
know
what
what
is
the
pain
we're
experiencing
after
on,
like
an
ongoing
basis.
G
G
E
I
I
mean
we
did.
We
told
you
a
very
specific
good
thing
that
we'll
come
up
with
the
court
of
developers
are
asking
for,
which
is
that
they
can
actually
use
the
notifications
for
the
eips.
Whether
or
not
you
think
this
is
reasonable,
like
I
can't
make
you
believe
that
that's
something
that's
useful,
but.
H
It's
good
that's
going
to
come
from
it
is
it's
going
to
be
a
lot
easier
to
get
people
who
disengage
from
the
process
to
re-engage
with
the
process.
Like
has
been
mentioned
in
chat,
we
have
been
losing
specs
that
should
be
eips
to
other
repos
that
are
skipping
the
EIP
process
that
should
have
EIP
numbers
posted
for
these
changes,
but
rather
than
engage
with
the
EIP
process
to
create
their
own
repo
and
do
their
own
thing.
That's
the
big
win
I
see
is
by
splitting
the
focuses
of
these
two
filing
cabinets.
H
These
two
organizations
or,
however,
you
want
to
view
it.
People
are
going
to
be
able
to
laser
focus
on
the
area
they
care
about
and
not
have
to
worry
about.
The
other
things
that
are
outside
of
their
skills
of
concern.
Erc
is
an
application.
Layer,
eips
have
a
broadly
different
scope
than
protocol
level
changes
and
there's
very
little
overlap
and
when
they
do
overlap,
it's
worth
an
EIP
in
both
repos,
because
there's
going
to
be
different
aspects
that
impact
how
the
protocol
interacts
with
it
and
how
the
clients
interact
with
it.
H
So
that's
the
big
change
I
see
is
making
these
two
layers
much
clearer
and
more
distinct
in
development
and
testable
developments
and
processing
uses.
So
it's
going
to
make
it
more
crystal
clear
that
this
happens
on
the
application
layer,
and
this
happens
in
the
protocol-
that
is
the
single
biggest
game
I
see
from
splitting
this
and
I
think
alone
is
sufficient
to
split
it.
F
I
mean
I'm.
Sorry,
if
we
do
this
I'll
leave
I'm
free
to
leave
you're
free
to.
Let
me
leave
and
I've
I've
gone
through.
The
changes.
I
actually
think
will
help
I
think
the
same
changes
need
to
be
made
to
the
ERC
I,
see
the
same
problems
with
the
process,
so
splitting
the
repo
still
leaves
all
those
problems.
I
I
I
I,
don't
think
many
people
disagree
with
you
that
there
are
many
common
issues
and
the
many
things
that
need
to
be
addressed.
But
this
is
an
orthogonal
issue.
We're
trying
to
address
here
and
very
much
would
like
to
to
to
fix
many
of
of
the
things
you
brought
up
and
in
many
of
the
ways
that
that
you're
going
after
here.
But
this
is
something
else
that
we
desperately
need
to
be
like.
Would
this
be
help
the
erpv
process
get
more
used.
F
I
Because
to
people
who
aren't
actively
involved
in
both
processes
and
don't
don't
don't
actively
all
of
the
exact
weird
rules,
you
have
to
learn
to
interact
with
this
repo.
It
is
a
nightmare
to
to
come
over
to
this.
Reaper
I
see
it
and
they
are
like.
I
It
just
seems
like
a
very
confusing
tastes
to
to
to
exist,
and
we
can
do
this
thing
where
it
like
dramatically
simplifies
things
with
the
average
person
you
just
have
to
go
to
the
repo
and
look
at
the
things
that
are
probably
relevant
to
you,
and
you
can
then
start
filtering
by
topic
instead
of
figuring
out
what
the
mental
filtering
mechanism
is.
That
happens
to
the
interact
with
this
report.
F
I
I
The
places
where
these
these
these
erps
exist
and
potentially
the
process
is
slightly
over
time.
If
that's
what
the
demands
are
from
the
two
different
communities,
largely
they're,
interacting
with
this
process.
E
C
C
Or
tabs
and
you're
definitely
welcome
here,
but
I
I
have
heard
your
voice.
Can
I
ask
audit
and
like
Lion,
who,
in
the
editor
group,
is
strongly
in
favor
of
splitting.
C
Sorry,
maybe
I
we
didn't
but
I've
not
work
with
you.
Maybe
you
three
three
times
mine.
A
No
I
don't
think
this
name
was
ever
in
their
latest
list.
If
this
question
was
specific
to
editors,
no
I
don't
think
it
was
there
and
we
are
not
joined
by
all
the
editors
today
in
the
meeting.
That
is
another
point
to
be
considered
so
I'm
not
sure
if
we
can
get
a
proper
response
over
here,
I
see
Panda
and
for
gender
saying
not
in
the
meeting
I.
C
C
Yeah,
it
seems
like
there's
a
a
bunch
of
people
who
are
who
are
reserved
and
I
do
believe
that
the
the
problem
that
carback
and
Daniel
and
Mary
is
said
is
real
problem.
That
people
were
disengaged
and
notification
was
not
was
inconvenient.
C
For
me,
the
notification
is
more,
is
inconvenient,
but
the
more
problem
is
it's
so
hard
to
edit
and
what's
I,
think
what
eip1
updates
by
Greg
is
about
making
it
convenient,
and
if
you
discuss
you
will
realize
that
a
lot
of
things
that
you
believe
is
natural
are
actually
not
like.
C
Some
people
in
the
editor
group
are
actually
trying
to
say
that
oh,
let's
make
it
harder
and
that's
what
I
think
we
are
trying
to
repeatedly
Greg
and
I
and
and
a
bunch
of
us
are
trying
to
make
the
process
easier
for
people
to
engage
and
we're
frustrated
as
much
as
you
are.
C
If
a
lot
of
debt
core
devs
like
individually,
come
to
us
and
say
hey,
this
policy
is
really
dark,
we
should
fix
it
and
whatever
we
take
it
to
the
editor
group,
it
gets
blocked.
I.
The
the
frustration
I've
seen
is
that
those
are
from
both
sides.
C
People
just
don't
want
that
to
be
so
restrictive
and
we
haven't
been
able
to
resolve
it
and
I'm,
not
I'm,
unlike
Greg
I'm,
not
planning
to
block
the
split
I,
just
feel
that's,
which
we
really
really
should
discuss
and
take
the
input
from
the
core,
Dev
and
ERC
authors
that
how
how
to
make
it's
easier
for
us
to
add
it
and
I.
C
Other
than
a
notification
I
haven't
seen
very
convincing
things
that
a
clear
direction
of
why
or
how
or
can
can
benefit
a
policy
that
ERC
can't
in
the
point
and
yeah.
So
can
we
at
least
take
a
look
at
the
IP
edits
up
updates
of
the
of
Greg's
and
then
I
have
Greg,
maybe
walk
through
the
the
over
overview
of
it
and
and
see
because
we,
it
is
a
valuable
time
where
a
lot
of
eyes
here
are
today.
A
H
So
there's
a
couple
of
things
that
would
benefit
if
we
could
split
the
repo
that
we
could
even
have
the
discussion
about,
starting
if
eips
and
erc's
were
different.
Some
there
are
some
workflows
that
the
cordovs
have
adopted,
such
as
eligible
for
inclusion
included
in
the
hard
Fork
that
that
kind
of
used
to
be
in
the
MP
process,
but
we
pulled
out-
and
these
are
steps
that
are
completely
inappropriate
for
an
ERC
to
be
considered
as
gatekeeping.
H
We
shouldn't
be
have
to
keep
the
diamond
standard
because
clients
don't
have
it
implemented
for
for
Cancun
or
Prague
or
whatever.
So
that's
one
policy
change
that
I
think
we're
going
pretty
early
is
we
would
bring
back
in
our
signaling,
for
which
eips
are
actually
viable
and
which
ones
aren't
for
inclusion.
The
withdrawn
suspended
just
really
isn't
doing
it.
H
For
us,
we
need
something
that
has
feedback
that
is
more
tightly
integrated
with
the
ACD
process,
and
the
second
thing
is
I
think
we
need
to
add
another
step
for
eips
that
our
core
protocols
that
reflect
the
the
Readiness
for
testing
development
do
we
have
reference
tests
written
for
these?
That
should
be
a
separate
lifestyle
cycle
stuff
that
should
block
final
acceptance
of
these
tests,
and
we
should
also
agree
in
the
process
whether
it's
ready
for
testnet
if
it's
been
deployed
on
mainnet.
H
These
are
things
that
are
very,
very
peculiar
to
core
protocol
and
aren't
worth
discussing
while
we
are
still
merged
with
the
the
the
ERC
process
that
has
completely
different
goals
of
completely
different
agendas
than
what
core
developers
have
it's
these
vastly
diverging
policies
of
the
vastly
diverging
needs
that
come
from
what
people
want
from
the
ERC
process.
That
is
really
what's
freezing
the
gears
in
all
eip1
discussions
on
the
thought
that
it
needs
to
serve
all
possible
use
cases.
D
So
I
definitely
understand
a
lot
of
the
frustration
with
having
the
EIP
process
not
attached
to
the
cord,
like
the
core
development
process
like
well
well,
I
was
working
on
eels,
the
amount
of
times
that
it's
like
okay,
which
hard
Fork
is
this
EIP
in,
and
you
know
what
block
number
does
this
EIP
activate
on
I
understand
a
lot
of
those
frustrations
and
you
know
switching
from
my
eels
hat
to
my
editor
hat,
the
statuses
of
documents
and
Eels
are
of
the
documents
themselves.
D
That
I
think
the
reason-
and
this
is
from
before
my
time
as
an
editor.
Unfortunately,
but
I
think.
The
big
reason
why
we
aren't
more
tightly
integrated
with
the
release
cycle
of
mainnet
is
that
eips
are
meant
to
be
like
agnostic
to
the
chain
that
they're
deployed
on.
So
you
can
point
to
an
EIP
and
say,
like
you
know,
on
ethereum
classic
we
have
these
eips
and
on
on
mainnet
ethereum
or
test
net
ethereum.
We
have
those
eips
and,
like
that's
kind
of
why
they're
they're
so
separated
from
how
core
development
Works.
D
Maybe
it's
time
we
re-examine
that
link,
but
we
can
do
that
without
splitting.
The
repo
I
think
like
having
a
different
process
for
core
eips
is
completely
doable.
A
I
would
also
like
to
add
a
few
points
here.
I
think
there
is
some
misunderstanding:
I'm
going
to
clarify
the
existing
EIP
process
is
somehow
different
for
core
and
a
rest
of
the
proposals
rest
of
the
category
in
time.
So
for
core
eibs
we
do
have
the
process
of
CFI,
which
was
never
a
part
of
ERC.
It
was
never.
A
Right
what
I'm
suggesting
here
is
like
we
can
still
follow
that,
and
it
is
not
affecting
core
eips
to
follow
it,
and
it
is
I
mean
like
erc's,
are
not
a
blocker
here
the
process.
What
is
being
suggested
can
be
followed.
We
have
ways
to
follow
and
I
don't
think.
Ercs
are
stopping
that
ERC
and
core
EIP
process.
In
fact,
core
EIP
is
only
category
where
it
is
a
little
bit
different
than
any
other
process.
A
A
A
So
what
I
understand
from
this
discussion,
what
vector
and
Greg
are
trying
to
communicate
is
let's
try
to
point
out
the
pain
points
which
are
not
accepted
by
the
ERC
category
and
which
we
want
to
implement,
because
we
want
to
support
core
eips
here
in
this
repository.
I
do
agree
that
the
noise
point
is
very
much
valid.
The
notification
point
is
very
much
valid
and
I
I
perhaps
do
not
have
any
perfect
solution
for
that.
A
H
So,
let's
look
at
the
CFI
process:
that's
something
that
does
not
really
managed
by
the
by
the
EIP
process.
That's
something
entirely
managed
by
the
ACD!
So
now
what
we
would
have
to
do
is
if
we
want
to
change
that,
we
would
then
have
to
post
an
EIP
to
eip1,
let
a
bunch
of
editors
who
don't
always
call
into
this
meeting.
Then
we
have
to
represent
what
the
needs
of
the
core
devs
are
and
that
just
increases.
H
It
increases
a
lot
of
friction
to
an
already
slow
process
of
shipping,
core
protocol
changes
and,
as
we've
seen
when
you
do
a
proposal
that
someone
doesn't
like,
they
will
jump
up
and
say
I'll
block
consensus
or
I'll
resign
and
make
big
drama
out
of
something
that
should
have
been
a
simple
change.
That
is
my
concern
of
keeping
it
together
really
making
all
of
these
exceptions.
But
the
number
of
the
exceptions
that
we're
getting
is
to
me
a
signal
that
it
needs
to
be
a
separate
process.
H
F
Some
history
here
we
started
out
with
nothing
but
drafts
and
how
the
court
devs
organize
their
own
process
was
not
an
EIP
concern.
Once
something
went
on
the
main
net,
we
labeled
it
final
because
once
it
was
on
the
main
net,
it
couldn't
really
be
changed.
Whatever
was
on,
the
main
net
was
what
was
on
the
main
net
and
that's
what
the
EIP
needed
to
describe.
F
We
added
a
last
call
process
for
erc's
just
so
there
would
some
way
to
get
them
vital
for
people
to
say.
Okay.
This
is
what
we're
going
to
implement
over
time.
We
wound
up
adding
more
categories
and
process
and
sort
of
mixing
up
the
core
Dev
process
and
the
EIP
process.
For
my
from
my
perspective
as
an
OG,
it
got
more
complicated.
It
got
more
mixed
up
together,
so
yeah
the
core
devs
are
having
to
fight
with
the
IP
process.
We,
when
really
they
shouldn't,
have
much
to
do
with
each
other.
G
It
just
feels
like
it's
terrible
like
when
we
have
to
use
each
magicians
to
like
signal
which,
like
eips,
we
may
want
to
include
in
the
hard
Forks.
It's
like
we're,
creating
all
these
random
things
that
the
only
people
who
can
actually
track
our
folks,
like
basically
me
whose
job
it
is
to
do
that.
But
if
you're,
a
random
person
who
wants
to
figure
out
hey,
which
gips
are
being
proposed
for
Cancun,
you
can't
go
to
like
eepsod
ethereum.org
and
have
any
in
Insight
on
that.
G
And
similarly,
you
know
on
the
ERC
side,
if
you're
a
random
person-
and
you
want
to
figure
out
which
you
know
what
what
are
the
implementations
of
like
the
last
nft
standard.
You
can't
do
that
and
you
can
imagine
like
that
would
be
a
much
healthier
version
of
both.
Those
processes
like
yeah,
like
Peter
from
Death,
asks
me
for
these
random
documents.
G
You
know
from
time
to
time-
and
it's
kind
of
insane
to
me
that,
like
you
know
with
the
context
he
has
he's
not
able
to
like
into
it
where
the
right
thing
is
and
I
think
this
is
because
the
the
things
have
to
be
standard
and
I.
Understand
that,
like
it,
you
know,
you
don't
want
the
EIP
statuses
to
be
focused
on
hard
Forks,
because
not
all
of
them
need
hard
Forks.
G
But
if
we
do
split
the
repos,
then
you
can
say:
look
on
the
EIP
side,
there's
an
extra
tag
that
says
you
know
hard
Fork
status
or
something
like
that,
and
you
know
maybe
for
networking
eips
it's
just
not
set,
but
for
like
a
core
protocol
change,
then
you
know
it
gets
set
and
then
you
can
just
click
on
like
the
proposed
tag
or
the
included
tag
or
the
London
tag,
and
you
just
get
a
full
list
of
all
the
eips
in
that
Fort
and,
like
I
I.
G
Then
it's
it's
like
really
bad
and
it
puts
those
people
at
a
disadvantage.
So
I
think
the
more
we
can
do
to
keep
the
processes
encapsulated.
In
one
thing,
the
less
context
people
have
to
learn
and
because
there
are
some
differences
with
eips
and
erc's,
it
makes
sense
to
split
them
so
that
you
know
both
processes
can
eventually
reflect
like
the
reality
of
the
whole
life
cycle.
Of
not
just
like
writing
the
spec.
But
like
writing
this
back
and
getting
it
live
in
deployed
and
stuff
like
that.
A
I'm
in
strongly
in
favor
of
like
keeping
both
processed
encapsulated
and
keep
on
working,
it
looks
like
the
ship
before
stopping
the
repo
split
has
already
been
sailed
and
I
think
it
will
be
interesting
to
follow
on
what
on
the
next
steps.
Yeah,
please
Marius.
If
you
have
to
add
something
over
here.
J
Yes,
so
one
thing
that
I
would
really
like
to
talk
about
is
so
as
codiffs
I
feel
our
duties
with
the
community
and
if
the
community
wants
something
or
doesn't
want
something,
we
have
to
respect
that
wish,
even
if
the
community
wants
something
that
we
are
not
in
favor
of
so,
for
example,
I
was
part
of
brockpo
back
in
the
day
and
I
was
really
in
favor
of
it,
and
I
thought
it
was
the
the
right
thing
to
do
and
at
some
point
the
community
decided
that
this
is
not
the
right
thing
to
do,
and
so
I
had
to
accept
it
and
I
think
the
idea
of
the
EAP
editors
overruling
the
the
community
as
something
that
is
so
foreign
to
me.
J
That
I
think
it's
incredibly
Democratic.
Why?
Why
should
these
eight
people
have
a
vote
on
how
this
process
that
should
serve
the
community
and
doesn't?
J
Why
should
should
they
have
to
vote
at
the
vote
to
block
the
the
view
of
the
entire
Community?
That's
I
haven't
seen
anyone,
except
for
people
from
the
EAP
editing
team,
speak
out
in
favor
of
keeping
the
repositories
together.
D
Well
so,
like
I
said
in
Chad,
the
community
would
rather
have
you
know
way
higher
gas
limits
that
would
cause.
You
know,
database
problems
in
a
few
years
right.
The
community
doesn't
always
know
that
you
know
the
technical
reasons
behind
why
things
are
the
way
they
are
and
I'm,
not
saying
that
there
are
technical
reasons
to
keep
the
repositories
together.
D
Don't
get
me
wrong,
I'm,
just
using
that
as
an
example
of
why
the
community
might
not
always
be
correct
and
experts
might
be,
you
know,
have
a
different
opinion
and
you
know
a
lot
of
the
times
with
the
process.
Around
eips
I
think
they
have
very
logical
reasons
and
I
I
think
a
lot
of
the
hate
the
EIP
process
gets
is
from
you
know
the
previous
era
of
EIP
editing
and
that
we're
a
lot
more
like
we're
a
lot
easier
to
follow
now
than
we
used
to
be.
A
Yeah
there
has
been
a
lot
of
process
change
and
I
do
not
deny
that
I
think
it's
time
to
accept
this
as
one
of
the
process
change
and
one
reason
why
I
feel
like
EAP
editors
have
been
strongly
supporting
or
opposing
whatever
their
point
of
view.
They
are
sharing,
because
ultimately,
Process
Management
is
something
that
they
are
heavily
engaged
with
so
yeah,
considering
that
the
split
will
bring,
as
I
mentioned,
that
there
would
be
a
fixed
cost
of
having
this
split
done.
A
Let's
start
looking
into
this
cost
and
if
I
understand
correctly,
it
was
mentioned
in
the
all
code
execution
call
that
if
this
thing
does
not
work
out,
we
can
perhaps
come
back
and
make
things
back
as
it
was.
I
think
that
there
would
be
some
tooling
needed.
I
was
having
a
conversation
with
someone,
and
he
mentioned
that
we
can.
We
do
need
to
duplicate
some
of
the
work.
Let's
start,
looking
into
that
I
don't
know
Sam,
you
have
been
managing
more
most
of
the
parts
related
thing.
A
D
D
It
shouldn't
really
be
a
problem
for
e
review.
Bots
I'm
a
lot
less
familiar,
but
I
I,
don't
see
it
being
more
than
a
few
configuration
changes.
A
D
Yeah,
so
the
tooling
should
be
easy.
The
governance
overhead
might
be
a
little
bit
worse,
but
I
don't
think
like
I,
don't
think,
there's
any
like
having
to
do
a
ton
of
work
objections
to
splitting
the
repos.
A
All
right
I
do
understand
that
there
are
people
who
are
still
not
in
favor
of
having
this
split
and
I
heard
Greg
mentioning
that
he
may
be
willing
to
resign.
At
this
point
of
time,
I
would
sincerely
request
to
every
editor.
Please
do
not
resign,
we
need
you,
I
understand
there
can
be
objection
and
that
can
be
solved
and
that
can
be
helped
only
if
we
have
you.
We
only
have
six
editors
on
board
and
we
need
more
people
to
join
in
to
help
out
with
this
process
split.
A
Whatever
time
you
have
got,
if
you
can
divide
it
for
both
repositories
that
is
good
to
have.
If
not,
then
please
support
one
repository
and
we'll
try
to
have
more
editors
on
board.
On
the
other
repository
as
of
now,
this
seems
like
what
people
are
requesting
for
or
looking
for.
Let's
give
it
a
try
see
if
this
helps
and
if
it
helps
the
core
EIP
process
to
evolve.
Better
ERC
can
always
learn
from
core
EIP
and
have
the
process
adjusted
other
than
the
filing
cabinet
filing
issues.
A
A
F
E
F
C
I
have
asked
I
have
asked
to
have
an
opportunity
to
surface
this
to
the
ERC
author
group
and
I
I
was
hoping
that
to
get
a
chance
when
I
heard
that
the
ERC
authors
are
not
part
of
the
community,
I
was
a
little
bit
confused.
So
when
lifeline
and
says
it's
a
community
consensus,
I
was
quite
confused
because
we
haven't
asked
the
ERC
office
and
it
is
totally
possible
that
when
we
go
to
ask
yeah
the
authors,
they
want
to
split
as
well.
It's
totally
possible.
C
Is
it
just
that
it
seems.
C
Was
well,
it
seems
like
the
consensus.
What
you
meant
is
not
as
mature
as
I
would
see
it.
E
C
F
E
D
E
A
Greg
I
really
want
to
be
respectful
over
here.
I
really
want
to
be
respectful
over
here
and
I
would
request
you
to
move
the
pr
in
from
draft
I
mean
like
it
is
still
in
the
draft,
and
we
don't
know
if
it
is
ready.
Yet
if
you
can
change
change
that
make
it
like,
you
know,
the
pr
is
ready
to
be
discussed.
I
think
we
can
perhaps
have
more
discussion
on
that
and,
as
Victor
also
mentioned,
that
he
would
like
an
opportunity
to
have
it
discussed
with
the
all
ERC
Dev
meeting.
A
We
can
listen
to
what
people
over
there
have
to
see
what
we
want
to
do
here
right
now
to
get
prepared
for
both
sides
like.
If
the
split
is
happening,
then
we
should
be
ready
with
tooling.
We
don't
want
things
to
break
down,
so
we
should
be
ready
with
tooling,
which
I
suppose
is
in
moving
in
the
right
direction.
We
should
do
not
have
to
work
too
much.
It
can
be
done.
I
also
manage
a
website
called
eips
insight.
A
For
now
we
are
already
taking
care
of,
like
you
know,
every
data
coming
up
from
this
eaps
repository.
If
we
have
to
go
with
the
split,
then
we
perhaps
will
have
to
have
another
set
of
tooling
done.
For
that
thing,
definitely
we
have
to
do
a
lot
of
work.
What
we
are
I
think
concluding
here
is:
we
should
be
ready
for
going
in
up
both
ways.
We
would
be
discussing
the
changes
that
you
are
suggesting
for
eip1.
A
If
it
is
valid
for
core
EIP,
what
we
need
to
do
is
like
suggest
it
for
both
parties
and
see
we
can
discuss
it
over
there,
but
let's
keep
that
pain
points
that
you
have
mentioned
separate
from
this
repost
plan.
I
do
agree
about.
You
know
the
ideas
to
learn
how
we
want
to
make
changes.
What
are
the
proposed
changes?
It
would
be
really
interesting
to
learn,
but
in
the
meantime
my
only
request
to
you
would
be.
Please
do
not
take
any
decision
in
in
rush.
A
Let's
give
it
some
more
time
and
let's
see
that
we,
how
do
we
evolve
with
it?
Let's
be
ready
for
both
sides.
G
E
A
E
A
A
Let's
give
it
two
more
weeks,
I'm
not
discussing
it
any
further,
but
what
I'm
saying
is:
let's,
let's
be
prepared
for
this,
give
us
some
time
to
get
prepared,
maybe
by
next
meeting
we'll
try
to
collect
some
async
feedback
from
Panda
on
EIP
bot
for
eipw
Sam
already
mentioned
that
there
are
some
work
to
be
done,
and
that
should
be.
That
should
be
good
and
I
hope
that
by
next
meeting
we
would
have
everything
in
place
and
we
can
smoothly
merge
it.
I
am
not
saying
Greg.
A
We
are
trying
to
disrespect
you
here,
it's
just
that
there
are
some
times
we
go
by
the
majority
of
what
people
say.
Even
if
we
do
not
have
an
absolute
consensus,
we
go
by
the
rough
consensus
and
if
that's
what
people
are
looking
for,
even
if
we
are
having
a
different
opinion,
let's
give
it
a
try.
A
A
All
right,
I
think
it's.
A
A
No,
no,
that's
absolutely
true.
We
are
really
thankful
for
all
the
time
that
you
have
given
up.
Perhaps
you
are
one
of
the
oldest
editor
that
we
have
on
board
and
we
would
not
like
to
lose
you
but
I
think
it's
time
to
wrap
up,
and
let's
have
this
conversation
like
giving
it
a
beautiful
rest.
We
wait
for
another
two
weeks.
A
In
the
meantime,
we
will
try
to
work
on
the
bot
side,
get
our
eib
GitHub
repository
and
ERC
GitHub
repository
ready
for
the
split
and
in
the
meantime,
Victor
will
also
take
some
feedback
and
come
back
and
share
it
with
us
Matt
a
sincere
request.
Please
do
not
get
that
we
are
merged
before
we
have
the
next
meeting.