►
From YouTube: EIPIP Meeting 28
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/56
A
Welcome
to
eipit
meeting
28.,
I'm
puchar
ranjan.
The
first
item
on
the
agenda
is
progress
on
eip
github,
repo
action
bot,
so
alita
more
from
the
ech
team,
is
working
on
the
eip
github
repo
and
I
suppose
she
also
created
a
full
request
to
you-
know-
share
this
bot
for
review
with
the
eip
editors.
The
pull
request
number
is
three
three
five
one.
A
C
C
I
mean
most
most
github
actions
that
people
use
are
you
know
public
actions
and
a
separate
repo,
and
you
only
add
it
to
your
yaml
file
in
the
github
workflow
folder.
D
E
Yeah,
you
guys
have
been
talking
about
it,
it's
more
related
to
mine.
So
I'll
just
wait
till
we
get
to
my
item
and
I'll.
Do
it
all
at
once.
A
The
next
item
on
the
agenda
is
network
upgrade
process
review.
So
there
were
some
questions
comments
on
the
network
upgrade
process
in
the
all
code,
discord
channel
last
week
that
surfaced
with
with
respect
to
eip2315,
regardless
of
the
decision
taking
for
that
proposal.
I
want
to
address
some
comments
that
was
specifically
related
to
the
network,
upgrade
process
that
we
came
up
with
recently.
A
So,
as
per
my
understanding,
it
was
mainly
related
to
two
things
number
one.
Many
people
are
still
not
aware
of
the
process
and
number
two.
The
network
upgrade
process
could
be
modified
to
enforce
the
review
status.
That
is
a
fairly
new
status
to
be
a
mandatory
status
at
or
before
it
is
a
cfi
approved.
A
So
for
the
first
point
like
people
are
not
aware,
I
think
we
need
to
be
a
little
more
vocal
about
that
and
create
more
awareness
about
the
new
process
and
encourage
authors
of
at
least
core
eips
to
follow
the
process.
A
As
far
as
point
number
two
is
there,
I'm
proposing
some
changes
to
the
current
process.
There
is
a
link
in
the
agenda
that
people
can
follow
like.
I
have
been
meaning
to
propose
this
earlier,
but
I
believe
it's
not
too
late
to
start
now
as
well.
I
came
up
with
these
suggestions
based
on
some
conversation
with
micah
at
different
places
regarding
the
last
call
and
the
final
status
for
core
eips,
so
I'm
proposing
this
new
structure
if
we
can
get
some
feedback
on
that.
B
So
this
was
the
oh
github
issue
in
the
comment
right.
B
Oh
okay,
sorry
I
was
reading
this
mess.
This
comment
wrong.
You
these
this
diagram
that
you
put
into
the
comment
is
the
proposed
changes,
not
the
current
state
right.
A
Right
so
in
the
diagram
below,
if
we
see
that
I'm
proposing
that
consider
for
inclusion
could
be
eip,
status
could
be
draft
till
review
and
devnet
phase
that
we
consider
the
eip
status
has
to
be
review
only
and
when
it
goes
to
main
net
phase.
The
first
part
should
be
review
to
last
call
and,
as
micah
was
suggesting,
that
we
should
not
put
final
status
on
any
core
eip
unless
it
is
deployed
on
the
main
net.
So
if
it
is
on
mainnet,
then
only
we
provide
the
status
of
finance.
So
this
is
the
proposal.
B
I
thought
we
got
rid
of
final
or
changed
the
definition
to
separate
the
the
upgrade
process
from
the
technical
process.
D
G
G
B
You
failed
earlier
so
that
should
be
in
devnet
phase,
because
if
it's
in
mainnet
phase
we're
it's
already
so
late
in
the
process
that
we
don't
want
things,
I
mean
a
lot
of
people
wait
until
last
call
to
actually
like
do
any
final
reviews
and
people
put
it
off.
So,
if
they're
doing
that
already,
then
wait
until
the
main
net
phase
seems
counter-intuitive.
G
I
think
people
do
that
did
that,
because
we
did
not
have
a
review
phase.
We
only
had
draft
last
call
final,
basically,
and
so
there
was
no
like
no
phase
where
the
author
asserted.
I'm
done
it's
now
time
for
people
to
look
at
this
before
it
goes
live.
There
is
just
like
I'm
working
on
this
and
then
it's
going
live
in
two
weeks
like
that
was
the
only
step.
Previously.
G
We
now
added
the
review
step,
which
is
so
we
now
have
I've
worked,
and
then
I'm
done
working
on
this,
or
at
least
I
think
I
am,
I
need
feedback
and
then
I
personally
think
the
last
call,
as
I'm
done
with
this.
I've
received
feedback.
I've
iterated
everybody
thinks
this
is
good.
This
is
your
last
chance
to
speak
up
like
to
stop
the
ship,
like
the
ship's
already
taken
off.
If
you
want
this
last
chance
to
stop
that
kind
of
thing,.
G
Well,
so
the
stop
the
ship
would
be
like
security
vulnerability
like
in
my
opinion,
once
you
go
into
last
call.
It
should
really
your
especially
core
ips
should
really
be
done
like
this
should
be
the
like
for
lack
of
a
better
word.
It
is
the
last
call
like
it
is.
Everything
is
done
like
there's,
there's
no
more
changes
like
this
is
the
last
chance
for
anyone
to
speak
up
like
speak
up
or
forever
hold
your
peace
sort
of
situation.
G
With
the
four
o'clock
decision.
B
Yes,
ercs
are
terrible
and
shouldn't
be
a
part
of
the
process.
So
so
so
the
thing
is
because
I
love
that,
but
because
well
we
shouldn't
it
shouldn't.
Ideally
that
shouldn't
be
the
case,
but
right
now
I
feel
like
unless
we
really
push
people
to
change
their
definition
of
last
call
for
both
ercs
and
core
eips.
B
B
I
think
eips
should
be
yeah.
That's
that's
weird,
because
we
don't
have
a.
I
don't
want
to
add
another
status
in
between
there,
necessarily
because
that's
adding
too
many
statuses.
But
yes,
I
I
agree
that
I
think
the
original
idea
for
last
call,
because
nick
johnson
put
it
in
so
a
lot
of
people
are
going
off
of
his
definition,
which
is
during
last
call.
If
there's
anyone
who
has
objections,
they
can
raise
those
objections
and
there's
not
any
implication
that
it
has
to
be
a
security
objection.
B
C
G
Suspect,
nick,
if
nick
put
this
in,
he
was
modeling
off
of
like
ietf
and
rfcs
and
all
those
and
those
ones
by
the
time
they
hit
their
last
phase
like
there's
almost
never
any
changes
when
there
is
it's
really
small
like
it's
like
you
know,
a
minor
tweak
like
a
constant
kind
of
thing.
The
problem
is
with
ethereum
eips.
G
We
are
not
nearly
as
good
as
those
people
at
making
specs,
and
so
by
the
time
we
get
to
last
call
like
you
said
there
are
a
lot
of
people
who
haven't
even
bothered
looking
yet,
whereas,
if
you
look
at
say
w3c,
you
know
when
javascript
hits
their
last
phase
like
a
javascript
change
or
a
browser
change
gets
to
the
last
phase,
like
there's,
really
no
opportunity
to
make
any
significant
changes
at
that
point,
like
it's
already
gone
through
years
of
iteration
and
it's
implemented
in
every
browser
and
like
it's
all
but
done,
and
the
that
last
phase
is
basically
we're
pretty
confident.
D
Say
we
do
put
last
call
for
dev
net
and
then
we
find
something
in
the
dev
test
map
that
should
be
worth
editing.
The
ap
like
at
that
point
like
if
we
put
in
the
last
call-
and
it
was
three
weeks
after
instead
of
two
weeks
after
like
would
it
be
messing
up
the
process
to
have
an
eip.
That's
final,
but
we
have.
We
found
something
in
the
dev
test
that
that
we
should
update
the
ap.
G
So,
for
last
calls
the
review
end
period
for
the
way
I've
been
treating.
It
is
not
optional,
but
it's
like
the
minimum
review.
It's
like
the
early
assistant
will
be
merged
as
two
weeks
later
or
whatever
date
the
person
puts
in.
B
G
Final
means
that
you
can't
change
the
ip,
because
remember
the
erp
process
is
uncorrelated
with
from
the
point
of
the
view
of
the
eap
process,
it's
uncorrelated
with
the
hardcore
coordination
process.
So
once
your
eip
is
in
final,
you
cannot
change
it
like.
If
you
want
to
change
it,
you
create
a
new
way
yeah
with
a
new
number,
and
you
know
maybe
it's
copy
and
paste,
which
is
the
minor
tune.
But
it's
a
new
thing
like
you,
don't
get
the
number
anymore.
G
It
makes
the
most
sense
for
court
efps
to
wait
until
they're
on
main
net
before
they
go
into
that
phase,
because
it
would
suck
to
have
an
effect
go
final
and
then
you're
not
able
to
change
it,
because
it's
already
done
basically
we're
trying
to
avoid.
I
don't
know
if
you
guys
all
remember
this,
but
the
keck
act.
256
versus
shot
three
situation
where
k
256
was
standardized.
Everybody
thought
it
was
done,
but
it
wasn't
actually
final
in
terms
of
standards.
G
Organizations
like
whoever
does
the
crypto
standards
and
then
ethereum
was
like
okay,
we're
using
sha3
and
we
launched
and
then
like
at
the
very
last
minute,
the
crypto
organization,
what
they're
called
they're
like.
We
actually
want
to
change
this
one
little
like
thing
like
it
was
a
tiny
change,
but
it
is
totally
incompatible
with
the
sha-3
that
ethereum
launched
with,
and
so
now
we
have
keck
act,
256,
which
is
not
even
a
standard.
G
It's
just
a
thing
that
would
everybody
thought
was
going
to
be
the
sha-3
standard
and
didn't
actually
end
up
being
standard,
and
so
we
want
to
avoid
that
situation,
and
so
one
way
to
do
that
is
to
make
it.
So
you
know
things
aren't
final
until
they're
live,
so
we
can
make
those
last
minute
changes
and
not
have
to
worry
about
running
running
into
collisions
and
all
that.
B
But
if
we
do
it
the
way
we're
currently
doing
it,
we
won't
be
able
to
make
those
last
minute
changes
without
breaking
test
nets
along
the
way
or
having
to
rush
client
releases.
So,
although,
like
the
idea
is
right
like
basically,
the
intention
is
good,
I
think
in
practice
it's
gonna
be
hard
to
break
old
habits.
This
quickly.
G
So
yeah,
so
I
can
appreciate
that,
and
so
that's
what
I
was
asking
kind
of
is:
are
people
disagreeing
with
the
ideal
long-term
process
or
is
the
fear
that,
given
ethereum's
history
and
people's
historic
behavior
we're
worried
that
the
current
process
will
not
equal
the
process
we
want?
It
sounds
like
the
latter.
B
It
is
the
latter,
mostly.
There
are
some
ways
to
tweak
this
to
correct
that.
I
think
one
of
them
being
to
rename
last
call.
So
basically
because
it's
been
abused
so
much
just
rename
last
call
but
then
have
the
real
definition
be
what
it
is
like.
What
you've
described,
which
is
very
few
changes,
except
for
security
vulnerabilities
during
the
last
call
phase,
but
then
that
doesn't
solve
the
problem
of
the
review
status
being
an
undetermined
indeterminate
amount
of
time.
B
B
B
Well,
yeah,
I
get,
I
guess,
you're
right
like
because
I.
B
G
If
you
somehow
you'd
like
you're
looking
at
it
in
review
phase
like
with
one
five
five
nine,
then
you
get
a
lot
of
feedback
in
the
review
phase
like
actually
one
time
I
got
the
feedback
in
the
draft
phase
and
so
like,
I
feel
like
there's
a
we
have
these
statuses
that
are
meant
to
tell
give
people
information,
but
I
don't
feel
like
they're,
particularly
functional
in
achieving
that
goal.
Like
people
are
not
looking
at
them.
B
I
would
need
abuse.
I
would
lean
toward
this
to
help
with
the
fact
that
the
stat
to
basically
stick
with
somewhat
of
the
status
quo,
but
to
try
to
also
push
practices
best
practices
would
be
to
keep
last
calls
definition,
as
is
pretty
much
because
it
doesn't
include
only
security
vulnerabilities
right
now
and
move
it
to
devnet
phase,
and
then
public
test
net
like
doesn't
include
an
eip
status
beyond.
Well
then,
that
yeah,
but
then
that
leaves
public
test
net
to
not
have
any
ip
status.
That's
the
problem,
I
guess.
A
G
B
G
B
Would
be
okay
but
like
the
the
thing
is,
I
think
it's,
I
think.
The
other
thing
that's
messing
me
up
here
that
makes
it
harder
to
find
a
solution.
Is
the
fact
that
that
that
this
definition
for
last
call
is
the
same
across
ercs
and
core
eips,
and
if
that
wasn't
the
case,
then
things
would
be
easier.
B
If
we
can
get
if
we
start
paying
for
editors,
I'd
be
okay
with
that
plan,
and
I
actually
talked
to
a
project.
I
can't
name
who
said
that
once
they
have
enough
funding,
they
want
to
give
money
for
eip
editors.
So
that's
that's
kind
of
part
of
the
another
piece
of
this
update.
I
think.
B
A
Yeah
sure-
and
I
see
there
are
some
comments
as
well
in
the
chat,
so
I'm
also
okay,
fine
with
not
making
any
decision.
I
just
wanted
to
bring
it
to
attention.
Like
you
know,
we
had
this
discussion
that
we
are
not
following.
The
process
of
people
are
not
aware
of
the
process,
or
there
are
some
changes
that
we
should
be
bringing
to
the
process,
so
I
just
wanted
to
share
it.
B
Yeah
that
sounds
okay.
I
have
it
in
my
to-do
list
to
make
a
comment
on
that
issue.
In
the
next
week.
C
Thanks
all
right,
I
can
just
say
one
more
thing
on
that
yeah.
I
think
I
think
a
lot
of
people
don't
understand
the
latest
eip
process
and
I
think
that
was
incredibly
clear
with
2315.
A
lot
of
people
still
thought
that
you
know
the
status
of
the
e
kind
of
meant
how
far
along
it
was
in
the
governance
process
and
people
were
like.
Oh
23,
15
was
still
in
draft.
C
We
thought
it
was.
You
know
we
didn't
realize
was
going
into
a
hard
fork
and
you
know
that's,
maybe
not
the
best
argument
in
the
world.
There's
probably
a
lot
of
documentation
that
was
going
into
hardcore,
but
I
think
that
you
know
having
those
things
separated
caused
a
lot
of
confusion
for
people
who
don't
reasonably
closely
follow
all
core
dubs.
G
The
eip
process
being
purely
technical,
allows
us
to
move
forward
and
ignore
politics
and
anytime
someone
brings
them
up.
We
can
tell
them,
go
away,
go
to
the
hardware
coordination
process
where
politics
are
handled
and
that's
is
very
valuable,
especially
given
that
we
are
already
you
know
massively
understaffed
to
actually
do
anything
with
eips
and
being
able
to
tell
people.
This
is
not
the
right
place
for
governance.
Discussion
is
very
valuable.
C
I
just
don't
I
I
really
don't
see
how
this
is
that
different
from
what,
because,
because
in
my
mind,
the
only
difference
would
be
that
if
you
want
to
move
to
a
final
state-
or
you
know,
we
add
a
new
state
that
says
it's
going
into
a
hard
fork,
a
new
status
to
me,
the
only
difference
in
what
we're
doing
is
that
they
need
to
provide
a
link
to
an
all
core
devs
decision.
That
says
you
know
this
is
going
into
a
hard
fork
and
then,
as
an
editor,
we
say:
okay,
yep,
that
checks
out.
C
G
So
the
we
ran
this
a
couple
of
times
with
eaps
in
the
past.
I
believe
where
the
governance
debate
ends
up
spilling
over
into
the
eip
process
and
being
very
distracting
for
the
ap
editors,
and
the
reason
for
that
is
because
at
some
point
someone
updates
an
eip,
and
it
now
says
you
know
going
into
hard
fork
x,
going
into
berlin
going
into
london
whatever,
and
as
soon
as
that
happens,
everybody
shows
up
in
the
ap
repo
and
starts
commenting
and
starts
many
pull
requests
to
remove
that,
etc.
G
When
that
is
handled
elsewhere,
it
makes
those
people
go
elsewhere
when
they
want
to
do
their
brigading
and
their
harassing
and
harraining,
and
so
james
can
deal
with
that
until
he
quits
and
hands
it
over
to
tim,
who
can
deal
with
that
until
he
quits
and
has
over
someone
else,
and
the
editors
hopefully
can
stick
around
and
not
be
driven
away
by
the
massive
brigade
and
problems
that
people
cause
when
they
see
that
stuff
like
it
by
having
a
clearly
separate
spot
for
them
to
go
to?
G
That's
not
here
like
not
here,
not
these
people,
don't
distract
these
people
they're
doing
real
work
go
distract
those
people
whose
job
it
is
to
deal
with
that
problem
like
and
it's
by
keeping
it
very
clearly
separated.
It
makes
it
easier
to
kind
of
draw
a
line
in
the
sand
and
say
no
that
goes
over
there,
whereas
if
the
two
are
intertwined,
then
it's
much
harder
to
kind
of
stand
up
and
say
this
is
not
the
right
place
because
they're
like
well,
this
is,
it
says
right
there,
it's
going
into
berlin.
G
G
C
Yeah
I
mean
I
haven't
really
experienced
that
so
you
know.
Obviously
my
my
take
is
gonna
be
different,
but
I
can
understand
how
that
is
frustrating
as
an
editor.
I
think
you
know
I
mean
I'll
just
say
my
two
last
points.
I
think
that
one
you
know
if
we
design
the
process
in
the
right
way,
I
feel
like
we
can
use
the
process
as
a
shield.
Still
I
think
that
we
should
be
able
to
say
this.
Isn't
the
place
to
discuss
this.
We
don't
discuss,
we
don't
choose
what
goes
into
hard
forks.
C
C
That's
that
different
than
using
than
just
saying
this
isn't
discussed
here,
because
it
basically
still
isn't
and,
and
then
you
know,
the
other
thing
is
that
I
feel
like
we're
optimizing
for
you
know
the
five
percent
of
eeps
that
have
a
lot
of
issues
and
by
optimizing
for
those
eeps
that
have
you
know,
issues
and
a
lot
of
people
fighting
for
them.
We
are
really
degrading
the
experience
for
everyone
in
the
community
and
for
the
other
95
percent
of
eeps,
because
a
lot
of
people
just
want
to
go
and
see.
C
You
know
want
to
read
about
it
and
know
what
the
status
is
and
they
want
to
do
it
all
from
a
single
page.
And
if
I
it's
it's
just
incredibly
frustrating
to
like
look
and
eat
but
not
know
how
far
along
and
the
governance
process
process
it
is
from
its
from
its
site.
That's
why
I
think
I
said
from
the
very
beginning
that
at
minimum
we
should
also
include
as
a
courtesy
what
the
like
hard
fork.
Status
of
an
eip
is,
even
if
those
things
are
still
separate,
the
you
know
the
specification
and
everything.
G
So
my
opinion
on
the
last
point
you
make
there
is
that
I
think
the
real
issue
here
is
that
people
are
using
the
eip
as
the
center
point,
and
I
don't
feel
like
it
should
be.
I
feel
like
the
eip
should
be
a
technical
detail,
not
the
you
know
the
the
the
center
point,
and
unfortunately
this
is
not
how
things
have
been
handled
historically
at
all
like
this.
This
is
very
much
not
how
things
are
actually
done,
but
I
do
think
that
it'd
be
great.
G
If,
instead
of
when
someone
wants
to
say,
like
you
know,
what
is
this
new
feat
change?
They
don't
go,
look
up
or
get
linked
to
eip
1559..
They
get
linked
to
the
like
that
resources.
Page
that
tim
put
up
it
has
links
to
you
know
some
blog
posts.
It
has
links
to
berlin,
hard
fork,
it
has
links,
it
has
description
of
the
erp
designed
for
certain
audiences.
Like
it's
not
just
the
technical
specification,
I
feel
the
vast
majority
of
people.
G
The
technical
specification
is
not
the
right
place
for
them
to
start
learning
about
an
eip
or
talking
about
an
efp
or
anything
like
that.
Like
it's,
you
know
it's
one
of
those
things
where
you
know:
there's
10
people
who
actually
read
the
rfc
for
for
email
addresses,
but
no
one
goes
to
the
email
rfc
to
learn
about
email
or
to
learn
about
how
to
send
an
email
or
how
to
use
email
or
anything
like
that.
G
Like
there's,
like
probably
a
few
hundred
people
in
the
world
who
have
ever
actually
read
that
ears
that
rfc
front
to
back,
I
would
like
it
if
we
can
get
there,
but
maybe
I'm
being
overly
optimistic.
C
I
mean,
I
think,
that's
I
mean
I
totally
understand
that,
and
I
definitely
agree
that
that's
probably
the
long-term
goal.
I
just
don't
think
that
we
are
close
to
that.
I
think
that
the
number
of
people
who
are
really
involved
in
this
process
are
still
I
mean
it's
just
it's
so
ingrained
that
if
you
are
working
at
a
low
level
of
ethereum
you're
going
to
go,
look
at
the
ip
repository
for
to
understand
changes,
and
we
just
don't
have
the
resources
to
have
every
single
change.
Have
you
know
a
resource
page
and
have
write-ups?
C
G
Yeah,
that's
a
fair
and
compelling
argument.
You
are
right,
like
you
know,
w3c
and
iatf
they've
got
lots
of
resources
when
they
want
to
like
when
there's
a
browser
change,
for
example,
there's
a
spec
for
it,
and
you
know
there's
like
10
people
who
actually
read
that
spec,
but
it's
you
know
listed
on
canius.com
and
400
other
web
pages,
and
people
blog
about
it
and
like
there's
almost
no
one
goes
to
the
specs
repo
to
learn
about
upcoming
changes
to
the
browser
apis,
but
you're
totally
right.
They
it's
because
they
have.
G
You
know
hundreds
of
people
working
on
every
single
change,
not
two,
and
so
maybe
maybe
maybe
maybe
the
issue
here
is
we
don't
have
the
funding
or
the
resources
to
actually
achieve
a
goal
and,
as
a
result,
we're
trying
to
achieve
an
unachievable
goal
which
just
puts
us
in
an
even
worse
place.
If
we
didn't
even
bother
trying.
C
I
feel
like
it's
gonna
happen,
naturally,
because
I
mean,
if
you
just
look
at
how
eeps
have
changed
over
the
last
four
four
years
or
so
you
look
at
eep,
seven
or
whatever
delegate
call
is
and
it's
you
know
50
lines,
and
it's
just
there's
just
nothing
there
and
now
you
know
we're
looking
at
some
of
these
later
ones
like
3074,
it's
a
you
know,
really
beefy
eep
and
if
that
would
have
been
proposed
in
2015
it
would
have
been
just
like.
Oh
the
toxic.
C
This
was
a
good
idea,
let's
just
throw
a
couple
lines
down
and
then
we'll
just
talk
about
it
on
irc
or
getter
how
to
implement
it,
and
you
know
in
five
more
years,
I'm
guessing
that
maybe
every
will
have
a
1559
style
resource
guide
and
all
that
stuff,
maybe
it'll
be
eight
or
ten
years.
I'm
not
sure,
but
I
think
that'll
happen.
G
I'll
think
on
what
your
argument
here,
it's
very
convincing
the
smaller
resource.
A
Pool
okay,
so
one
last
question
I
think
I
may
have
on
this
topic
before
we
move
on.
Although
I
know
this
is
not
an
encoded
meeting,
and
this
is
not
like-
we
are
discussing
the
berlin
upgrade
here,
but
it's
a
question
to
eip
editors
right
now.
All
the
proposals
of
berlin
are
on
tesna
and
as
far
as
I
know,
there
is
only
one
eip
out
of
four,
which
is
actually
in
last
call
and
rest
all
are
in
review.
G
I'd
be
fine
as
the
first
one
and
if
they
don't
want
to
I'm
also
okay
with
that.
A
G
It
might
help
if
we,
like
you,
said
edit
eip1,
someone
spent
a
priority.
Everyone
that
just
gets
rid
of
that
makes
it
more
clear
that
the
14
days
is
a
minimum,
not
a
hard
requirement,
and
then
maybe
in
the
future.
We
can
talk
about
removing
before,
like
the
review
end
period
and
just
have
it
implicit.
G
A
G
A
Days,
okay,
so
I'm
gonna
bring
it
back
on
the
agenda
next
to
in
the
next
meeting
as
well.
G
Since
hudson
has
to
leave
in
a
few
minutes,
do
you
guys
mind
if
I
interject
a
quick
discussion
item
that
I
forgot
to
put
on
the
agenda.
G
So,
for
reasons
that
I
don't
fully
understand,
the
burden
of
reviewing
eips
has
increased.
It
is
now
to
the
point
where
I
am
unable
to
keep
up
while
also
continuing
to
sleep
every
night,
and
so
I
think,
starting
probably
this
week
stop
reviewing
erc's.
Just
because
I
need
to
drop
something
and
it's
either
drop,
ercs
drop,
sleep
or
drop
eating
and
I've
decided
erc's.
G
They
drew
the
short
straw,
so
either
someone
else
needs
to
pick
up
reviewing
erc's
or
we
just
need
to
accept
that
we're
going
to
go
back
into
the
state
we
used
to
be
in
where
yeah.
If
you
are
sitting
waiting
for
a
reviewer
for
months
to
years,
unless
someone
has
a
very
novel
solution.
B
I
think,
while
we
find
a
solution,
if
it
goes
back
to
where
it
was
before,
where
we're
not
like
completely
up
to
date
on
it
and
we
have
a
lagging
a
lag
behind-
that's
not
the
worst
thing
in
the
world,
because
that's
kind
of
what
has
to
happen,
but
we
should
work
towards
recruiting
more
editors.
I
still
haven't
cracked
that
code,
so.
B
C
C
I
mean
yeah.
If
there's,
if
there's
open
stuff,
I
usually
will
get
to
them
after
you
know
a
week
or
so
so
I
don't
think
we're
gonna
get
back
to
the
place
where
it's
months
and
months
now
reviews,
but
I'm
definitely
a
lot
more
open
to
removing
ercs
from
the
eip
repository,
probably
not
something
we
can
decide
right
now,
but
I've
known
in
the
past.
I've
been
against
it
and
I
think
that
I
don't
know
if
it's
just
micah
is
really
getting
in
my
head
and
you
know
he's
starting
to
control
my
thoughts.
G
G
I
think
the
skill
set
for
reviewing
ercs
is
very
different
than
eips.
I
happened
to
have
both
just
because
of
my
history.
I
came
up
through
the
deaf
side
and
then
moved
over
to
cordov
sort
of
side
later,
but
I
can
definitely.
I
definitely
I
know
of
people
who
would
be
very
good
at
reviewing
ercs
and
terribly
reviewing
eips,
and
I
also
know
people
who
are
very
good
at
reviewing
eaps
and
I
would
not
want
them
reviewing
the
rc's.
B
B
G
Okay,
I
would
separate,
then
recruit
just
for
the
reason
I
just
said,
like
the
skill
set.
A
B
That's
true:
okay:
we
need
to
figure
out
how
hard
it
would
be
to
separate
and
like
propose
something
before
we
decide.
I
think.
G
C
I
C
Is
we
could
just
replace
every
erc
with
like?
We
did?
I
think
the
rc20
token
was
named
differently
and
then
we've
got
a
placeholder
there.
We
could
do
that
for
every
erc
and
keep
that
for
three
to
five
years,
and
I
don't
think
that
that
would
really
impose
much
of
an
issue
because
who's
actually
going
through
that
list
of
files,
not
not
many
people.
B
It's
more
the
discussion
links,
but
we
could
we
wouldn't
be
deleting
pr's
or
issues.
Would
we
no.
A
C
On
that,
real
quick,
I
don't
know,
is
theoretically
if
we
did
want
to
do
that.
Does
anyone
have
like
a
theoretical
path
to
you
know
making
that
like
who?
Who
needs
to
agree
to
that,
to
make
something
like
that.
G
Yeah,
I
also
don't
know
so.
The
people
who
actually
look
at
ercs
are
me
and
in
theory
other
eip
editors,
so
very
few
and
far
between.
As
you
know,
and
then
there
are
the
authors
of
those
ercs
themselves
and
then
once
the
ercs
get
popular
they're
the
people
who
are
looking
at
them
to
implement
those.
Those
are
three
people
I
have
seen
show
up
in
the
ips
repo
related
to
erc's,
one
or
three
types
of
people.
A
Maybe
this
is
something
that
we
could,
like.
You
know,
bring
it
on
the
next
call
and
like
as
an
item
itself
like,
do
we
want
to
separate
these
vip
and
erc
if
people
are
open
to
discuss
that.
G
Sure,
just
so
people
can
chew
on
it.
The
reason
I
want
them
separated
and
not
just
like
say
you
know,
micro
reviews,
core
eips
and
someone
else,
reviews
erc's
is
that
github
subscriptions.
I
subscribe
to
the
entire
efps
repository,
which
I
think
an
email
notification
for
everything
and
right
now
that
is
about
half
erc's
and
it'd,
be
nice.
If
I
could
not
subscribe
to
the
erc
half
and
I
don't
believe,
there's
an
easy
way
to
do
that
without
splitting
it
out
into
a
separate
repository.
C
I
think
that's
a
general
argument
for
a
lot
of
issues
that
we
have
with
you
know.
Governance
is
that
a
lot
of
people
don't
want
to
contribute
because
the
noise
is
so
loud,
but
with
them
separated.
I
think
that
there's
just
a
lot
less
happening
in
terms
of
core
eeps,
and
so
that
may
allow
a
larger
number
of
people
to
actually
review
everything
that
comes
through
because
they
feel
comfortable
doing
that,
and
then
maybe
people
who
want
to
look
at
ercs
will
feel
comfortable,
because
this
is
like
an
erc
specific,
it's
a
little
more
friendly.
A
Okay,
in
the
essence
of
time,
let's
move
on
to
like
quickly
go
over
a
few
other
items,
and
I
will
try
to
add
that,
on
the
I
mean
not
try.
I
will
definitely
add
that
on
the
agenda
next
time
to
have
a
proper
discussion
on
this
topic-
separation
of
eip
and
erc
and
yeah.
Coming
back
to
alita's
item,
I
think
we
have
discussed
it
briefly.
A
So
the
next
item
on
the
agenda
is
a
progress
on
canonical
source
for
eips.
I
believe
brent
has
something
to
talk
about
it.
E
Yeah
the
meeting
is
way
long,
so
I
just
want
to
mention
that
we've
forked,
the
repository
and
I'm
working
with
one
of
our
part-time
engineers
to
figure
out
the
bot
system
that
makes
eips.etherium.org.
So
we
can
make
a
mirror
of
that
site.
Once
we've
got
that
running,
we're
going
to
start
making
changes
the
changes,
we're
proposing
and
I'm
proposing
those
in
the
dark
so
just
want
to
let
everyone
know
I'm
pushing
in
that
direction.
That's
the
progress
we've
made.
So
that's
that's
all
I
need
to
mention
today
we'll
talk
about
it
later.
E
E
E
But
thanks
for
the
support,
yeah,
we're
yeah
if
anyone
has
any
helper
but
anyway,
yeah
we're
working
on
it.
So
thanks.
A
Thank
you
ben
for
that.
So
coming
back
to
item
number
one,
which
was
on
the
progress
on
eip
github
repo.
Now
that
alita
have
joined
arita.
If
you
have
anything
to
update
on
that-
and
we
know
that
this
is
already
in
a
pull
request
on
eip
github
for
editors
to
review.
Do
you
want
to
add
anything
on
that.
J
No,
not
really,
I
think,
that's
that
pretty
much
covers
it.
It's
in
review,
yeah.
G
Can
you
ping
me
once
you're,
I
notice
you're
making
a
bunch
of
changes,
and
so
I
kind
of
stopped
checking
back.
Can
you
just
mention
me
on
that
once
you're
to
a
point
where
you're,
you
think
you're
done
with
all
your
next
round
changes
and
I
can
review
it
again.
J
Yeah,
so
after
that,
that
is
one
thing
that
I
I
added
you
did
you
want
tests.
I
wasn't
really
clear.
G
I
mean
I
always
want
tests,
but
I
also
have
been
an
engineer
long
enough
to
know
how
much
of
a
time
sync
that
can
be-
and
so
the
question
is
is:
is
it
worth
the
time
and
I
don't
have
a
good
answer
to
that?
One
in
your
opinion,
how
easy
is
it
to
test
github
actions
is
one
of
those
things
where
you
have
to
spend
like
two
weeks,
just
figuring
out
how
to
test
a
github
action
like
in
automated
fashion
or
something.
J
Like
you,
don't
know
how
to
do
that,
so
I
can
build
like
a
like
a
custom
system.
That'll
just
do
it
like
like
a
mock,
basically,
which
is
what
jess
is
for
anyway,
and
what
that
means
is
basically
like
just
creating
like
some
basic,
not
necessarily
perfect
reproduction
of
a
pr
just
to
test
certain
behaviors.
The
biggest
thing
is
like
there
are
a
lot
of
edge
cases
to
do
so
like,
like
I
mean
I,
I
there
there
are
bugs
with
the
current
bot
like
a
lot
of
them.
J
Yeah
well,
wait
well,
but
anyway,
like
th,
there
are
a
lot
of
things
that
are
wrong
with
it,
which,
admittedly
you
know
writing
tests,
would
be
a
really
great
opportunity
to
then
like
test
and
fix
those
edge
cases,
but
also
the
bot
seems
like
a
perfect
candidate
for
tests
like
to
require
tests,
because
no
one's
going
to
notice
when
a
test
when
something's
going
wrong
but
anyways
like
I
would
say
it
will
take
me
about
one
to
two
weeks
to
get
a
solid
baseline
of
tests
going.
G
So
my
feelings
that
that
one
two
weeks
aligned
with
my
where
my
gut
was
just
just
looking
over
you're
kind
of
looking
over
your
shoulder.
That's
of
the
order
magnitude.
This
is
what
kind
of
this
is
almost
a
question
of.
Should
you
test
your
test
sweep
because
the
the
bot
is
effectively
just
kind
of
a
test
runner
that
is
supposed
an
automated
ci
process
and
spending.
G
It's
just
a
question
of:
is
it
worth
the
time
like?
Would
we
would
that
time
be
better
spent,
making
the
bot
actually
do
better
like
making
it?
You
know,
do
more
things
like
there's
a
we
have
a
list
of
things.
We'd
rather
have
the
bot
do
like.
If
you
have
one
or
two
weeks
of
engineering
time,
we
can
either
sync
it
on
making
sure
the
the
bot
is
robust,
or
we
can
sync
it
on
making
the
bot
more
feature-rich
and
I'm
on
the
fence.
That's
twitching,
more
valuable.
C
You
know
checking
functionality
just
to
make
sure
that
okay,
for
these
simple
cases,
this
makes
sense,
you
know
it
did
they
change
the
status
to
review.
If
so,
then
that
needs
an
ip
editor.
I
don't
know
what
the
control
flow
exactly
is,
but
just
you
know
a
handful
of
tests.
You
know
I
don't
expect
every
edge
case
to
be
tested,
but
just
a
few
sanity
checks,
I
think,
would
be
valuable
and
then
having
the
structure.
For
you
know,
writing
other
tasks
in
the
future
would
be
nice.
J
Okay,
that
that
makes
sense
as
a
first
as
a
first
go,
and
then
you
know
obviously
like
I'm
happy
to
continue
work
on
it
as
well.
If
you
all
wanted
to
keep
me
on
with
that,
but
like
in
regards
to
like
building
out
test
versus
well,
first
off
so
for
this
pr,
it
would
make
sense
to
build
out
the
infrastructure
for
tests,
not
necessarily
tests
themselves,
and
I
could
get
that
done
in,
like
I
mean
pretty
quickly
but
but
anyways
like.
J
I
think
that
the
the
bot
itself
really
needs
like
very
comprehensive
tests.
Just
because,
like
it's
going
to
be
really
hard
to
build
out
things
when,
like
the
bot
needs
to
be
on
point,
otherwise,
it's
kind
of
like
gonna
cause
problems
right
because
like
if
we're
just
like
auto
merging
things
because
of
some
bug,
then
that's
gonna
mess
up
the
repo.
So
I
think
that
we,
it
would
be
better
to
be
sure
than
to
have
problems
with
this
sort
of
thing.
G
Yeah,
that's
a
good
point.
I
forgot
that
this
particular
bot
a
failure
in
the
bot
results
in
bad
things
happening
like
it's.
It's
not
just
like.
Oh
that
didn't
help
us
human
can.
Step
in
this
is
oh,
the
bot
actually
made
things
worse.
That
kind
of
that
pushes
me
more
towards
the
yes.
We
should
test
more
stuff.
J
And
then
also
when
it
comes
to
like
the
actual
code
itself
like
it
for
some
reason
it's
pretty,
I
mean
I
think
it's
because
it
was
reporting
from
python
or
something
like
the
logic
was
pretty
tangled.
So
there
is
still
some
work
to
do
as
well
like
to
make
it
expandable,
because
right
now
you
can
expand
it,
but
like
it's
just
going
to
cause
problems,
but
anyway,.
G
Sure
getting
the
infrastructure
up
in
a
place
that
the
rest
of
us
can
iterate
on,
I
think,
is
a
very
valuable
first
step
like.
E
So
you're
talking
about
creating
a
a
mirror
of
eip
repository
on
a
server
right
and
that's
exactly
what
we're
building
so
yeah.
We
could
do
all
that
stuff
on
this
repository
that
I'm
working
on
we're
going
to
be
tweaking
the
getting
the
jekyll
script
and
everything
running
on
a
server
and
that
that
would
be,
it
seems
like
to
me:
that'd,
be
a
perfect
place
for
elita
to
run
or
tests
and
develop
testing
and
make
sure
everything
runs
on
this.
E
A
snap
or
fork
of
the
eip
repository
then
once
and
we
can
keep
updating
that
fork
and
run
the
scripts
and
develop
tests
and
stuff
like
that
anyway.
Yeah
I'd
like
to
get
our
part-time
engineer
involved
and
help
with
some
of
that,
we
can
do
that.
J
So
we
don't
need
a
server
or
anything
for
these
tests.
They
are
straightforward
and
well-defined
for
github
actions,
so
it
can
be
done
in
a
single
repo,
so
yeah.
It
wouldn't
really
be
pertinent.
J
I'm
not
totally
sure
what
that
means,
but
with
the
current
behavior
we
don't
need
any.
We
didn't,
it
doesn't
need
anything
else.
No.
G
G
Yeah,
I
think
I'm
convinced
I'm
a
flight
client
just
getting
you
can
test
infrastructure
up
at
least
and
then
a
few,
a
few
standard
checks
on
the
most
egregious
things
like
the
things
that
we
definitely
want
to
make
sure
get
blocked
such
as
is
one
of
the
authors,
the
pull
request
author,
or
did
they
approve
it
like
that's
kind
of
the
the
one
thing
that
it
does
good,
and
is
it
not
in
the
wrong
status
like
if
we
can
get
those
two
things
tested
at
least
on
the
surface,
and
that
would
go
a
long
way.
G
G
So,
if
that's
possible,
if
there's
a
manual
trigger-
and
I
want
to
say
there
is-
I
think
I
saw
a
repo
that
had
a
manual
trigger
github
action.
If
there's
a
manual
trigger,
then
we
could
merge
it
and
then
use
it
manually
when
the
current
merge
bot
fails,
which
is
pretty
often
because
when
it
fails,
I'm
currently
closing
the
eip
and
reopening
it.
G
C
Theoretically,
there's
definitely
ways
where
you
can
tag
a
bot
and
give
it
a
command.
I
know
boris
has
a
lot
of
functionality
like
that
where
you
can
tag
boards
and
say:
okay
once
you
know
the
other
people
on
this
approve
go
ahead
and
merge
it.
I
don't
know
how
hard
it
is
to
implement
like
a
really
simple
that,
like
some
functionality
really
simply,
but
it
can't
be
done.
J
Kind
of
because
we're
short
on
time,
I
wanted
to
hop
on
one
other
thing:
did
you
all
want
me
to
go
out
and
build
that
like
the
bot
and
do
a
separate
repo,
and
I
can
just
do
it
like,
I
can
set
it
up
and
then
like
hudson
or
whoever
has
permissions
can
like?
I
can
just
give
over
control
or
something
like
that.
G
I'm
on
the
fence,
like
clients,
have
convinced
me
the
plus
side
of
having
it
in
the
eips
repo.
Is
that
it's
right
there
and
the
same
people
who
have
right
access
to
the
aps.
Repo
would
have
right
access
to
the
bot.
So
when
we,
the
the
people
who
have
write
access
to
that
repo
notice,
it
doing
something
wrong
or
we
want
to
make
a
quick
patch.
We
know
we
have
permissions,
and
so,
if
we
add
new
editors,
those
editors
will
automatically
get
the
correct
access
rights.
G
Having
a
separate
repo,
though,
is
just
from
like
a
modularity
and
keeping
separation
of
concerns
that
doesn't
make
more
sense
in
that
regard,
I'm
on
the
fence,
if
other
people
have
really
strong
problems.
This
is
definitely
not
a
hill.
I
want
to
die
on
on
either
side.
C
J
I
agree
with
light
client
in
addition
to
that,
we
can
it'll
make
it
a
lot
easier
to
do
like
in
pli
for
the
bot
itself.
G
Yeah,
okay,
I'm
convinced
the
having
using
my
own
argument
against
me.
That
was
that
was
smart.
I
just
argued
before
earlier
that
we
should
separate
ercs
and
eips,
so
people
could
subscribe
more
specifically
and
having
yeah
bought
prs,
go
to
the
same
place
that
er
eip
p
hours
ago
would
not
help
with
that
so
yeah.
Let's
get
it
out
separate
repo.
J
And
then
did
you
want
me
to
do
it
or
were
you
waiting
for
someone
else?
I
forget,
I
know
who
it
was,
but
I'm
forgetting.
A
Thank
you
alita
my
car
and
light
friend.
A
A
I
think
we
are
over
time.
I
wanted
to
quickly
cover
on
the
eip
editors.
Onboarding
thing
we
just
have,
you
know,
try
to
answer
most
of
the
questions
on
the
eip
discord
itself,
but
if
you
could
not
get
answer
like,
I
have
created
this
new
role
in
the
ech
discord
as
eip
editors
aspirants
and
if
you
are
not
there,
you
want
to
be
on
part
of
there.