►
From YouTube: EIPIP meeting 48
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/105
A
All
right
welcome
to
eipip
meeting
48.
A
I
just
have
shared
agenda
in
chat.
The
first
item
listed
here
is
eip
bot
so,
as
we
know
that
there
has
been
a
lot
of
work
going
on
on
eip
bot
side.
A
In
the
last
meeting
we
discussed
some
of
the
working
of
different
bots
to
be
documented,
and
I
have
also
added
some
of
the
items
which
were
picked
from
the
discard
discussions.
So,
let's
start
with
the
update,
if
there
are
any
on
the
working
of
different
parts,
would
you
like
to
take
this
one.
C
That
a
light
line
built.
A
C
A
C
The
other
one
was
the
the
one
that
alita
built
as
far
as
remember.
There
is
no
third
ball,
I
guess
so
just
a
second.
Can
you
hear
me
guys.
A
A
B
Several
of
them
use
github
actions,
but
I
believe
they
are
separate
things
like
dub
actions
is
a
kind
of
a
tool
suite
and
you
can
set
up
a
number
of
different
bots
that
utilize
that,
and
so
the
greeter
is
run
by
github
action.
The
merge
bot
is
also
run
by
github
actions.
The
validator
is
not,
it
is
run
by
travis
ci.
C
I
hope
it's
fine
now,
maybe
I
should
speak
a
little
louder,
much
better,
much
better
right
yeah.
So
I
identified
that
there
are
two
bots
one
written
by
matt
and
the
other
one
was
written
by
arita,
so
I'm
currently
going
through
the
bots.
I
could
I
didn't
get
time
because
I
didn't
my
health.
Wasn't
I
kind
of
got
covered
and
I
got
sick,
so
I
didn't
get
time
to
go
through
the
entire
court,
but
I've
been
able
to
identify
how
the
bots
are
being
triggered
exactly
when
they're
being
triggered.
C
So
I've
been
kind
of
making
a
small
note
here
and
there
so
that
I
basically
first
understand
what's
exactly
going
on
but
like
there
are
a
couple
of
things
as
to
like
how
are
these
eip
editors
being
assigned
for
for
specific
for
specific
reviews
and
like
how
the
reviews
are
happening
for
each
eips
or
the
or
the
issues,
or
you
know
pr's
that
are
being
submitted,
that
I'm
still
trying
to
figure
out.
C
B
So
I
can
answer
the
question
of:
how
are
you,
how
are
editors
assigned
there's
a
file
somewhere
that
just
has
a
list
of
the
different
eip
types,
so
you
have
ercs
and
core
eips
and
informational,
eips
and
there's
a
file
that
says
these
are
the
editors
it
should
be
mentioned.
If
it's
erc,
these
editors
should
mention
if
it's
core
eip,
I'm
trying
to
find
it
right
now.
I
believe
there
it
is
so
it
is
in
this
file.
B
B
And
then
I
don't
know
how
the
bot
reads
that,
but
it's
space
is
passed
into
the
auto,
merge
bot
so
like
instead
of
environment
variables,
I
think
they
get
passed
to
the
fee.
Yeah.
C
Basically,
yep
yep,
so
these
are
basically
the
usernames
of
the
sorry
github
usernames
of
the
individual
eip
editors.
As
far
as
I
understand,
yeah,
okay
got
it,
and
and
how
is
the
review
process
happening
like
so,
let's
say
if
I
submit
an
eip
which
is
like
in
pre-draft,
let's
just
call
it
pre-draft
because
not
submitted
so
as
soon
as
as
soon
as
it's
ready
to
merge
or
like
being
pushed
into
the
eip
repository
like
how
is
that
process
defend?
Does
the
reviewer
have
to
yeah
sorry.
B
So
as
soon
as
you
submit
apr
to
the
repository,
the
bot
will
see
it
and
assuming
the
bot
can
figure
out
whether
it's
a
query
like
assuming
it's
formed
well
enough
that
the
bot
can
identify
whether
it's
a
query,
ip
or
an
erc
or
whatever.
Then
the
bot
will
mention
the
appropriate
set
of
editors
and
then
one
of
them
will
at
their
earliest
convenience
review
it,
give
you
feedback
and
then
once
everything's
good.
Then
it
will
get
auto
merged
or
rather
then
the
editor
will
approve
the
vr
and
then.
C
And
after
that,
it's
directly
it
also
it's
being
submitted
on
the
eips
dot,
ethereum
dot,
the
eips
web
sub
domain
right
yep
got
it
got
it.
B
C
Okay
and
are
there,
were
there
any
edge
cases
in
the
past
or
were
there
any?
Are
there
any
specifics
that
have
to
be?
You
know
kind
of
remembered
when
working
with
the
board,
especially
regarding
the
eips.
B
There
should
so
everything
that's
a
problem
with
the
bot
should
be
filed
in
for
the
merge
button.
At
least
we've
had
a
lot
of
trouble
elite
has
been
working
on
it.
We
keep
trying
different
things,
try
to
fix
it
and
they
keep
having
problems.
The
eip
bot
repository
should
have
a
number
of
issues.
That
is
where
we
track,
like
all
the
little
problems
like.
E
C
Yeah,
I
think,
there's
one
persistent
issue
that
we
are
having
with
greg.
I
guess
they
get
greg's
username
has
been
defined
and
I
think
that
specific
bug
hasn't
been.
You
know
reproduced
again,
so
I'll
keep
an
eye
on
it,
because
I
I
haven't
seen
that
bug
being
reproduced.
So
basically
that
bug
was,
I
think,
micah.
You
yourself
pointed
that
out
that
greg
was
being
showed
as
the
first
time
contributor,
and
so
maybe
that
was
the
book.
A
Yeah,
I
think
that
was
a
long
back
issue
and
I
am
hoping
that
that
must
have
been
fixed
by
now,
because
greg
is
already
added
an
eip
editor
so
possibly,
but
would
not
recognize
him
at
least
as
a
new
contributor,
and
that
should
not
reappear.
A
Yeah
and
other
than
that
there
are
a
couple
of
more
open
issues.
I
have
shared
the
link
here
in
the
chat,
so
you
know
you
can
visit
that
and
you
can
also
look
into
the
history
of
earlier
box
and
those
were
fixed
by
alita,
and
maybe
it
will
help
you
understand
what
kind
of
issues
are
generally
faced
by
these
working
of
the
bots
yeah.
B
B
There's
a
number
of
things
that
I
manually
review
that
could
easily
be
validated
like
making
sure
the
discussion
to
link
goes
to
ethereum
magicians
and
making
sure
that
the
eips
that
are
dependencies
of
the
iep
in
question
are
in
the
appropriate
state
to
be
dependencies.
You
shouldn't
have
like
a
final
eip
should
not
depend
on
a
draft
eip
and
certainly
that
bot
could
very
easily
say
hey.
This
can't
be
merged
until
you
move
those
other
ones
forward.
First,
circular
dependency
is
another
one.
B
A
desire
to
work
in
rus,
then
the
validator
definitely
has
room
for
improvement.
C
Yeah
I
mean
I
have
there.
Is
this
one
open
issue
that
I
like
to
pick
it
up,
because
I
couldn't
find
time
over
there
because
I
got
sick
so
I'll
pick
it
up
and
also
try
to
get
into
that
part.
So
my
current
process
to
understand
the
bots
and
all
the
like
anything
that
wherever
any
information
that
I
can
find,
I
can
find
us
reading
the
code
understanding
the
amble
file.
C
Context
as
to
why
the
specific
merge
happened
or
like
you
know
like
why
this
change
was
introduced,
so
so
that
kind
of
helps
but
yeah
it's
kind
of
taking
a
bit
of
time.
But
I
like
most
of
the
like
the
core
aspect
of
like
how
the
workflow
is
happening
and
stuff
like
that
that
I
kind
of
understand
but
like
there
are
a
couple
of
things
that
are
still
being
done
manually.
C
Although
the
bot,
what
was
supposed
to
do
provided
that
bot
already
had
that,
like
the
auto,
merge,
sometimes
doesn't
happen
like
you
have
to
close
and
reopen
the
issue
to
make
it
automatic,
or
something
like
that.
So
I
might
have
to
talk
to
elita
once
yeah.
B
Elita
has
been
fighting
yeah
elena
has
been
fighting
with
the
auto
merge,
sometimes
not
working
for.
Like
three
months,
we've
tried
like
three
or
four
different
tools:
tool,
suites
she's
optimistic,
but
I
think
also
the
same
time
as
a
good
dose
of
reality
behind
her
that
the
newest
one
kodiak
will
work
more
reliably
so
we'll
see,
we
just
got
that
one
set
up.
C
All
right
make
sense
other
than
that
I
think
yeah
other
than
that,
it's
fine.
So
hopefully,
by
the
end
of
the
week,
I
should
have
a
bit
of
like
a
small
document
so
that,
like
anybody
can
who
wants
to
pick
up
a
eip
issue
can
kind
of
understand
like
what's
happening
exactly
at
least
the
workflow
part,
maybe
not
the
entire
details,
because
it
just
takes
a
lot
of
context
to
understand.
A
Thank
you.
I
think
it's
going
to
be
a
learning
curve
for
everyone
joining
here
for
the
first
time,
because
elita
has
actually
contributed
in
building
the
bot,
so
she
has
a
better
understanding
of
it
and
with
some
of
the
documentation
and
maybe
looking
into
the
process
flow,
would
be
easier
for
new
people
to
join
in
and
start
contributing
more
well.
I
appreciate
you
working
on
documenting
some
of
those
stuff.
That
could
be
very
helpful.
A
A
It
was
mentioned
by
mike
on
the
discord,
and
I
remember
that
in
one
of
the
eipab
meeting
we
discussed,
we
should
have
a
greater
bot
for
kind
of
letting
people
know
who
are
creating
the
issue
for
for
the
first
time,
even
if
it
is
not
for
the
first
time,
even
if
it
is
just
for
like
you
know
they
they
showed
up
and
they
are
trying
to
create
an
issue
on
eip
github
and
that
is
related
to
general
eip
discussion.
They
should
be
moved
to
the
fellowship
of
ethereum
magician.
A
It
looks
like
the
fix
that
alita
worked
actually
accidentally
triggered
for
both
pull
requests
and
the
issues,
so
that
looks
like
a
small
fix
and
we
might
want
to
deactivate
that
just
just
close
that
that
the
greatest
part
get
activated
only
for
the
issue
section
not
for
the
pull
request
is
my
understanding,
correct
micah.
That
was
the
concern
here.
A
Based
on
this
statement
that
the
bot
is
reflecting,
it
appears
to
be
that
way
because
it
says
that
if
this
issue
was
created
as
a
discussion
too
so
that
I
mean
I
mean
my
understanding
is,
it
is
mostly
for
the
issue
section
definitely
like
to
go
back
and
check,
and
if
that
is
correct,
then
we
can
just
have
a
small
fix
here
to
get
this
deactivated.
C
A
A
Because
that
message
simply
states
that
if
you
are
creating
this
discussion
to
this
issue
for
discussion,
two
for
an
eip,
please
create
a
thread
for
fellowship
of
a
theory
magician
and
that's
just
a
simple
one-liner
message.
And
it
has
nothing
to
do
with
the
pull
request.
B
D
Does
the
bot
actually
catch
that
as
like
a
a
failed
issue
in
the
prs?
D
B
No,
no,
that
is
something
that
would
be
great
if
someone
wants
to
take
up,
if
you,
if
you
love
rust
and
the
elevator
bot
is
written
in
rust
and
could
should
be
an
easy
thing
to
add,.
B
A
B
Validations
page,
I
would
assume,
would
go
on
the
eip,
validator
repository
and
things
with
the
auto
merger
and
the
greeter
and
things
everything
else
should
probably
go
in
the
ip
repository
at
some
point
in
the
future.
It
would
be
nice
perhaps
if
those
were
consolidated,
but
at
least
for
now
that
seems
to
make
more
sense.
A
That
make
a
lot
of
sense
all
right.
So
moving
on
the
last
item
here
was
issue
with
the
auto
merger
bar.
I
I
I
suppose
alita
is
looking
for
any
alternate
proposal
and,
as
mike
also
mentioned
earlier
that,
if
someone
has
any
suggestion,
merger
bot
is
something
that
people
are
struggling
with.
If
you
can
help
with
that,
please
reach
out
to
us
anyone
on
the
discord,
the
ap
editors
or
the
canada's
team.
A
So
as
we
know
that
this
is
not
a
new
item
for
the
eipab
meeting
as
the
execution
specs
repository
itself
is
the
result
of
a
discussion
in
the
past
eipib
meetings
at
presenter,
the
cool
team
is
working
on
documenting
specs
for
execution
clients,
I
suppose
in
python,
and
the
cat
had
always
wanted
to
support
the
work
and
communicate
it
to
the
rest
of
the
community.
So
we
hope
to
have
sam
wilson
talking
about
the
updates
and
also
based
on
the
progress.
A
D
Cool
sound
as
beautiful
as
always
back
into
compliments
all
right,
so
I
don't
know
where
you
guys
are
like
how
how
closely
everybody's
been
following
the
execution
specs,
but
it's
basically
just
a
python
reimplementation
of
the
yellow
paper.
Peter
and
boith
have
just
put
up
the
pr
for
spurious
dragon
so
we're
slowly
but
surely
catching
up
to
mainnet
yeah
I
mean
the
documentation.
Tools
are
pretty
neat.
D
You
can
go,
take
a
look
at
them,
I'm
not
sure
what
kind
of
an
update
you're
looking
for
in
the
actual
progress,
but
yeah
we're
getting
there.
As
for
the
actual
proposal
for
how
we're
going
to
do
eips
in
the
future,
there
is
the
peeping
video
that
probably
goes
over
most
of
it.
D
The
short
form
is
I'd
like
to
replace
the
specifications
section
for
core
eips
with
a
diff
into
the
execution
specs
repository,
and
then
we
can
collect
all
of
the
eips
as
like
markdown
files
inside
that
repository,
and
that
way
we
one
kind
of
get
to
separate
ercs
from
eips,
which
I
think
mica
would
probably
appreciate,
and-
and
we
also
get
like
a
bit
of
documentation
that
goes
along
with
each
code.
D
Change
in
the
same
repository-
and
I
think
that's
going
to
make
it
a
lot
nicer
for
for
following
along
when
you're
implementing
a
client.
A
Thank
you
with
the
updates
I
was
just
like
wondering
like
we
should
keep
people
updated
on
how
far
along
we
are.
As
you
mentioned,
that
spurious
dragon
protocols
are
already
up.
That's
really
good
progress.
We
have
a
few
more
upgrades
to
catch
up.
D
A
Just
a
few
yeah,
not
that
so
that
is
nice
to
know
and
about
this
the
new
proposal.
I
have
shared
the
link
in
the
chat
for
people
who
may
have
missed
it,
but
it
would
be
interesting
to
hear
more
thoughts
on
it.
A
I
know
micah
and
many
other
are
very
much
interested
into
having
a
separate
process,
so
it
would
be
interesting
to
learn
about
what
are
the
prep
work
that
we
can
do
like
cataracts
can
support
with
to
just
bring
this
proposal
to
the
community
and
maybe
actually
help
out
and
using
this
for
not
for
the
merge,
of
course,
after
merge
whatever
if
it
is
shanghai
or
whatever
it
is.
D
B
D
All
right
all
right,
we'll
migrate
off
that
if
you're
a
lodge
band
fan,
then
we
we
can
use
that
okay
but
yeah,
so
I
think
yeah.
That
would
be
a
great
start
just
playing
around
with
ideas
for
how
we
want
eaps
to
look
and
what
kind
of
structure
we
want
for
them.
D
Obviously,
thinking
about
how
the
bots
are
going
to
have
to
change,
to
enforce
whatever
constraints
we
want
on
the
new
repository,
yeah
and
and
obviously
just
like
socializing,
the
idea
of
changing
where
we
look
for
eips
and
maybe
getting
feedback
from
core
devs
on
you
know,
do
they
think
it's
useful?
Do
they
think
cause
like?
I
think,
we're
far
enough
along
in
the
specs
project
that
you
can
look
at
and
be
like.
D
B
If
someone
wanted
to,
let's
say
we
live
in
the
future,
and
all
we
have
is
the
specs
repo
and
someone
heard
about
eip,
I
don't
know
151
or
something
and
they
wanted
to
go.
Look
it
up.
What
would
that
look
like
and
specifically,
choosing
an
eip
that
is
in
the
past,
like
something
that
currently
is
the
oldie
type
vip?
Do
we
have
any
ideas
of
how
we
might
be
able
to
port
those
over
somehow,
so
it
makes.
D
I
think
the
the
goal-
sorry,
I
just
had
a
contractor,
come
into
my
room,
so
I
I
think
the
goal
would
be
to
have
all
of
the
old
eips
ported
into
the
same
format
as
the
the
new
eips
for
core
eip,
specifically
right
yeah,
exactly
yeah
erc
is
you
you
really
can't
represent
in
the
same
repository
so.
D
Okay,
so
I
think
the
way
I'd
want
it
organized
is
so
it's
hard
to
separate
an
eip
out
from
the
fork
it
was
in,
but
I
think
you
should
be
able
to
get
a
decent
idea
from
the
diff
between
the
fork
and
the
previous
fork,
which
we
generate
and
the
the
text
document
that
describes
the
changes
and
that's
probably
how
we're
gonna
have
to
do
it.
B
I
see
so
you
would
have
like
any
ipv5151
document
that
described
the
change
and
then
would
link
to
the
diff
where
the
change
was
included
for
the
actual
specification
part.
D
So
that'll
be
a
lot
easier
in
future
eips
and
we
have
the
process
formalized
but
for
older
ones.
I
think
it's
just
going
to
have
to
be
like
all
of
the
eips
in
a
four
in
one
diff,
because
it's
hard
to
maintain
individual
gifts
per
eip,
yeah,
like
even
maintaining
gifts
per
fork
is,
is
proved
to
be
challenging,
but
yeah.
D
D
D
So
I'll
put
this
in
the
chat
here,
so
this
is
or
actually
I
could
just
share
my
screen-
that's
even
better
yeah.
I
cannot
share
my
screen,
so
I'm.
D
A
So
if
I
understand
correctly,
the
idea
here
is
to
have
all
the
earlier
eips
that
went
into
one
of
the
earlier
folks
to
be
documented
in
one
days
and
for
the
upcoming
eips,
which
are
to
be
considered
for
upgrade.
They
will
have
their
separatists
and
they
in
that
other
than
the
the
specs.
There
will
be
a
separate
txt
file
which
will
contain
other
information,
whether
or
not
they
go
into
the
upgrade
like.
A
D
Exactly
yeah
and
then,
like
I,
I
kind
of
imagine
the
way
it'll
be
developed
for
an
upcoming
fork
will
be
every
every
eip
will
be
developed
in
its
own
branch
and
then
we'll
be
generating
the
documentation
from
all
of
those
branches
merged.
So
you
can
kind
of
see
what
the
next
hard
fork
is
going
to
look
like,
but
then,
when
the
actual,
the
actual
hard
fork
is,
is
decided
and
made,
all
of
those
things
will
be
merged
and
you'll
be
able
to
link
to
each
commit
where
those
eips
were
merged.
A
A
A
Moving
on
the
next
item
is
a
eip's
insight.
That's
a
monthly
eip
status,
reporting
update
since
the
last
update.
There
is
one
new
proposal
added
in
the
past
two
weeks,
and
now
we
have
a
total
of
four
new
eips
in
draft
status
and
there
are
three
eips
in
the
review
status,
eap,
4200,
eip,
eip4626
and
eip3668.
A
Obviously,
eip3668
is
a
no
more
in
review,
but
it
is
listed
here
in
review
status
because
it
changed
its
status
in
the
month
of
january
itself.
For
that
particular
proposal
that
has
now
completed
its
last
call
and
we
should
be
expecting
a
pull
request
to
move
it
to
the
final
status
very
soon
by
the
author.
A
The
last
call
period
for
three
of
the
proposals
which
were
earlier
in
the
last
call
is
now
over.
So
ideally,
all
the
proposals
are
eligible
to
be
moved
to
the
final
status.
366
is
one
of
them
and
the
other
two
proposals
are
eip3448
and
eip3607.
A
There
is
one
additional
proposal
which
is
resurrected
from
the
stagnant
to
review
and
the
number
is
eip2980,
that
is
swiss
compliant
asset
token,
and
there
was
already
one
proposal
which
were
resurrected
from
the
stagnant
status.
Technically,
we
have
like
more
than
three.
We
should
have
five
in
the
review
status,
but
again
one
one
has
completed
the
last
call,
so
only
four
left
in
the
review
status.
A
A
Yeah,
I
see
the
comment
from
micah
and
it
is
really
good.
These
updates
from
sam
give
give
everyone
not
only
micah
hope
for
brighter
future
for
a
reason
not
to
just
live
just
to
be
a
part
of
this
community
as
well.
Thank
you,
sam.
A
Moving
on
the
next
item
listed
here
is
eip,
editor
apprenticeship
meeting.
We
had
this
meeting
yesterday.
There
were
reviews
on
some
of
the
pull
requests
which
were
submitted
over
the
past
two
weeks.
The
highlight
of
the
meetings,
including
some
of
the
pull
requests
those
were
discussed
yesterday,
are
added
to
the
summary
section
which
is
available
in
the
comment
to
add
the
agenda
to
the
meeting.
A
We
can
expect
at
least
one
more
proposal
moving
to
the
final
status
that
is
eip
1271,
it's
it's
an
old
proposal
and
it's
a
big
win
for
the
team,
because
this
was
a
long
due
proposal
to
be
moved
into
the
final
status.
There
were
some
edits
and
recommendation
to
other
pulled
requests.
A
One
of
those
were
eip2982,
which
is
an
informational
eip
for
a
serenity
phase.
Zero,
please
check
out
the
video
and
the
summary
linked
in
the
eipip
meeting
agenda
for
the
details
of
the
discussion
happened
in
the
eip
editors
apprenticeship
meeting,
and
this
meeting
is
bi-weekly,
so
we
would
be
expecting
the
next
one
two
weeks
on
tuesday.
A
So
from
the
previous
meeting,
as
we
can
see,
there
are
only
two
shashank
will
be
working
on
documenting
the
eip
bot
improvement.
He
is
already
working
and
we
should
be
having
something
added
to
the
maybe
readme
file
or
in
the
dark
for
new
people
to
contribute
to,
and
I
did
check
with
william
in
trichen
and
unfortunately
I
did
not
receive
any
response
yet,
but
for
some
of
the
questions
those
were
asked
in
the
earlier
meeting.
A
A
I
will
check
back
with
the
team
one
more
time
and
let's
see
we
hope
to
have
this
migration
done
to
the
ethereum
github
repository.
I
hope
by
the
next
meeting.
I
don't
know
yet
I'm
just
waiting
on
the
response.