►
From YouTube: EIPIP Meeting 29
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/57
A
the
first
item
on
the
agenda
is
network,
upgrade
process
review
and
some
proposed
changes
to
the
status
of
core
eip.
This
item
we
discussed
in
the
previous
meeting
and
with
the
present
model
I'm
trying
to
propose
some
changes
in
the
status
of
core
eip.
A
A
A
Right
so
the
last
meeting
we
discussed
that
generally,
the
last
call
is
suggested
to
be
for
14
days
only
so
there
were
one
con.
There
was
one
correction
that
I
recommended
that,
instead
of
having
the
last
call
for
14
days,
we
can
mention
it
as
a
minimum
of
14
days.
That
was
point
number
one
and
the
point
number
two.
When
we
are
sending
it
on
public
test
net,
then
we
mention
it
to
be
on
the
last
call
and
until
it
reaches
on
the
public
test
net,
let
it
be
in
review
status.
A
Sense
and
and
eip
will
be
considered
final
only
if
it
is
deployed
on
mainnet
for
the
proposals
which
are
actually
being
considered
to
be
deployed
on
the
mainnet
via
network
upgrade,
because
the
standardization
process
for
eip
and
network
are
different
now,
so
there
can
be
some
core
proposals
who
would
be
reaching
to
the
final
status
but
may
not
be
ever
being
deployed
on
the
main
net.
C
A
Right,
but
what
I'm
suggesting
here
is
like
if
we
are
planning
something
and
document
it,
we
can
at
least
reach
out
to
the
code,
or
maybe
the
author
of
the
eip,
suggesting
that
this
is
this
is
the
process,
and
if
we
go
by
this,
that
would
be
like
really
helpful
for
everybody.
Nobody
can
say
that
we
went
away
aware
that
the
proposal
is
in
this
status
and
it
is
going
in
the
upgrade
and
something
like
that.
That
happened
for
one
particular
proposal.
C
Yeah,
I
I
do
think
that
taking
off
my
eip
editor
hat
putting
on
a
wannabe
core
dev
hat,
I
think
that
anything
that
is
proposed
for
like
for
mainnet
should
be
in
review
by
the
time
it
gets
there
like.
We
don't
want
eips
that
are
still
under
active
development
by
their
authors
to
be
proposed,
like
you
should
be
confident
enough
in
your
your
ap
that
you
think
you're
done.
At
least
you
might
not
actually
be
done,
but
you
think
you're
done
before
you
bring
it
to
the
core
devs
and
waste
their
time
with
it.
A
Right
so
by
bringing
it
to
the
codex,
do
you
mean
the
consider
for
inclusion
phase,
because
my
understanding
is
even
if
it
is
in
draft
for
computer,
consider
for
inclusion?
It
must
be
in
review
when
it
is
approved.
If
a
coder
says
that
okay,
this
is
general
consensus,
we
can
think
about
it.
Then
it
should
be
in
review,
or
I
mean
it's
fine.
C
I'm
okay,
I'm
personally,
okay
with
cfi
being
in
draft,
because
mainly
just
because
we
don't
want
people
to
waste
a
huge
amount
of
time
before
they
get
just
like
a
general
consensus
from
the
dev
core
devs
saying
yes,
this
is
an
interesting
thing
to
us
and
to
me,
cfi
is
basically
the
core
dev
saying
yes
this.
This
is
interesting
to
us.
Go
go
finish
it
now
and
come
back
to
us
when
it's
ready
for
us
to
look
at
for
implementation
right
and
so
for
cfi.
C
If
this
is
going
to
be
immediately
rejected
by
the
core
devs,
it
would
be
nice
if
people
get
just
like
like
there's
a
bunch
of
core
aps,
you
know
where
people
craft
them
and
then
they
go
through
a
huge
amount
of
effort
to
get
it
past
me
and
then
they
finally
get
it
past
me
and
then
they
take
the
core
devs
and
the
core
devs
immediately
just
shoot
it
down
and
say:
no
we're
never
doing
that,
and
this
is
just
a
big
waste
of
time
for
that
that
author.
A
D
That
sounds
good
to
me
by
the
way,
sorry
about
that
I
actually
can
be
here
today.
Everyone
was
very
quick,
so
I
can
make
it.
A
Okay,
so
let's,
let's
keep
it
for
the
notes
taker.
The
suggestions
here
cfi
for
draft
network
upgrade
for
review
and
test
net
block
chosen.
That
is
actually
the
main
net
phase
in
the
last
call,
and
it
will
be
marked
as
final
only
on
when
it
is
deployed
on
the
main
net,
and
we
will
share
this
information
with
the
coder
as
well
hope.
There
should
not
be
any
objection.
A
Okay,
moving
on
the
next
item
on
the
agenda
is,
should
erc's
be
moved
to
a
separate
repo,
so
there
has
been
this
discussion
around
eips
and
ercs
should
be
in
different
repos.
We
discussed
it
briefly
in
the
previous
meeting
and
I
saw
some
conversation
on
the
ethereum
discord
channel
as
well,
so
maybe
like
client
or
mica.
If
anyone
would
like
to
take
a
lead
and
talk
more
about
it,.
E
Hello
hi:
we
can
hear
you,
okay.
I
was
still
connected
on
my
other
device.
Okay,
so
I
posted
on
the
discord
channel
based
on
the
conversation
for
the
last
eip
ip
meeting.
E
You
know.
For
that
reason,
in
other
reasons,
you
know
we
talked
in
the
last
meeting
about
what
if
we
had
what
if
we
took
the
ercs
and
we
put
them
in
their
own
separate
repository-
and
I
had
just
posted
on
discord
asking
like
what
does
it
take?
Who
whose
approval
do
we
need
to
get
to
make
that
happen?
I'm
happy
to
do
the
work.
I
I
don't
think
it's
gonna
be
too
difficult
to
me.
E
The
biggest
question
mark
would
be
there's
a
lot
of
permalinks
out
there
that
point
to
the
you
know
the
github
pages
we
can
redirect
the
eeps.ethereum.org
website.
All
the
ercs
can
be
redirected
to
their
correct
page,
but
we
can't
redirect
the
github
page
my
proposal
to
resolve
that
is
just
replace
every
erc
with
a
stub
that
just
says
this
has
been
moved
to
the
years.
He
requested
here's
the
new
link,
and
so
that
would
just
add
an
extra
level
of
indirection
for
anyone
trying
to
access
it
directly
on
github.
E
I
think
the
numbering
system
would
you
know,
we'd
have
to
have
some
way
of,
and
you
know
my
look,
the
lowest
tech
that
I
can
think
of
is
just
a
google
sheet
that
we
share
with
editors
and
that's
going
to
increase
the
burden
a
little
bit
because,
instead
of
just
looking
at
the
pr
number,
we
would
have
to
go.
Look
at
the
sheet
to
see
the
next
available
number.
E
I
think
that
that's
that
that
that's
just
asking
for
problems
in
the
future,
but
I
think
it's
worth
it
in
the
long
run
just
to
make
it
a
little
bit
harder
to
assign
a
number,
because
it's
going
to
be
a
lot
less
work
for
core
editors
who
don't
have
to
review
ercs,
and
then
we
can
really
bring
on
more
people
to
edit
ercs
and
actually
build.
C
C
E
C
Right
so
as
soon
as
they
as
soon
as
someone
like
editor
comes
in
and
says,
oh,
your
pr
number
is
20.,
so
use
erc20.
The
user
will
then
try
to
create
erc20
realize
conflict,
send
a
message
to
the
auth,
the
editor
saying:
hey,
there's
a
conflict.
What
should
I
do?
No,
the
editor
then
just
says
I'll
use
19
instead
or
whatever.
B
E
E
E
C
Yes,
but
the
the
total
number
of
ercs
that
are
actually
like
draft
or
higher
is
on
the
order
of
maybe
hundreds,
I
think,
I'll
check.
While
I
talk,
but
I
think
that
long
term
you're
going
to
end
up
with
more
simplicity,
if
you
just
continue
to
use
the
pr
number
numbering
scheme-
and
you
just
deal
with
those
100
or
so
conflicts
if
they
come
up
and
keep
in
mind
that
there's
a
very
good
chance,
they
won't
come
up
because
you
know
every
single
pr
increments.
C
That
number,
but
only
a
small
handful
of
those
are
actually
new
ercs,
and
so
I
think
that
you'll
just
end
up
with
a
small
number
of
conflicts
like
so
when
someone
comes
along
and
does
pr20.
If
pr20
happens
to
be
a
new
erc,
not
someone
updating
an
existing
rc,
then
they'd
have
a
conflict
and
then
we'd
do
a
one-off
fix.
For
that
one
say:
I'll
use
19.
Instead,
19
is
free.
A
I
have
a
suggestion.
I
don't
know
how
much
it
will
be
helpful,
but
I
was
wondering
like
not
all
pr
number
is
an
eip.
So
what
if
we
add
an
additional
step
for
the
ercs,
just
asking
them
to
create
a
pull
request,
stating
that
I
have
requested
for.
I
have
created
a
full
request
in
erc
repository
for
whatever
proposal
he
or
she
has
and
just
refer
the
pull
request
number
here
and
use
that
as
erc
number
there.
E
You
know,
issue
or
request
number,
and
you
know,
theoretically,
we
could
have
a
repo
ethereum,
slash
numbers.
I
don't
know
what
you
would
call
that,
but
you
know
you
could
just
say.
If
you're
going
to
open
an
erc
or
vip,
you
have
to
go
open.
An
issue
to
you
know
claim
a
number
that
kind
of
removes
the
burden
from
the
editors.
E
B
E
D
Yeah
and
like
the
the
precedent
we've
set,
is
that
ercs
are
eips
up
to
now,
so
changing
that
precedent
would
be
a
task.
It's
not
impossible,
but
like
maybe
taking
this
in
steps
so
like
the
first
step
would
be
finding
someone
who
even
wants
to
be
an
erc,
editor
and
then
have
them
start
doing
erc,
editing
in
the
main
repo
and
then
getting
the
resources,
meaning
funding
and
people's
time
to
split
out
the
repo.
That
would
be
a
whole
different
discussion.
F
One
additional
thought
I
had
in
since
we're
talking
about
splitting
ercs
from
core
dev
eips
is
there's
all
my
understanding
is
that
mica
and
light
client
get
harassed
with
a
bunch
of
people
trying
to
do
stuff
that
isn't
related
to
either
one
of
those
and
if
we
it
and
the
key
is
we
need
an
editor
for
erc's
and
we
and
and
and
maybe
we
could
have
a
miscellaneous.
So
we
have
three
different
locations.
F
But
eips
are
just
for
cores
anyway,
just
a
thought,
because
if
I
I
believe
you
instead
of
telling
people
what
not
to
do,
tell
them
a
better
thing
to
do
so,
if
people
that
there's
a
lot
of
people
that
want
to
do
that,
if
they
had
a
place
where
they
could
put
stuff,
that
would
take
some
pressure
off
the
editors.
I
would
think.
E
E
It
didn't
generally
tens
of
people,
you
know,
are
at
dap
level
developers
or
they're
kind
of
core
level
developers
and
there's
a
lot
of
noise
in
the
eep
repository
with
both
of
these
things
and
being
an
editor
having
notifications
on
seeing
the
noise,
it's
hot
can
be
tough
for
me
to
keep
up,
even
though
this
is
like
a
responsibility
that
I
signed
up
for.
If
I
was
just
a
community
member
who
wanted
to
follow
the
latest
and
greatest
core
developments,
the
latest
and
greatest,
you
know
erc
developments.
E
That
would
be
hard,
and
I
think
that
if
we
split
it
up,
that
would
generally
just
allow
this
kind
of
natural
boundary
that
already
exists
for
people
to
like
really
begin
to
be
more
involved
in
that
process
without
actually
having
a
role.
Just
you
know
tracking
what's
happening
and
you
know
being
a
part
of
the
the
governance
process
on
both
of
those
sides.
D
Oh
michael,
you
just
asked
what
point
you
got
cut
off.
I
I
didn't
hear
you
from
the
beginning.
So
if
someone
interrupted
you
mid-center
because
you
haven't
talked
oh
okay,
I
think
you're
on
now.
C
So
there's
only
a
few
hundred,
I
would
say
total
eips
and
a
portion
of
that
is
erc's,
and
so,
when
it
comes
to
numbering
schemes,
if
we
just
use
the
pr
number
like
we
do
with
the
erps
that
use
it
for
ercs
as
well,
except
for
be
the
erc
repo,
it
will
be
very
rare
that
we
actually
run
into
a
conflict
and
when
we
do,
we
can
just
handle
that
conflict
individually,
and
I
think
overall,
that
will
be
the
least
amount
of
work
for
erc
editors
in
general,
just
because
conflicts
are
rare
and
when
they
happen,
they're
very
easy
to
resolve,
and
that
way
the
numbering
scheme
for
the
common
case
is
very
simple.
C
Yeah
so
we'll
start
with
the
erc1
and
there's
like
a
99
chance,
we'll
skip
20,
naturally,
because
that's
just
how
the
numbering
system
works,
it
is
not
incrementally
increasing.
Like
eip,
you
know,
20
exists
and
55
exists
and
nothing
in
between
the
two
exists.
As
yeah.
We
start
with
erc
one,
and
then
there
would
be
an
erc.
You
know
maybe
35
and
maybe
in
year
c
72,
I'm
assuming
the
pattern
is
similar
to
eips
and
every
now
and
then
there'll
be
a
conflict,
but
it'll
be
very
rare.
I'm
guessing
one
or
two
total.
A
How
did
agree
to
that?
So
if
we
have
to
start
this
like,
we
should
be
starting
from
this
point
onwards,
not
going
to
the
back
number.
That
would
be
my
first
suggestion
and
using
the
same,
like
you
know,
getting
the
pr
number
would
be
a
better
idea.
It
would
not
ever
let
us
to
any
kind
of
conflict,
because
it's
just
an
request.
That
is
there
an
empty
kind
of
just
mentioning
that
there
is
a
relevant
erc
that
people
can
go
and
refer
to
if
they
want
to.
E
I
I
just
think
that
we've
already
said
this
precedent
that
ercs
and
eaps
are
kind
of
very
similar
they're
in
the
same
repos.
They
have
different
numbers
and
it's
going
to
be
hard
enough
to
try
and
tell
everyone
hey.
This
is
a
totally
different
thing.
Now,
ercs
are
their
own
thing.
There's
you
know.
Maybe
in
the
future
they
can
have.
The
numbers
could
conflict,
but
I
I
just
think
in
the
in
the
beginning,
I
I
really
don't
think
it's
that
much
extra
work.
There's
you
know
I
think,
there's
two
good
ways
to
do
it.
B
C
The
problem
with
that
is,
you
don't
solve
the
one
of
the
bigger
problems
which
is
email
notifications
like
I,
I'm
currently
subscribed
to
all
the
heal,
eips
repo.
So
that
way,
anytime
someone
comes
in
with
a
new
pr.
I
notice
it
and
if
we
add
them
in
one,
then
I
still
get
all
the
erc
ones
and
on
the
escalator
it
still
gets
all
the
ip
ones.
C
I
mean
you
can
set
up
like
a
github
github
action
that
fires
web
hook
anytime,
a
pr
is
made
and
you
can
even
set
it
up
to
automatically
do
the
numbering
so
get
the
humans
out
of
the
numbering
system.
Of
course
that
requires
engineering
effort,
and
that
is
something
we
are
very
short
on
in
this
group.
E
Yeah,
I
mean
definitely
we
can
have
bots
do
this.
This
is
a
very
simple
thing
to
have
written.
Obviously
it
has
to
be
written.
I
don't
think
we
have
the
time
to
specifically
do
it
at
this
exact
moment,
but
that's
what
I'm
saying.
I
think
that
you
know,
starting
with
a
spreadsheet
and
then
eventually
having
someone
go
in
and
turn
that
into
a
part
of
the
merge
bot
that
would
be
back
to
the
same
level
of
effort
required
or
less
today.
A
I
don't
know
if
github
repository
supports
with
the
help
of
label.
I
mean
like
if
we
start
labeling
it
as
erc
in
the
beginning,
if
somebody
is
creating
a
pull
request
and
that
helps
like
with
the
notification
that
you're
receiving
I'm
not
sure
that,
by
the
way.
D
Yeah,
so
just
to
go
over
what
we've
kind
of
decided,
we
definitely
want
to
split
editorship
into
eip
versus
erc.
We
are
heavily
leaning,
if
not
pretty
much
decided,
they
should
be
split
out
by
repo.
What
we're
stuck
on
is
once
they're
split
out
by
repo.
D
Okay,
so
I
think
a
better
option
would
be
for
people
to
come
up
with
proposals
when
we
make
an
issue
in
the
eipip
repo
or
like
where's,
the
stuff
discussed,
there's
an
eipip
repo
yeah.
So
I
can
make
an
issue
for
that
and
put
it
in
in
here.
It's
like
ethereum
dash
cat
dash,
herder,
slash,
e-I-p-I-p
and
github.
D
I
think
that's
good,
and
then
we
can
move
on
to
other
stuff.
Unless
someone
wants
has
like
a
final
thoughts
on
this.
C
D
I
think
it's
we
should
try
out
with
erc's
and
learn
from
that
and
then
split
it
out
further.
If
well,
I
don't
know
maybe
doing
it
all
at
once
would
work,
but
I
don't
think
there's
very
many
how
many
interface
and
networking
eips
are
there.
I
don't
think
there's
that
many,
that
it
would.
C
Yeah,
I
agree.
I
tend
to
agree
with
that.
Core
networking
are
very
tightly
related.
Interface
is
a
different
set
of
people
so
like
metamask,
and
basically
all
the
wallet
providers
care
a
whole
lot
about
the
interface
section,
as
do
core
developers
as
do
dab
developers,
and
so
interface
is
like
it's
a
very
appropriate
name.
C
It
is
the
interface
between
all
three
layers
and
they
care
about
all
three
very
much
so
maybe
that
one
pulling
it
out
just
again,
so
we
can
have
people
can
don't
have
to
get
the
core
eips
if
they
just
care
about
interface,
stuff.
E
A
So
yes,
sorry.
A
I
think
I
think
that
was
background
noise.
I
think
we
have
to
create
an
issue
on
eipip
get
our
repository,
stating
that
we
would
like
to
start
with
erc
to
be
in
a
separate
repository,
and
then
maybe
I
don't
know
if
elite
I
just
mentioned
in
the
chat,
if
we
can
have
some
documentation
of
the
requirement
for
both
bot
that
we
discussed.
If
that
has
to
be
done
with
the
help
of
bot.
D
And
oh,
did
we
did
anyone
discuss
about
losing
like
historical
hit
like
history,
between
behind
like
the
older
eips
and
stuff?
Would
we
just
close
all
the
previous
prs
and
issues
and
they'd
still
be
in
the
eip
repo.
E
A
A
Cool
so
moving
ahead.
The
next
item
on
the
agenda
is
progress
on
the
eip
github
ripple
action
part
I
believe
alita
is
working
on
that
and
there
is
an
issue
for
collecting
some.
You
know
requirements
for
debate
that
is
issue
number
59.
In
the
same
repository
anytime,
you
would
like
to
provide
some
more
update
on
it.
G
Sure
so,
right
now
the
bot
is
waiting
on.
I
forget
who
exactly,
but
basically
we're
waiting
on
transferring
the
exact
bot
to
a
ethereum
controlled
repo.
It's
currently
in
a
private
repo.
The
actual
merge
bot
like
where
it's
used
on
the
main
eip
repo
is
not
merged.
Yet
I
think
that
there's
a
small
change
that
needs
to
be
made
and
we're
still
trying
to
figure
out
like
manual
stuff
for
the
eip
bot
itself,
the
from
stuff
we
discussed
last
week.
G
Our
last
meeting
I
have
implemented
like
the
testing
framework
for
it,
and
then
I
have
created
a
new
issue
for
okay,
so
I
have
interfaced
like
the
eip.
Merge
bought
its
own
repo,
so
that
way
we
can
more
easily
managed
it.
G
D
Great
job
and
did
we-
I
don't
see
it
written
anywhere,
how
much
the
cad
herders
are
paying
for
this,
and
I
want
that
like
down
somewhere.
So
we
know
how
much
to
pay
you
for
your
work
is
that
somewhere.
G
No,
no,
I
I
actually
created
a
funding
request
in
the
cat
herders
and
that
references.
The
video
that
like
got
me,
started
on
it,
which
was
seven
thousand
usd
so
and
then
for
future
funding
like
because,
because
I'm
considering
getting
it
up
and
running
with
like
the
features
that
were
initially
requested
and
like
transferring
over,
including
the
testing
included
in
the
7000.
G
Just
because
I
don't
know,
I
want
to
make
sure
it's
good,
but
any
future.
Like
features
and
stuff,
I
will
make
like
the
idea
behind
the
requirements
document
is
to
get
everything
in
one
place.
So
then
we
can
create
a
like
a
thorough
proposal
for
funding
to
get
those
in
place
as
well.
A
Not
issue,
actually
it
was
a
response
somewhere
in
the
eip
github
repository
itself,
in
which
we
kind
of
calculated
like
how
much
the
work
is
required
and
how
much
should
be
the
funding.
Maybe
I
would
share
that
link.
G
Yeah,
you
could
transfer
over
and
then
well.
Actually
I
have
two
requests.
Can
I
please
be
made
a
contributor
to
the
eips
repo,
because
it
would
be
nice
to
be
able
to
branch
off
of
that
because
I'm
probably
making
changes
to
the
bot
once
once
it's
put
in
like
if
I
want
to
change
the
version
or
something
on
it
and
then
but
yeah.
G
So
then
we
also
need
to
transfer
the
current
bot,
which
is
a
lead
or
a
leader,
dash
more
eip
bot,
which
I
can
link
that
one
needs
to
be
moved
to
an
ethereum
control
repo,
which.
D
That
all
sounds
good
to
me,
so,
just
to
be
clear,
we
don't
have
contributor
access
on
the
eips
repo.
The
three
roles
we
have
are
read:
write
and
admin,
because
we
are
on
an
old
github
plan,
that's
cheaper
for
us.
So
would
you
need
write
permissions
to
read,
clone
and
push
to
the
repository
and
manage
issues
in
pull
requests?
Or
would
you
need
admin
to
also
change
settings?
I
don't
know
if
I
need
admin.
D
Okay,
put
your
username
in
the
zoom
chat
if
you're
not
on
mobile
and
I'll
make
you
write
permissions
right
now
and
then
message
me
on
discord
and
we'll
in
the
next
few
days
get
that
transferred
sure
all
right
awesome.
Thank
you.
A
Just
one
last
comment
from
the
camera
side:
like
do
let
us
know
whenever
everything
is
done
like
when
bot
is
merged
and
when
we
have
to
make
the
payments
so
just
gives
us
a
heads-up.
G
I
mean
I
submitted
the
funding
request.
The
bot
is
like,
I
guess
mostly
done.
I
have
some
like
polishing
to
do.
I
don't
know
if
we
want
to
wait
for
that
to
be
done.
I
know
I'm
waiting
on
a
final
review
from
micah
like
essentially
it's
kind
of
a
continuous
process.
So
I
don't
know
if
there's,
if
there's
a
clear
line
in
the
sand
like
in
my
opinion,
it
feels
like
the
initial
task
was
done
and
I'm
just
polishing
right
now.
What
do
you
think
or
you
all
think.
D
My
opinion
would
be
after
micah's,
final
review,
if
that,
if
he
says
it's
all
good
and
there's
no
last-minute
fixes
that
were
part
of
the
initial
set
of
either
requirements
or
expectations,
then
I'd
say
we
can
pay
out.
Then,
with
the
expectation
that,
for
we
don't
pay
anymore
for
you
actually
installing
it,
because
I
think
that
was
part
of
the
initial
stuff
right.
G
Oh
yeah
for
sure
yeah.
D
C
C
I
think
oh,
but
this
particular
bot
needs
to
know
the
pr,
because
it's
gonna
merge.
I
see.
Well,
that's
annoying.
Okay
and
the
do
you
remember
what
the
other
one
was.
G
Oh
yeah,
that
the
other
one's
done
it
was
talking
about
not
referencing
master,
so
yeah,
the
the
the
bot
on
its
own
separate
repo,
has
a
versioning
system
and
it's
using
the
version.
So
that's.
C
Easy
just
send
at
mention
me
in
the
pr,
so
I
can.
It
gets
added
to
my
inbox,
which
will
cause
me
to
then
look
at
it,
and
I
can
do
it
final
review.
G
Done
and
then,
as
far
as
the
the
manual
thing
goes,
I
mean
there
are
definitely
solutions,
it's
kind
of
hard
to
do
that
async.
So
maybe
we
can
have
a
call
or
something
like
today
or
tomorrow.
C
And
what
I'd?
What
I
ultimately
really
like
is
a
way
that
we
can
dip
our
feet
in
with
it
and
migrate
to
it
slowly,
and
so
we
can
basically
test
to
make
sure
it's
doing
what
we
think
it
should
do
and
then,
once
we've
validated
that
it's
doing
everything
we
think
it
should
do
in
the
production
environment.
G
Okay,
I
will
implement
some
way
of
do
manual
like
the
one.
Okay,
maybe.
C
C
If
we
can
just
have
it
go
green
or
red,
then
I'll
at
least
see
did
the
the
bot
think
it
wanted
to
merge
or
to
think
that
it
shouldn't
merge.
Then
we
can
do
run
that
for
like
a
week
or
two
and
then,
if
it
looks
like
it's
correctly,
going
green
and
correctly
going
red
at
the
appropriate
times,
then
we'll
flip
the
switch
and,
if
and
actually
enable
merges,
and
if
not
we
can
fix
whatever
bugs.
C
I
mean
documentation
is
always
nice,
but
at
the
same
time
I
would
rather
elita
spend
her
time
on
more
useful
tasks,
given
there's
like
maybe
three
people
that
actually
ever
use
it.
G
So
there
is
some
documentation
on
the
bot.
Like
the
code
itself,
I
mean
it's
well
commented
and
everything
I
fully
intend
on
doing
like
a
full
test
suite
for
it.
Just
because
I
mean
I
want
it
to
be
scalable
but
like
essentially,
what
kind
of
documentation
are
you
referencing.
A
I
know
I
was
just
mentioning
that
if
any
kind
of
documentation
is
needed
for
people
to
refer,
maybe
in
future,
if
they
have
to
fix
anything
or
something
like
that,.
G
Yeah,
the
bot
itself
is
written
in
a
way,
that's
readable,
with
clear
documentation
on
con
contributing.
So
I
think
that's
good.
Oh
cool.
A
Okay,
so
in
the
sense
of
time
should
we
move
ahead
with
next
agenda
if
everyone
is
funnier?
A
Okay.
The
next
item
is
the
the
eip
standardization
process,
so
we
had
this
meeting
for
eib1474
or
that
that
was
basically
for
rpc
standards
for
ethereum
jason,
rpc
standards
and
two
things
were
proposed
in
the
meeting
one
like
this
standard.
This
proposal
particularly,
is
never
going
to
achieve
a
final
status
because
there
is
always
going
to
be
room
for
some
improvement.
A
So
should
it
follow
the
normal
eip
standardization
process,
or
should
it
be
granted
some
kind
of
special
access,
or
maybe
you
know
going
with
a
special
status,
maybe
living
or
there
was
another
proposal
of
converting
it
to
a
meta
eip,
because
it
would
be
kind
of
template
for
every
client
to
implement
in
the
way
they
want
to,
because
not
every
client's
implementation
for
json
rpg
standards
are
exactly
the
same.
C
My
personal
preference
is
take
this
opportunity
to
try
out
a
specification
system
closer
to
like
what
eth2
has
where
we
have
a
repository
that
defines
a
specification
and
then
pr's
to
that
repository
is
the
change
control
process
and
then,
when
a
pr
is
merged,
the
repository
just
shows
the
latest
version.
C
I
feel
like
that
works
really
well
for
documents
that
tend
to
live
over
time.
That
being
said,
I
don't
actually
think
the
json
rpc
should
be
a
living
document
at
all,
like.
C
C
So
json
rpc
specifically
definitely
needs
to
be
specced
out
somewhere
like
it
needs
to
be
documented.
Currently
it's
documented
in
five
different
places
and
is
documented
poorly
and
the
people
who
own
the
documentation
are
not
necessarily
the
people
who
care
about
the
the
specification,
and
so
it's
not
great.
The
current
situation
1474,
if
I
remember
correctly,
tries
to
move
all
of
it
into
an
eip
kind
of
wholesale
at
once,
which
I
have
spoken
out
weekly
on
like
loosely
against
that
saying
that
it
should
really
be
multiple
eips.
C
C
C
I
don't
think
trying
to
have
this
one
monolithic
eip
that
then
just
mutates
over
time.
Does
anybody
any
good,
because
then
you
have
immutable
standard
and
mutable
standards
are
not
standards.
So
therefore,
they're
not
useful
as
a
standard.
Again
I
would.
This
is
a
good
up.
I
I
still
think
this
is
a
good
opportunity,
though,
to
try
other
things
besides
eaps
like
there
are
currently
there's
basically
other
than
this
eip.
C
There's
no
work,
that's
been
done
historically
or
very
little
on
standardizing
interfaces,
there's
some,
but
not
a
whole
lot,
and
so,
unlike
core
eips
moving
out
of
the
earpiece
repo,
I
don't
think
would
be
hard,
and
so
I'm
going
you
know
trying
something
new
like
a
like:
eth2
is
doing
with
a
github
repo
that
it
just
has
prs
against
it.
Maybe
is
a
better
solution.
A
I
Yeah
hello.
Yes,
that
sounds
like
an
interesting
proposal.
I
I
I
caught
the
I
I
caught
the
very
tail
end.
I
think
so.
The
suggestion
that
we
may
want
to
do
something
like
h2
is
doing
and
having
a
pr
dedicated
to
the
json
rpc
interface
that
accepts
prs.
C
Yeah
so
basically
have
a
github
repo
that
contains
the
specification
and
then
the
change
control
process
would
just
be
prs
against
that
repository
and
the
entire.
That
is
the
entire
change
control
process.
So
pr
would
want
to
submit
if
they
want
to
submit
a
change
gets
reviewed
by.
However,
many
people
that
pr
lives
for
a
reason
amount
of
time
to
make
sure
there's
time
for
people
to
get
feedback
on
it
and
then,
when
the
pr
is
merged.
C
I'm
fine
with
that,
I
think
that's
a
great
place
for
it
to
live,
and
this
would
be
a
good
opportunity
to
try
to
kind
of
start
using
eth10
specs
repository
for
this
exact
sort
of
thing
and
then
maybe
one
day
we
can
enter.
Then.
If
this
works
successfully,
I
can
dream
at
night
about
how
one
day
the
core
dev
change,
control
process
goes
through
the
same
system,
and
these
will
know
specs.
B
When
the
merge
happens,
those
repos
should
merge
too,
and
the
e2
specs
repo
is
like
much.
I
guess
more
much
bigger.
It
has
more
content
than
the
eth1
specs
repo,
so
I
suspect
in
the
next.
Like
I
don't
know,
six
months
or
maybe
a
year,
the
ethonospex
repo
will
probably
get
merged
into
the
e2
specs
repo
and
and
given
like
the
scope
of
both
the
east.
One
would
be
this
one
that
moves
over
yeah.
So
I
just
want
to
point
that
out.
B
B
And
then
maybe
we
removed
it
yeah
and
moving
the
ethospex
repo
is
not
long.
You
know,
I
could
probably
do
it
in
a
day,
but
I
think
it's.
C
You
know
yeah
the
moving.
The
pr
is
the
hard
part
like
if
we
do
do
this
pr
change
control
process,
then,
like
it's
nice
to
have
the
pr's
living
in
the
right
place
from
the
beginning.
B
B
So
I
guess
my
fear
is
like,
or
my
perception
of
their
fear
is
maybe
I
I
don't
know,
I
think
danny
ryan
is
the
one
who
would
want
to
ask
about
it.
Like
I'm
curious,
I'm
just
looking
at
the
commit
history
right
now
and
it's
like
danny,
ryan
and
and
xiaowei
are
like
80
of
the
commits,
and
I
guess
proto
is,
like
you
know,
number
three,
a
distant
third,
but
like
yeah,
shawway
and
daddy
ryan
are
really
like
the
biggest
committers.
So
I
think
just
asking
the
two
of
them
is
probably
yeah
good
approach.
B
I
don't
mind
asking
I
don't
mind
asking:
I
guess
what
what
I
would
would
be
useful
to
know,
along
with
the
ask,
is
like
what
are
the
specific
changes
we'd
want
to
do.
You
know
because
that'll
be
the
hard
part.
If
I
tell
them,
can
I
move
five
markdown
files
over,
I
suspect
they'll
say
yes,
if
I
tell
them,
can
we
change
how
you
handle
pr's,
I
suspect
they'll
say
maybe-
and
this
is
the
hard
conversation
right
right.
B
So
I
you
know,
I
think
it
yeah.
Maybe
the
best
way
to
go
is
like
for
us
to
and
us
I
feel
like
I'm
putting
work
on
other
people
than
myself
right
now,
but,
like
yeah
till
I
kind
of
write
down
what
we
want
and
then
bring
all
of
that
to
them.
Rather
than
just
like,
can
we
merge
the
two
repos,
which
is
a
bit
disingenuous.
C
Some
of
those
are
already
in
the
two
specs
repo.
So,
however,
they
have
it
laid
out.
Maybe
we
could
kind
of
merge
in
with
that
again,
assuming
everybody
is
on
board
with
this
general
idea
eric.
Does
this
general
idea
sound
good
to
you
not
quite
sure
how
much
sarcasm
there
was
in
your
statement
earlier.
I
None
whatsoever,
I
think
I
think
this
will
be
well
received,
because
one
of
the
main
concerns
that
have
been
raised
during
the
like
json
rpc
groups
meetings-
is
that,
like
like
it
particularly
from
the
client
teams
they're
like
wait,
you're
saying
that,
like
we're
going
to
be
held
up
by
the
eip
process
to
like
create
or
change
methods,.
C
I
C
B
We
talked
a
bit
earlier
about
splitting
up
the
eip
repo
for
notification
spam
I
feel
like
if
we
merge
the
eth1
specs
e2
specs
and
json
rpc
all
together,
then
we
are
back.
You
know.
Xiaowei
doesn't
want
to
hear
about
new
json
rpc
calls
and
people
in
yeah.
C
C
Yeah,
that's
very
valid,
it's
a
good
point,
yeah,
so
fallback
suggestion
then
would
be.
I
don't
know.
Ethereum
interface,
specs,
repo
or
something.
B
Yeah,
I
think
I
feel
like
there's
I
don't
know.
Maybe
it
makes
sense
to
actually
keep
them
separate
for
now
and
have
yeah
one
for
the
json
rpc,
which
is
like
the
interface
e1
and
e2,
and
then
after
the
merge,
we
can
merge
each
one
into
e2
and
then
and
and
then
you
know,
there
won't
be
any
more
changes
to
each
one
after
right,
like
or
whatever
changes
they'll
be
they'll,
be
across
the
merged
clients
right,
they
won't
be
just
across
each
one.
C
Other
protocols
like
grpc,
if
once
an
artem,
gets
his
way
or
we
have
rest
for
the
consensus
application
layer.
I
think
they
use
rest
for
their
communication
and
it
feels
like
all
those
things
should
go
in
this
repo
like
this
is
the
repo
for
how
various
pieces
of
the
system
talk
to
each
other,
essentially
yeah.
That's
what
I'm
imagining
at
least.
C
That
is
in
my
head.
That's
what
I'm
imagining,
because
that
that
still
is
an
interface
which
is
between
dap
and
wallet.
Right
and
you've
got
the
interface
between
wallet
and
client.
You've
got
the
interface
between
application,
client
and
consensus
client.
You
have
the
interfacing,
condenser,
client
and
wallets
like
each.
C
We
could
split
each
of
those
connections
out,
but
I
worry
that
we'll
end
up
with
people
being
confused,
especially
since
there's
some
overlap
like
the
dap
wallet
and
wallet
clients,
application,
client
interfaces
are
very
similar,
like
they
share
a
lot
and
so
splitting
it
apart
into
like
one
repo
per
like
pair
of
things,
feels
like
that's,
not
quite
the
right
solution,
and
so
that's
why
I'm
thinking
one
one
repo
for
all
of
it
open
to
other
radios,
though
yeah.
I
Now
I
think,
I
think
that
makes
sense.
A
Okay,
to
conclude,
for
this
particular
item
like
we
have
to
wait
for
some
time,
and
maybe
when
we
are
getting
more
clarity
on
how
to
merge
with
the
each
one
and
e2
spec
as
the
ethereum
spec
repository,
then
we
will
proceed
with
like
creating
a
pull
request
there
and
having
that
living
there.
On
that
repository
itself.
A
Yeah,
because
I
understand
that
we
are
not
planning
to
have
the
json
rpc
spec
on
the
eat,
one
spec
repository,
so
it
will
be
created
on
the
each
two.
Only
directly.
There.
C
No,
no
so
the
the
current
thinking
for
tim's
feedback
long
ago,
we've
pivoted
very
rapidly.
The
current
thinking
is
now
have
a
new
repository
that
is
just
for
interfaces.
Basically,
oh.
A
Sorry,
sorry
yeah,
I
got
it
no,
I
I
just
messed
with
yeah
okay,
so
we
have
just
a
few
more
minutes
left
eric.
Do
you
have
any
more
questions.
I
Or
I
I
don't
at
this
point,
I
really
appreciate
that
you
guys
decided
to
talk
about
this
and
I
think
the
solution
sounds
good.
A
F
Okay,
yeah
yeah.
We
have
made
a
little
bit
of
progress.
We
got.
One
of
our
engineers
got
the
jekyll
system
running
on
his
personal
system
and
now
we're
moving
that
to
a
public
system
and
once
we
get
that
up
and
running,
then
we'll
have
a
staging
area
where
we
can
stage
proposed
changes.
So
don't
have
a
lot
of
time,
but
we're
making
some
progress.
A
Sounds
good,
so
I
know
many
people
have
to
drop
now
to
join
the
other
call
and
we
have
almost
had
the
time.
So.
Thank
you.
Everyone
for
joining
us
today
see
you
all
in
next
two
week
on
april
7th
and
the
timing
will
be
15.
1500
utc
will
be
back
on
our
usual
timing.