►
From YouTube: EIPIP Meeting 62
Description
Agenda: https://github.com/ethereum-cat-herders/EIPIP/issues/168
A
The
first
item
I
have
added
it
from
the
issue
that
was
submitted
yesterday,
which
is
make
eip
authorship,
depends
on
ens.
I
find
it
very
interesting
not
that
it
is
very
important.
That's
why
it's
in
number
one
position
but
kind
of
interesting
would
be
curious
to
hear
thoughts
from
people
just
a
second
grit.
I
think
I'm
hearing
echo
from
your
end,
if
you
can
maybe
mute
and
yeah,
if
people
have
any
thought.
B
Comments
I
mean
personally.
If
it
can
be
done,
I
would
prefer
that,
but
it's
all
about
whether
or
not
it
can
be
done.
Obviously,.
C
C
Yeah,
but
you
have
to
have
a
github
account
right
now
and
we
don't
have
any
requires.
Basically,
the
ens
is
going
to
be
used
as
some
sort
of
civil
resistance
mechanism,
and
so,
if
there's
no
mechanism
to
enforce
that,
that
person
has
ownership
of
it,
then
it's
not
really
doing
its
job,
and
so
it's
just
adding
an
additional
step.
B
B
I
think
this
is
more
about
decentralizing.
The
actual
repository
location
itself
in
case
github,
decides
to
have
the
erp's
repository,
go
the
way
of
a
tornado.
C
E
E
C
C
B
Have
user
names
too
are
kind
of
essential,
not
sure
what
would
happen
if,
like
the
the
majority
of
the
yeah
eip,
editors,
perhaps
got
banned
like
if
there's
no
one
to
review,
for
example,
corey
ips,
then
that
would
probably
be
a
problem.
A
A
Moving
on,
we
have
collected
some
issues
and
pull
requests
from
the
github
issue
of
eip
and
what
I
guess
also
okay
part
is
at
number
three.
In
the
last
meeting
we
were
discussing
about
eips
and
erc's
like
how
do
we
write
it?
How
do
we
read
it
and
there
was
one
important
discussion.
A
That
was
how
we
should
pick
eip
numbers,
I'm
not
sure
if
there
was
any
final
decision
on
the
way
we
should
use
eip
number
or
erc
number
so
yeah
people
can
share
thought
on
that,
and
then
we
can
probably
pick
up
how
we
should
pick
up
eip
number.
I
guess
this
was
suggested
by
sam.
E
I
think
the
discussion
was
basically
like,
since
we
had
difficulties
about
eip
numbers.
We
should
make
a
bot
to
do
it
and
I'm
totally
for
doing
that.
If
you
guys
want.
E
B
My
proposal
was
actually
that
we
had
assigned
the
eip
bod
itself.
Some
of
the
nfts
can
use
the
nfts.
E
So
I
think
I'm
in
this
case
I'm
for
the
simplest
solution,
which
is
just
have
a
counter
and
a
sign
based
on
a
counter.
But
you
know
if
we
want
to
go
the
nft
road.
I
guess
I'm
not
super
opposed
to
it.
F
When
I
I
talked
about
the
nft
routes
with
like
some
of
the
client
devs,
and
there
was
definitely
some
amount
of
pushback
and
I
guess
the
like
highest
level,
one
is
people
feel
like
this
is
not
a
decision
that,
like
just
vip
editors,
should
make
like.
F
I
think,
when
you
like,
basically
auctioning
off
a
common
good
or
a
public
good,
and
I
think
if
people
do
want
to
go
to
nft
route
like
I,
it
would
be
good
to
get
like
a
much
broader
set
of
like
input
into
it,
because
I
suspect,
if,
if
like,
we
just
go
ahead
and
do
this
and
like
don't
tell
more
people,
some
people
will
be
like
mad
or
like
yeah,
disappointed
that
this
thing,
that
kind
of
affects
how
the
governance
is
handled
is
like
being
done
without
them
being
consulted.
F
So
not
that,
like
it's,
it's
impossible
to
do
it,
but
I
think
that
it's
definitely
something
which
would
require
like
a
broader
buy-in,
because
otherwise
it
looks
really
bad.
If,
like
you
auction
these
nfts
and
like
cordell
say
this
is
a
terrible
idea,
you
basically
lose
all
the
like
legitimacy
to
your
mft
yeah.
B
Well,
technically,
right
now
the
editors
have
full
power
to
assign
an
to
assign
eip
numbers.
F
Right
so
so
it's
something
yeah,
it's
not
the
assigning
the
numbers.
I
don't
think
any
client
death
cares
about
how
the
numbers
are
assigned.
It's
the
like
auctioning
off
the
public
good
bit.
B
I
think
there's
a
general
consensus
among
the
editors
though
correct
me,
if
I'm
wrong,
that
the
numbers
themselves
do
not
matter
to
us
at
all
right.
E
I
think
what
tim
is
probably
saying
is
that
we,
if
we
were
to
auction
off
nfts,
it
would
make
us
look
like
we're,
taking
more
of
an
active
role
in
assigning
like
using
our
using
our
power
in
a
particular
way
to
assign
numbers
and
the
core
devs
might
disagree
with
that.
It's.
F
F
Anyways,
but
I
do
think
anyways
just
because
it's
like
a
a
largest
change
in
their
process
like
I
would
get
their
input
and
I'm
not
saying
that
like
they
will
be
against
it.
But
I'm
saying
that
like
doing
this,
without
getting
input
will
probably
lead
to
pushback
and,
like
some
people
might
be
against
it.
A
Well,
I
guess
we
are
trying
to
like
address
two
things
here.
One
is
about
nft
sale
of
eip
number
and
help
me
understand
the
proposal
of
how
we
should
be
eip
numbered.
Is
it
dependent
on
the
sale
in
any
way
like
if
the.
D
D
I
thought
we
agreed
the
bot
would
simply
pick
up
the
series
and
start
assigning
the
numbers
so
that
we
could
stop
arguing
about
or
caring
about,
the
assignment
of
numbers.
I
thought
we'd
agreed
to
that
and
I
can't
see
complicating
the
bach
to
try
to
go
picking
through
old
numbers
and
I'm
going
to
object
to
any
going
back
into
the
old
sequence
to
assign
numbers.
I
I
will
strongly
object
to
that.
B
B
Perfect,
specifically,
the
one
that
bases
on
the
the
pr
number.
E
B
E
B
Whatever
the
lucky
person
to
get
pr
number
to
get
eip9.
D
Yeah
I
mean
exactly
when
it
happens:
I'll
leave
to
the
bot
authors,
because
I
know
that's
a
dicey
process,
but
they're
just
a
number:
let's
just
assign
them
sequentially,
then
there
won't
be
so
many
holes
in
the
sequence.
They
won't
stack,
yet
they
won't
get
so
big
so
fast
and
we
won't
lose
editors
over
incredibly
stupid
arguments.
A
All
right
so
yeah,
I'm
just
trying
to
repeat
here,
so
we
are
good
with
the
bot
proposal.
That
is
there
with
five
to
nine
four
and
we
are
moving
ahead
with
that.
F
A
Okay,
cool
and
I
had
listed
this
nft
sale,
one-time
sale
of
unused
eip
number
that
was
on
the
later
part
of
this
discussion,
but
because
we
are
already
discussing
this-
probably
we
can
address
to
that.
So,
if
I
understand
correctly,
that
was
the
proposal
for
unused
numbers.
So
far,
it
was
not
for
future
numbers
like
not
auction
for
future
numbers,
so
that
is
not
going
to
affect
the
way
bot
will
be
assigning
number
in
future.
That
is
one
point,
and
the
second
thing
is
like:
where
are
we
on
that?
B
A
All
right,
okay,
then
I'm
gonna
drop
it
from
the
agenda
and
we
can
probably
take
it
from
the
issue
that
is
added
here.
If
people
are
strongly
in
favor
of
pursuing
it,
we
can
have
it
done.
If
not,
then
the
issue
can
be
closed.
Eventually,
anyway,
we
have
bots
which
closes
issues
if
they
are
not
under
discussion
for
like
over
three
months
or
so
so
that
would
be
taken
care
of.
A
Moving
on
the
next
one
is
fixed
eip
bot.
I
guess
this
was
suggested
by
panda
peep.
Would
you
like
to
take
it.
B
Yeah,
so
basically
for
a
while
now
the
eop
bot
has
been
broken.
Spr
just
fixes
it
micah
refused
to
mikey,
just
now
refused
to
merge
it
without
another
editor
approving.
So
if
someone
here
would
like
to
approve
that,
I
can
then
ping
micah.
A
A
B
Well,
there's
also
going
to
need
to
be
some
changes
after
it
has
merged
to
the
branch
protection
settings
so
require
review
from
code
owners
is
going
to
need
to
be
enabled
enable
dismiss
sale.
Pr
reviews
is
also
gonna
need
need
to
be
enabled,
and
the
eip
merge
bot
is
actually
going
to
need
to
be
removed
from
the
required
checks,
but
that
should
only
be
done
after
the
pr
has
merged
not
before.
B
That
is
a
completely
separate
thing.
I
think
we're
currently
putting
it
on
hold
for
now.
Just
because
again,
there
are
more
important
things.
A
Got
it
so
there
is
an
ongoing
discussion
thread
added
here.
The
link
is
added
here
on
the
agenda.
It
is
about
some
setting
changes
requested
on
organization
level.
People
interested
may
look
into
it
and
they
can
also
participate
in
the
discussion.
Discussion
is
happening
on
issue
eip
github
issue,
as
well
as
on
qatar,
does
discount.
B
Well,
I
mean
micah,
I
think,
was
the
biggest
objector
here.
It's
now
been
a
change
to
only
check
for
solidity
files
and
then
required
that
the
license
be
explicitly
cc01.0
and
reasoning
for
this
is
that
a
lot
of
people
try
to
do
things
like
mit,
because
that's
what
open
zeppelin
uses
apache
2
for
some
reason
is
another
one
I
see
a
lot
of
in
in
general.
B
Well,
they
should
all
be
cc0
and
since
the
solidity
style
guide
actually
requires
you
to
have
an
identifier,
this
just
forces
you
to
have
the
right
identifier.
E
E
Eap1
doesn't
actually
say
that
eip1
only
says
that
the
eip
itself
needs
to
be
cc0,
but
it
doesn't
saying.
B
E
B
E
A
Cool,
we
can
take
it
on
github.
A
Moving
on
the
next
one
is
add,
ech
discord
channel
to
eip
page
index.
This
is
again
something
that
was
there
for
ap
apprenticeship
meeting,
but
we
felt
like
a
broader
audience,
may
be
good
to
have
a
consensus
on
this
particular
topic.
Do
we
want
to
have
ecs
discord
channel
be
added
to
eid
page
index?
A
B
A
Sounds
good
guitar
is
something
that
we
are
definitely
not
using,
and
I
am
just
concerned
because
I
understand
any
discussion
on
eip
level.
Part
of
it,
in
fact,
big
part
of
it,
also
goes
on
with
our
data
score.
We
are
definitely
encouraging
people
to
make
use
of
cathedrals
discard
and
make
a
discussion
here.
So
we
do
not
just
like
overwhelm
the
ether
and
a
discord
server,
but
I
am
not
sure
how
good
or
bad
it
will
be,
because
eip
getter
it
was
the
only
place
for
discussion,
and
that
was
independent
of
discounts.
A
B
A
Right
yeah
matt
mentioned
there
is
some
good
content
in
the
guitar,
of
course,
yeah
totally
up
to
ap
editors.
If
there
is
any
concern
about
adding
a
ecs
discard
to
the
page,
github
page,
I'm
fine,
we
can
let
the
user
know
about
it.
You
can
definitely
add
your
feedback
on
the
pull
request.
The
number
is
added
here.
It
is
5415
and
if,
if
there
is
no
objection,
probably
with
the
minor
edit
that
gavin
suggested,
this
pull
request
can
be
pushed.
A
Moving
on
the
next
sub
item
is
bug
explain
in
text
that
erc
was
renamed
to
eip.
Well,
this
is
this
is
all
together
a
good
discussion,
and
I
I
find
a
comment
from
greg
like
was
it
made
final?
Was
there
a
decision.
A
E
B
A
Yeah,
that's
a
very
good
point
instead
of
arguing
about
what
we
should
call
an
eip
like
whether
an
eip
or
an
erc,
let's
take
smaller
steps,
and
first
thing
first
would
be
like
call
eip
when
it
is
only
existing
in
an
eap
repository,
not
in
like
issue
form
or
repository
of
somewhere
else,
because
there
are
many
other
chain
that
call
their
proposals
also
as
eip.
I
don't
know
why.
C
A
Yeah,
so
that
is
there
and
I
am
a
strong
proponent
of
like
they
are
free
to
call
whatever
they
want
to
call.
They
can
refer
it
to
whatever
they
want
to
refer
it,
but
if
they
are
using
eip
dash
123.md,
then
it
should
be
there
at
least
for
documentation
purpose
greg.
C
I
was
just
saying
to
say:
I
think
we
all
agree
that
we
shouldn't
refer
to
issues
as
eaps
there's
some
legacy
issues
that
sort
of
were
from
before
this
time,
where
we
were
as
hard
about
making
sure
that
things
were
marked
down
files,
but
you
know
we're
anytime.
Those
things
are
referred
to
and
new
ap
eips,
I
think
we're
requiring
them
that
they
merge
them
as
markdown
files.
So
I
think
we're
all
already
on
the
same
page,
with
with
respect
to.
B
D
It's
it's
just
a
confusion,
that's
worth
resolving
one
way
or
the
other,
but
I
don't
think
we
can
get
rid
of
calling
things
erc.
So
I'm
more
in
tune
with
just
try
to
always
call
them
ercs,
and
if
people
wonder
it's
like
well
yeah.
Historically,
you
can
also
call
them
eips
and
you'll
confuse
people
a
little,
but
erc20
and
eip20
are
actually
the
very
same
thing.
Don't
worry
about
it.
D
There's
just
there's
so
much
history
and
confusion
here
that
I
don't
know
that
we
can
ever
really
straighten
it
out.
A
Okay,
talking
about
the
documentation
purposes,
I
understand
the
new
bot
eipw
that
has
some
chats,
which
is
like
whether
it
which
is
for
the
way
it
should
be
documented.
A
E
Like
for
the
erc
versus
eip
yeah,
we
just
have
to
write
a
test.
We'd
have
to
change
the
test
so
that
it
checks
the
type
of
the
linked
document
to
see
what
it
is.
A
E
A
A
Okay,
all
right,
so
I
believe
if
people
are
willing
to
make
these
changes,
they
can
definitely
create
pull
requests
respectively,
and
I
suppose
sun
can
take
care
of
the
bot.
A
Yeah
at
this
point,
I'm
also
fine,
like
moving
ahead
with
whatever
people
want,
because
I'm
sure
that
there
are
more
important
issues
that
we
can
probably
bring
up.
However,
I
was
thinking
that
it
would
be
better
time
when
we
are
definitely
separating
erc's
and
eib.
Then
we
should
bring
this
up
and
do
it.
But
fine,
let's
go
ahead
with
that.
D
A
C
Oh,
I
ask
if
there
is
a
decision
to
also
change
all
previous
texts
to
con
to
make
it
consistent
with
this
new
policy.
A
Yeah,
if
I
understand
correct
like
this,
is
a
flexibility
that
is
being
provided
in
in
the
past,
people
have
been
using
eips
and
ercs
whatever
they
wanted
to.
However,
in
eip1
we
made
this
change
to
reflect
that,
while
you
are
documenting,
you
should
probably
use
it
as
eip.
A
Now
I
it
looks
like
the
group
here
decides
that
we
don't
need
to
be
very
strict
on
that,
and
we
can
go
ahead
with
whatever
way
they
would
like
to
use
it
while
documentation
and
they
would
be
referring
to
file
where
it
will
be
eib-123.md,
but
yes
on
documentation,
they
could
be
using
anything
they
would
like
to
so.
Probably,
yes,
eipw
part
might
need
to
be
giving
that
flexibility.
Otherwise
it
was
a
blocker
there.
C
Yeah
I
started
one
and
I
put
it
in
my
own.
The
repository
to
begin
with
it
doesn't
have
to
tight,
be
tied
to
ethereum,
but
if
you
find
we
find
it
helpful,
then
we
can
integrate
with
the
action
like
github
action
or
anything
like.
I
will
I'll
get
more
concrete
prototype
and
share
with
the
editorial
group
and
see
what
people
think.
A
Well,
the
good
thing
is
like
we
have
a
number
here:
it's
five
four
zero.
Eight
people
can
definitely
add
their
thoughts
on
this
issue
and
if
they
are
interested
to
like
pursuing
it,
they
can
do
that.
So
I
probably
will
drop
it
from
the
agenda
for
the
next
meeting.
I
would
not
bring
it
up,
because
this
is
not
something
that
is
concerning
eip
editors.
A
A
A
I'm
sorry
victor
you
are
breaking,
can
you
maybe
a
little
louder
than
probably
will
be
able
to
catch
it.
C
B
Can
I
ask
why?
Because,
if
any,
in
my
opinion
that
there's,
if
someone
wants
to
see
the
contributors
list
there
are,
there
are
git
commands,
you
can
use,
there's
the
github
sidebar,
there's
like
actual
full
contributors
list.
That
gives
all
the
commits
they've
done.
The
number
of
files
changed
the
added
lines,
the
removed
lines.
B
I
would
be
okay
if
we
started
using
version
numbers
and
and
and
like
congratulating
new
contributors
when
the
new
version
releases,
but
I
don't
see
a
need
to
have
it
in
the
readme.
Maybe
a
contributors
thought
a
contributors.
Rc
document
might
be
useful.
C
I
oh
so
just
to
thank
you
for
asking
the
question
by
panda
and
I
think
my
proposal
is
to
maintain
it
somewhere
and
if
it's
sufficient
to
have
it
on
github,
we
can
like
have
it
synchronize
with
somewhere,
but
it
doesn't
have
to
be
in
in
with
me.
So
I
can.
C
I
can
further
discuss
with
you
to
get
some
consensus
on
where
to
put
it
or
other
way
to
recognize
it,
I'm
in
favor
of
the
general
direction,
I'm
not
like
a
strong
strongly,
preferring
one
way
or
another
where
they
put
or
how
we
are
doing
it.
So
if,
if
you
wanna,
we
can
further
discussion
on
this
on,
like
the
exact
cool
awesome.
A
A
Currently,
that
is
with
matt
as
well.
We
had
two
maintainers
in
the
past
and
I
have
already
requested
the
devops
team
to
provide
access
to
samuelson
as
well
yeah,
I'm
fine
with
that
for
having
one
more
editor
on
just
wanted
to
chat
with
the
present
set
of
editors
group.
C
So
I'm
not
requesting
I'm
not
requesting
a
mention
the
mentor
status,
but
I
think
it's
fair
to
say
that
I'm
in
favor
of
panda
and
getting
this
as
well
so
long
like
everyone
is
like,
if
that
agrees,
that
there's
a
consensus
between
these
men
and
women
that
they
can
be
more
true
right.
B
I
don't
think
I
should
have
admin
permissions,
because
just
because
that
would
allow
me
to
do
things
like
set
that
yet
the
eip
bot
thing
to
private,
which
would
just
completely
mess
with
the
workflow,
but
I
think
we
need
at
least
some
someone
that
can
merge
the
pull
requests.
C
B
Yes,
the
eip
hyphen
bot
repository
yeah.
I
think
I
did
get
I'm
not
sure
if
I
have
right
access
or
not.
A
Okay.
Item
number
three
here
is
eap:
bots,
related
discussion,
updates
agreement
on
merging
pr's
and
closing
issues.
I
believe
we
were
looking
for
some
consensus
for
these
pull
requests
to
be
closed.
A
B
So
micah
didn't
want
105
merged
because
he
wants
a
full
end-to-end
testing.
Basically
me
like
using
a
clone
of
the
eip's
repository
using
the
clone,
doing
the
whole
work
flow
of
submitting
a
pr
having
someone
else
to
prove
it
and
it
being
merged.
I
added
test
cases
that
test.
If
there
is
zero
editors
approving
one
editor
approving
and
two
editors
approving
just
to
verify
that
it
will
only
merge
when
there
are
two
or
more
editors,
but
I
didn't
do
it
manually.
B
This
was
an
automated
test
and
I
think
mike,
for
some
reason,
has
some
guams
with
that,
since
it
was
fading
before
I
ended
the
tests
and
was
passing
afterwards,
I'm
pretty
confident
that
it
works
also
because
the
entire
change
is
changing
a
one
from
a
not
equal
to
zero
to
a
greater
than
or
equal
to
two,
but.
A
I
understand
when
the
bar
tripper
was
created
that
was
being
tested
by
one
of
cat
herders.
I
I'm
not
sure
jose.
If
we
made
any
progress
on
testing
environment,
creating
testing
environment,
how
far
along
we
are
there
in
making
that
environment.
G
Hello,
yes,
we
exactly
with
mica,
we
create
the
environment
and
well
you
use
me
to
you
can
use
it,
but
I
I
told
panda
that
you
have
you
didn't:
have
an
environment
either.
I
didn't
understand
why
you
were
not
able
to
to
go
to
the
I
to
the
test.
What
I
assume
is
that
what
you're
trying
to
test
is
the
new
architecture
that
you
are
proposing
correct
me
if
I'm
wrong.
B
The
reason
why
it's
because
109
was
merged
less
than
an
hour
ago,
so
I
wasn't-
and
I
had
my
eip
hyphen
clone
repository-
set
to
test
that.
D
G
If
you
have
your
test
done
in
your
own
environment,
you
just
need
to
document
the
pr
with
the
test
that
was
the
last
in
the
the
instructions
that
I
remember
from
micah.
You
just
need
to
comment.
Your
test
result
in
the
pr
and
the
and
when-
and
I
guess
that
the
merge
will
will
go-
I
mean
that's
that
should
be
the
standard
procedure.
You
want
to
test
a
new
code
or
new
architecture
for
the
bot.
G
You
clear,
your
you
create
your
testing
environment
with
the
with
the
clone
with
the
fork
of
the
eip
report
and
the
you
get
the
test
successfully
and
you
recommend
the
pr
with
that
comment
and
the
merge
will
go.
I
don't
know
is
the
process
of
hitting,
but
that's
that
was
the
process
that
I
have
been
dealing
with
for
months.
B
B
Like
the
test
cases,
don't
lie
like
the
test
cases
fail.
Then
it
means
that
something's
wrong.
If
the
test
cases
pass
and
you've
added
tests
that
successfully
fail.
If
what
you're
doing
is
wrong
and
past,
if
what
you're
doing
is
right,
then
I
don't
see
the
need
to
have
a
dedicated
testing
environment.
G
G
G
Okay,
I
will
go
with
it.
I
will
test
my
new
proposal
manually
and
that's
it,
but
so
far
from
my
point
of
view,
the
code
should
be
tested
in
the
in
the
in
the
environment,
running
your
test
case
documented
and
ensuring
that
it's
working,
even
even
if
it
is
the
test,
it's
gonna,
imply
changing
the
the
architecture
of
the
god
or
or
whatever
is
the
wrapper
in
this
case
is
the
body.
G
But
if
you
guys,
as
I
said,
if
you
guys
the
editors
this
the
size,
something
different,
that's
fine
and
I'm
just
a
contributor-
and
I'm
just
trying
to
you,
know
to
to
get
my
grain
of
sand
on
it.
And
I
will.
G
C
C
C
I
would
say
yeah,
maybe
I
would,
I
would
say,
the
rationale
to
suggest.
That
is
that
it
makes
it
easier
for
future
contributors
to
contribute
and
so
that
the
original
authors
will
be
notified.
A
So
one
question
here
given
for
testing,
as
you
mentioned
in
the
chat
like
there,
would
be
three
testers
needed
for
it
right.
So
sam
has
a
question
here
like
is
there
any
specific
level
that
is
needed
or
it
can
be?
Any
three
person,
contributor
or
eep
editor
can
do
that.
B
B
Actually,
I
think
most
of
them
run
in
less
than
an
hour
a
minute
and
a
half
then,
but
then
there's
also
micah,
who
wants
an
entire?
Basically,
what
I
did
was
I
set
up
an
entire
clone
of
the
eip's
repository
with
all
the
edit
with
all
the
editors
sam
and
got
sam
to.
Basically,
I
set
up
a
pr
submitting
a
eip
with
a
number
one.
A
Victor
your
hand
is
raised,
is
it
from
the
last
time
or
you
want
to
learn
something
more.
A
E
To
me,
like
basically,
you've
been
given
right
permission
to
the
repository,
you
can
decide
what
level
of
testing
you'd
like
to
see
on
it
and
if
there's
a
problem
down
the
road
like,
if
bugs
get
in,
then
we'll
bring
this
discussion
back
up,
but
for
now
decide
what
you
want
to
do
and
go
with
it.
I
don't
think
it's
really
an
eipip
decision.
B
It's
yep:
well,
I'm
also
not
planning
on
submitting
a
new
pr
every
time
something
changes
to
the
ipod
it'll
be
like
a
whole
batch
of
changes
that
then
I'm
okay
and
to
end
testing.
I'm
okay,
I'm
okay
with
end-to-end
testing.
Every
time
I
need
to
submit
a
pr
I'd
rather
not
have
to
do
that.
Every
time.
A
pr
comments
into
the
eip
yeah
repository.
A
A
We
have
just
five
minutes
left,
so
there
is
one
last
important
item
I
can
see,
but
I'm
not
sure
if
that
is
important
for
this
meeting
today
or
not.
That
is
about
the
meta
e
for
executable
spec
process
for
core
eips.
I
know
it
was
discussed
in
the
all
coordinate
meeting
last
thursday.
I
believe.
A
I
guess
from
the
coded
meeting
it
seems
obvious
that
people
are
generally
in
favor.
There
were
some
changes
that
were
recommended
by
core
devs.
So
probably
we
can
look
for
new
proposal.
One
thing
that
we
wanted
to
discuss
here
earlier.
It
was
a
creation
of
meta
e.
I'm
not
sure
we
are
there
in
the
draft
status.
Yet
right.
A
Okay,
no,
I
was
just
wondering
like
we
discussed
about
creating
a
meta-eber,
so
do
we
have
any
draft
of
it?
I
know
there
is
an
accounting
file
which
was
shared
with
an
all-quarter
meeting,
but
we
are
still
in
the
process
of
documenting
it.
Right.
A
Fine
would
it
be
okay
to
drop
it
for
future
meetings
for
some
time,
and
when
we
have
that
draft
right,
then
I
will
bring
it
back
to
the
agenda.
Oh.
A
A
B
Oh
quick
thing:
can
I
quickly
merge
that
pr
that
adds
the
waiting
for
erp
number
label.
A
All
right,
yeah,
I
think
we
are
on
time
and
I'm
just
trying
to
quickly
look
into
if
there
was
any
action
item
from
the
past
meeting.
A
C
So
I
previously
put
bring
up
that
there
is
a
requires,
a
part
in
the
preamble
of
eip
templates
and
sometimes
that
rem
requires
are
understood
as
that
that
require
the
the
eip
requires
pre,
the
other
eips,
to
be
ready
or
to
be
implemented.
Sometimes
I
think
from
at
least
what
I
learned
a
conversation
with
mikko
that
it
it
was
used
in
some
way.
That
means
to
understand
this.
A
If
I
remember
correctly,
it
was
added
in
the
last
meeting
agenda,
but
unfortunately
I
missed
to
add
it
here
in
this
meeting
and
yeah.
I
could
probably
bring
it
up
in
the
next
meeting.
I'm
not
sure
if
there
was
any
consensus
on
that.
A
Thank
you.
We
are
at
time
I'm
gonna
create
the
agenda
for
the
next
meeting
right
after
this
one.
If
you
can
probably
add
the
link,
I
will
try
to
pull
it
from
the
earlier
meeting
and
do
that
if
in
case
I
miss
it,
please
help
me
out
over
there
and
add
the
link
in
the
comment
section.
I
will
do
that.