►
From YouTube: Filecoin Core Devs Biweekly #4
Description
Recording for: https://github.com/filecoin-project/tpm/issues/7
For more information on Filecoin
- visit the project website: https://filecoin.io/
- or follow Filecoin on Twitter: https://twitter.com/Filecoin
Get Filecoin community news and announcements in your inbox, monthly: http://eepurl.com/gbfn1n
A
A
Awesome
it's
thursday
october
22nd,
and
this
is
the
fourth
for
falcon
quartets
meeting
and
first
agenda
item
is
reviewing
openfit
prs,
one
of
which
is
around
reward
vesting.
Why
you
want
to
walk
us
through
this
quickly.
B
Yeah
cool,
so
a
little
bit
of
motivation.
Pre-Commit
takes
a
fair
amount
of
gas.
If
you
measure
up
total
gas
used,
so
I've
been
looking
at
a
space
gaps,
gas
tallying.
If
you
it
averages
over
the
last
three
epics,
you
see
around
20
percent
of
total
gas
used
by
pre-commit.
You
don't
have
as
good
measurements
of
the
percentage
of
gas
taken
by
vesting.
B
But
if
you
do
a
quick
average,
I
did
this
morning
just
like
five
five
first
pre-commits
I
saw
on
a
gas
trace,
and
I
saw
like
thirty
percent
and
there's
some
variants
up
till
between
like
zero.
B
If
a
minor
doesn't
have
any
reward
and
like
about
50
for
minus
a
big
gas
table
or
big
big
locked
fund
stables
so
that
overall,
if
we
could
stop
vesting
during
pre-commit
that
that
gives
us
between
like
four
and
ten,
maybe
higher
percent
of
total
gas
used
system-wide
per
epic
reduction,
which
would
be
really
nice
and
the
change
is
very
simple.
B
If
you
take
a
look
at
issue,
18
alex
lays
out
the
proposal
which
doesn't
just
include
pre-commit
but
also
confirms
sector
proof
valid,
just
the
callback
that
gets
hit
during
a
proof
commit.
B
So
the
basic
idea
is
to
just
not
vest,
not
not
unlock
funds
which
have
vested,
which
means
we
don't
have
to
load
up
the
big
array
and
then
store
it
back,
which
is
where
all
the
gas
cost
comes
in
and
the
downside
is
pretty
low.
There's
going
to
be
the
one
downside
is
that
there's
an
extra
30
minutes
where
the
funds
will
not
vest.
B
So
if
a
miner
was
hoping
to
make
use
smoothly
and
automatically
for
that
last
30
minutes
between
when
funds
automatically
vest
during
deadlines
and
and
pre-commit,
then
they
would
have
to
automatically
invest
or
automatically
invest
the
funds
from
the
the
locked
funds
table
and
there's
like
a
method
for
doing
that
with
potentially
some
downsides
yeah.
That's
like
a
one,
thirty
minute
window,
it's
and
that's.
B
It's
also
really
going
to
only
impact
people
who
are
only
taking
funds
who
are
relying
solely
on
pre-commit
funds
coming
straight
from
their
vesting
table.
So
all
in
all,
it
seems
like
a
pretty
solid
win
yeah
and
the
implementation
is
just
to
guard
the
loading
and
and
investing
of
funds
and
saving
back
with
a
a
protocol
version
number.
So
it's
we're
talking
about,
like
I
don't
know,
like
10
15
lines
of
code
at
most
yeah
I'd
love
to
take
any
questions,
I'm
guessing!
It's
all
pretty
straight
forward
to
you
all,
though,.
C
Yeah,
it
seems
pretty
straightforward.
The
only
question
I
have
is:
do
you
guys
have
a
like
pr
for
the
change
in
the
spec
actors
for
like
this
proposed
change,
or
have
you
not
done
that.
D
I'm
stephen:
do
you
have
any
I
feel
like
stevie
might
have
some
of
different
opinions
here.
Just
make
sure
that
we
hear
him.
Is
there.
E
It's
because
it
will
save
the
guys
and.
E
Yeah,
well,
I'm
I'm
looking
into
the
code.
I
I
say
there
are
many
places
yeah
there
are
and
I'm
based
in
and
call
there
yes
not
so
necessary.
I
would
think
yes,
it's
a
very
good
proposal.
Let's
do
it.
A
Awesome
yeah,
overall
wins
of
making
making
it
less
expensive
for
everyone
to
do
stuff
on
the
chain
seems
seems
good
seems
like
we'll
probably
find
more
of
these,
so
will
not
be
not
be
the
last
change
of
this
kind,
but
awesome
sounds
like
we're
kind
of
all
thumbs
up
on
moving
forward
with
this
sound
good,
great,
perfect
cool.
So
I
think
we'll
we'll
work
on
actually
printing
that
up
and
we'll
share
that
back
with
the
group.
Once
we
have
a
draft.
A
And
that
will
not
be
for
the
current
state
upgrade
that's
in
the
works,
but
for
the
next
one.
Well,
we'll
let
him
get
that
one
in
cool.
I
don't
believe
we
have
any
other
open,
fit
pr's,
correct.
A
Then
the
next
thing
is
upcoming
seat
upgrades
so
lotus.
The
1.1.0
is
going
to
be
triggering
later
today
in
about
about
like
four
or
five
hours,
so
that
one
has
fip
zero
zero
zero,
four
in
it,
which
unlocks
25
percent
of
bulk
reward
immediately
and
that's
the
other
75,
and
so
I
I
think
the
majority
of
the
community
has
upgraded
but
things
it's
a
small
upgrade,
and
so
we're
not
super
concerned
about
it,
but
things
things
are
continuing
there.
A
So
that's
our
next
upcoming
state
upgrade
at
the
moment
any
questions.
Thoughts
on
that
side,
cool
looks
like
we
don't
have
raul
yet
so
maybe,
let's
hop
into
updates
from
the
various
implementations
and
just
anything,
that's
relevant
for
this
group
or
any
especially
any
questions
for
across
implementations
would
be
great
magic.
Do
you
want
to
start.
A
F
A
Yeah,
I
think
focus
on
stability,
performance
improvements
working
with
the
community
to
debug
any
issues,
but
but
also
decreasing
rate
of
change,
which
is
good
and
what
we've
been
aiming
for.
So
I.
G
Have
a
question
for
magic?
Actually,
someone
has
mentioned.
I
think
it
was.
You
know
you
might
be
someone
else
on
the
previous
meetings,
that
that
magic
is
working
on
drastically
improving
the
mining
speed
any
place
on
that.
F
Yeah
that
car
is
open.
It's
ready
for
testing.
It
has
apparently
separate
trigger
exam
issues
for
some
people
on
some
gps
with
some
drivers.
F
A
Magic,
you
also
have
a
a
set
of
improvements
to
the
like
lotus
minor
code
that
have
been
like
in
the
works
and
you're
like
picking.
F
Roughly
ready
well,
it
is
ready.
The
basic
change
is
that
the
worker
minor
to
worker
communication
is
now
based
on
http
and
this
placing
among
a
couple
of
other
changes
and
yeah.
It's
basically
not
just
waiting
for
the
team
to
do
it.
F
To
damon
communication
from
websockets
http,
no,
no!
That's
my
installed
website
the
word
crypto
miner.
Yes,
oh
actually,
cool.
F
F
I
Awesome
so
updates
pretty
much.
We've
been
focused
on
interop,
I'm
really
proud
of
the
team.
For
getting
to
this
point.
We
are
passing
all
valid
conformance
vectors,
which
is
great,
and
we
did
the
upgrade
to
v0912
for
actors,
and
so
we're
now
able
to
sync
up
to
this
space
race
export
of
block
36.
I
mean
it
seems
like
it's
just
a
small
issue
there,
so
things
are
looking
really
good
from
an
interrupt
perspective,
so
next
steps
for
interop
would
actually
be
after.
I
We
fix
that
one
issue
to
sync
space
race
by
actually
connecting
to
the
network
rather
than
using
an
export
and
we're
hoping
that
the
results
will
be
the
same
other
than
that
we
are
continuing
with
the
storage.
Miner
and
markets
integrations.
So
for
storage,
miner
we've
been
running
a
local
devnet
and
resolving
issues
as
they
come
up.
So
we
added
versioning
for
storage,
miner
and
jwt
authentication
and
for
markets
once
we're
done.
The
pay
channel
implementation,
which
is
very
close,
we
add
the
pay
channel
rpc
and
should
have
integration
with
go
fill
markets.
I
We
are
up
holding
off
on
the
upgrade
ability
for
actors
just
because
our
main
goal
is
to
sync
with
mainnet,
and
so
since
we
can
do
that
using
a
snapshot,
we
will
just
do
the
upgrade
to
v2
and
just
anyone
who
wants
to
use
our
node
can
use
a
snapshot
and
then
in
the
future
we
will
add
the
upgradeability
logic,
and
this
just
gets
us
to
syncing
mainnet
as
quickly
as
possible.
I
C
Yeah
that
pretty
much
covers
it.
I
guess
the
only
kind
of
clarification
I'd
make
is
that
we
are
also
sinking
against
lotus
like
we're
not
just
like
validating
car
file
and
the
issue
that
we're
running
into
now
is
just
a
simple
chain
exchange
thing.
So
I'm
not
sure
exactly
how
many
blocks
you
can
sync,
but
everything
seems
kind
of
clear
and,
as
I
mentioned,
we're
passing
all
test
factors
so.
A
I'm
sure
raw
will
plans
to
make
your
life
better
and
harder
imminently
with
even
more
chain
chain
related
test
factors.
So
all.
C
A
G
Yeah
sure,
so
we
also
on
the
stage
where
we
are
trying
to
sync
with
the
main
network
of
of
file
with
lotus.
Mainly,
we
have
passed
all
the
conformance
tests
which
are
not
disabled.
G
We
have
also
started
making.
Well,
we
have
our
legacy
actors
which
were
developed
initially
for
version
0.2.
As
far
as
I
remember
and
they
were
compatible
back,
then
we
decided
that
we
need
to
start
making
them
compatible
our
own
implementation
of
actors
compatible
with
the
current
lotus
version
so
currently
working
on
that.
G
Basically,
we
are
able
to
connect
to
my
net
get
information,
but
currently
there
are
some
issues
with
a
hat
which
business
which
has
been
chosen
by
all
node,
not
tools
but
stepped
up
by
all
nodes.
So
we
are
currently
working
out
on
what
is
the
issue.
E
We're
focusing
on
the
venus
to
interoperate
with
notice-
and
you
know,
we're
still
using
the
spacesuits
and
the
mandate
and
chain
to
actually
directly
to
sync
with
the
chain
and
after
some
time
we
fixed
some
issues
and
right
now
we
could
yeah.
We
are
now
about
20
000
height
to
yeah
sync,
to
the
notice
chain
and
yeah.
There
is
als
or
also
a
long
way
to
go,
but
as
we
already
fixed
a
lot
of
things
yeah,
but
we
were
facing
a
challenge.
E
Is
that
the
chance
thinking
is
not
so
quick,
so
yeah,
it's
very
slow.
So
we
want
to
improve
our
hardware,
especially
the
io
performance.
So
we
are
yeah
and
actually
we'll
change
the
chain
to
another
hardware,
with
the
ssd
drive
and
maybe
drive
with
cpu,
and
we
think
that
well,
yeah
from
the
20
000
to
and
150
000
or
exist
is
just
a
time
of
work.
We
need
to
pull
up
and
to
say
yeah.
If
there
are
any
issues,
we
just
fix
it.
E
This
way
thing,
and
we
think
that
yeah,
it
is
really
painful
yeah
for
us
to
yes
think
yeah
from
the
height
zero
to
one
hundred
thousand
something
like
this.
So
we
plan
to
also
use
a
snapshot
and
to
set
a
checkpoint
and
yeah,
which
makes
this
thing
is
easier.
Yeah,
and
I
heard
that
some
incompletion
already
used
the
snapshot,
but
we're
still
working
on
that.
If
we,
you
really
have
a
tool
to
make
a
snapshot,
we
can
directly
use
that
yeah.
E
If
any
of
you
can
provide
that
kind
of
tool,
and
that
will
be
very
wonderful
for
us
and
the
sixth,
and
also
we
have
a
mixed
place
to
how
to
build
and
the
venus
and
implementation.
Actually,
as
I
mentioned
in
the
lift
of
shoe,
is
that
I
mentioned
that
we
will
have
separated
components
of
the
whole
implementation
and,
for
example,
we
have
right
now
we're
working
on
the
chain
center
yeah.
E
We
just
do
the
chain,
validation
and
the
thinking
and
provide
the
change
information
to
other
components,
and
we
could
have
another
message
to
just
as
a
tool
with
the
with
cri
and
provide
a
better
ux
for
users
and
which
can
actually
need
a
person
to
to
to.
You
know,
send
out
to
to
make
make
a
message
and
send
up
the
message,
something
that
and
we
could
have
also
minor
yeah,
separate
and
also
senior
civilian
yeah.
Something
like
this.
So
the
based
on
this.
E
We
we
we
plan
to
have
one
or
two
more
people
to
join
the
team
and
to
catch
up
above
this
yeah.
Okay,
and
that's
all
thank
you.
A
Awesome
yeah
modularity
helps
a
lot.
I
believe
magic
lotus
already
has
all
of
the
snap
shorting
snapshotting
tooling
available,
which
is
how
we're
doing
snapshots
that.
E
C
Yeah
we've
been
using
it,
it's
it's
pretty
straightforward
and
it
works
works.
Well.
Just
exports,
a
car
file.
A
A
Great
y'all,
you
guys,
are
all
making
awesome
up
up
the
chain.
Progress
sinking
away,
super
super
snazzy,
probably
the
maybe
still
a
little
bit
early.
But
probably
the
next
thing
to
think
about
across
implementations
is
like
you
know,
once
we
once
we're
getting
to
a
point
where
a
lot
of
groups
are
are
hitting
kind
of
a
similar
set
of
things.
A
We
might
want
to
try
having
a
devnet
with
all
of
the
implementations,
all
syncing
up
to
a
portion
of
the
chain
together
and
then
starting
to
think
about
bringing
bringing
minors
onto
some
of
these
implementations
to
test
things
out.
Definitely
for
when,
when
we
started
up
the
interrupt
net
between
gofalcoin
and
lotus,
like
back
in
that
was
may
june,
time
frame
discovered
a.
A
Pretty
pandemic
times
for
us
crazy,
so
I'm
sure
we'll
discover
a
lot
more
interesting
challenges.
Once
we
have
other
people
trying
to
sync
sync,
with
these
nodes
run
the
miner
on
all
different
kinds
of
hardware:
that's
always
super
fun,
so
I'm
still
relatively
early
days,
but
something
to
think
about
there
is
like
yeah
usability
and
I'm
actually
starting
to
have
have
other
groups
pick
up
the
code
and
potentially
use
it
without
full
understanding
of
the
internals
and
hopefully
get
it
to
work.
C
Yeah
that'd
be
awesome
to
have
a
test
net
with,
I
guess
specifically
only
like
after
mainnet
network
versions,
just
because
yeah
testing
interop
would
be
so
much
easier
for,
I
guess,
all
of
us
without
having
to
snapshot
past
the
space
race,
export.
C
A
Yeah,
let's,
let's
plan
to
do
that,
I
guess
once
people
hit
the
the
spec
actors
v2,
let's
spin
up
a
devnet
and
start
hammering
each
other
in
something
that
has
a
nice
small
chain,
but
we
can
see
what
goes
wrong
should
be
fun:
cool.
A
J
Yeah
I
gave
I
just
presented
at
liftoff
a
week
in
the
research
and
engineering
track,
and
I
gave
all
of
you
a
shout
out
so
a
great
job
on
accomplishing
that,
like
incredible
milestone
of
having
all
test
vectors
passing,
I
think
I
just
like.
I
heard
this
from
forest,
but
did
I
hear
right
that
fujon
also
has
all
test
vectors
passing?
That's
that's
amazing!
J
Yeah,
honestly,
those
should
be
scrapped
entirely
so
yeah
because
nobody's
using
them,
but
it's
good
to
have
to
haven't
been
on
them
anyway.
Yeah
awesome,
that's
that's
great
okay.
So
the
the
update
that
I
wanted
to
that
I
wanted
to
give
is
you've
all
probably
seen
it
but
kind
of
like
for
the
official
record.
We
now
have
multi-variant
vectors,
so
this
is
our
generator.
Scripts
are
running
against
all
known
protocol
versions
and
generating
vector
variants
and
then
merging
them
merging
the
equivalent
ones
into
multi
variant
vectors.
J
So,
basically
now,
when
you
run
a
test
vector,
you
have
an
array
of
in
the
preconditions
block,
you
have
an
array
of
the
network
versions
and
that
box
that
it
needs
to
run
with
against
and
those
headphones
are
anchor
anchor
epochs
or
base
headbox,
and
then
every
single
epoch
within
the
apply
the
apply
blocks
are
actually.
Reference
are
actually
offsets
on
top
of
that
epoch.
J
So
that
makes
for
a
very
elegant
system
where
we
can
like
run
vectors
through
many
protocol
versions
at
once
and
make
sure
that
the
client
is
compatible
with
them.
Also,
there
is
a
a
selector,
so
it
like,
as
you
as
implementers,
develop
there
and
develop
support
for
new
protocol
versions.
You
probably
don't
want
to
run
deliberately,
don't
want
to
run
those
that
are
targeting
protocol
versions
that
you
still
don't
support
so
because
that
would
give
you
like
failures
and
like
known
failures.
J
So
we
add
a
selector
string,
so
you
can
filter
out
those
vectors
which
you
don't
have
protocol
support
for
yet
so
that's
that's
kind
of
like
for
the
official
record
and
stuff
that
we're
working
on
right
now
is
should
be
emerged
by
the
end
of
this
week.
J
We've
just
been
pretty
caught
up
with
liftoff
and
other
things,
but
we
have
a
new
tvx
simulate
command
which
allows
you
to
craft
a
raw
message
and
play
it
against
any
height
on
the
chain
and
it
generates
a
vector,
and
it
also
generates
a
state
div
to
show
you
exactly
what
that
message
produced
the
impact
of
that
message.
J
So
this
is
useful
for
us
to
test
those
messages,
those
kinds
of
messages
that
have
been
still
or
those
like
edge
cases
that
haven't
still
made
it
on
chain,
because
it
allows
us
to
like
synthetically,
create
those
messages
and
test
it
against
against
the
the
state
of
the
actual
network.
Other
things
that
are
gonna
that
are
gonna
land
is
a
tvx
project
command
which
allows
us
to
take
a
vector
or
many
vectors
and
project
those
vectors
under
on
top
of
a
new
protocol
version.
J
If
it
works
and
the
post
conditions
are
met,
then
we
in
place
update
that
vector
and
add
the
new
variant.
If
not
we
fail,
and
that
allows
us
to
like
very
clearly
know
if
a
particular
functionality
has
been
affected
by
by
a
protocol
version
and
that's
pretty
much
it
for
block
sequence
vectors
we
caught
up
with
with
a
bunch
of
things,
and
we
haven't
really
made
substantial
progress
on
that
front.
J
A
Job
saw
thanks
so
much
for
wall.
That's
super
exciting,
I'm
I'm
really
excited
for
these
tvx
commands,
because
that'll
make
testing
upgrades
just
way
easier.
One
of
the
challenges
we
had
with
the
one
of
the
previous
upgrades
is
that
it
was,
I
guess,
a
spec
actors
upgrade
we'd
run
it
a
lot
but
running
it
on
the
real
chain
took
longer
than
running
it
on
other
chains,
and
that
was
something
we
wish
we'd
tested
even
more
thoroughly,
and
now
we
have
the
tools
for
it.
A
A
Awesome
cool
last
thing
on
our
agenda
was
reviewing
open
changes
to
the
fit
process.
A
Issue
16
by
by
ian
who
was
discussing
the
fact
that
current
current
fip
numbering
is
a
little
confusing
where
you're
supposed
to
open
a
pr,
but
you
don't
have
a
name
yet
and
that
when
you
change
the
name
of
the
fip,
it
starts
changing
the
link
to
the
fip
itself,
and
so
we
had
this
challenge
with
fip,
three
and
fifth:
four:
where
they
act,
you
know
they
got
merged
in
the
opposite
order,
and
then
they
switched
numbering,
and
so
we
linked
to
one
of
them
to
have
people
comment
on
it
and
suddenly
it
was
pointing
to
the
other
one.
A
It
was
like
a
little
bit
confusing,
so
the
suggestion
here
is
to
amend
fip1
such
that,
instead
of
starting
with
a
pr.
You
start
with
a
github
issue
and
from
the
github
issue
you
get
like
thumbs
up
to
go
and
create
a
pr
with
a
fip
number
associated
with
it
within
the
issue
which
allows
you
to
then
have
a.
You
know,
choose
your
fifth
numbering
ahead
of
time
for
your
pr,
so
that
that
your
pr
url
doesn't
change.
C
I
kind
of
just
have
a
question
of
curiosity:
what's
the
reason
for
why
the
order
of
the
fips
that
come
in
have
to
be
ordered,
you
know
why
they
have
to
be
ordered
by
the
number
they
come
in
like.
Why
did
you
have
to
switch
the
number
of
the
ones
of
three
and
four
like?
What's
what's
the
negative
to
having,
they
might
guess,
come
in
in
different
orders,.
A
Well,
we
definitely
want
to
avoid
duplicates,
so
we
don't
want
to
have
two
fib
fours
and
it
would
create
the
possibility.
G
A
A
But
then
you
know
it's,
it's
not
accepted
because
you
know
some,
it's
not
ready
yet
or
some
other
reason,
and
so
we
just
actually
created
but
now
fit.
Five
has
already
been
drafted
and
pr-
and
so
then
we
just
skip
over
it
potentially
and
create
a
hole
in
the
numbering.
Holes
are
better
than
duplicates,
but
yeah
right
now
the
the
fip
one
process
does.
A
The
number
is
supposed
to
be
assigned
by
the
the
fip
editor
who,
like
reviews
it
for
correctness
and
decides
whether
it's
accepted
instead
of
by
the
person
who's
pr
in
the
change
itself,
and
that
does
make
a
little
bit
of
that
changes
in
the
the
url
of
the
thing
you're
linking
to.
Unfortunately,
so
something
there
needs
to
change
that
that
maybe
is
an
alternate
proposal
which
is
just
when
you
file
the
fip.
You
choose,
you
choose
the
right
next
number
and
we
figure
it
out
later.
A
If
there's
there's
gaps
or
collisions,
use
dram
to
generate
fip
numbers
more
suggestions,
those
would
be
harder
to
remember
hard
to
type
in
hard
urls.
A
I'm
generally
pro
on
the
idea
of
starting
things
with
a
github
issue,
because
we
already
need
a
github
issue
to
discuss
anyway,
and
so
it
seems
like
a
a
relatively
small
change
and
we
can
maybe
we
can
trial
it
and
see
how
it
goes
with
the
next
couple
of
flips.
That
sounds
good
to
people
cool
awesome,
we'll
move
forward
with
that.
I
A
And
then
the
other
one
is
about
the
integration
with
the
spec
process.
Janice,
you
want
to
talk
us
through
that
and
feel
free
to
show
us
anything
if
that's
easier.
K
Yeah
sure
so
yeah
as
I've
presented
in
the
one
of
the
previous
meetings
and
as
you've
probably
seen
there
has
been
a
huge
effort
that
was
put
in
to
update
the
spec,
which
you
know,
is
kind
of
running
the
risk
of
running
out
of
date.
Again,
if
all
those
wonderful
fips
are
not
integrated
into
do
not
change
the
spec
as
well.
K
So
we
really
don't
want
this
to
happen,
because
it's
much
easier
to
change
it
bit
by
bit
when
the
fit
you
know
is
in
process,
rather
than
later
after
a
few
months
trying
to
integrate
100
fips
on
top
of
each
other
and
creating
another
mess.
So
it's
really
important
for
everyone
who
wants
to
create
a
new
fip
as
part
of
the
process
to
have
to
submit
another
pr
to
the
spec
repository
for
the
changes
that
need
to
be
done
to
the
spec.
K
Of
course,
this
does
not
apply
to
every
fip,
but
at
least
for
the
technical
ones.
We
should
have
a
parallel
pr
to
the
spec
process.
Now.
What
we
want
to
do
in
the
end
is
that,
on
the
spec
side
we
want
to
have,
you
know,
extend
the
dashboards
in
order
to
have
on
each
section
which
fips
have
touched
on
this,
and
edited
this
and
effectively.
We
want
to
have
nice,
versioning
kind
of
a
like
time,
machine
where
you
go
back
when
before
fip114
was
integrated.
K
What
did
the
spec
look
like,
and
that
would
be,
of
course,
all
of
the
spec,
but
especially
it
would
focus
on
the
specific
section
that
this
fit
touched
on.
So
there
is
currently
pr
number
11
in
the
fit
repository
it's
not
merged.
There
is
a
kind
of
ongoing
discussion
on
how
that
would
happen.
There
is
a
little
process.
It's
it's
not
too
complicated,
basically
before
something
is
either
accepted
or
final
or
merged.
K
There
should
be
some
evidence
that
you
know
there
is
a
pr
on
the
spec
site
as
well,
and
the
guy
the
team
or
the
person
responsible
for
the
fit
the
fit
authors
you
know,
do
an
update
to
to
the
spec
in
order
to
be
able
to
you
know,
automate
the
process.
What
we
did
was
that
we
have
assigned
a
a
unique
identifier
to
each
section
that
the
fit
is
going
to
touch
on
and,
of
course,
it's
not
necessary
that
the
fib
is
only
touching
one
section.
It
might
touch
multiple,
it
doesn't
matter.
K
This
goes.
This
identifier
will
go
to
the
front
matter
of
the
of
the
fib
itself,
and
the
spec
repository
will
pick
it
up
from
the
front
matter
there
and
that's
how
we're
going
to
create
all
the
extra
features
that
we
want
on
the
spec
side.
So
that's
the
summary
hugo
is
also
around.
I
don't
know
if
we
want
to
give
you
know
if
there's
any
more
detail
into
it,
yeah
it's
just
here
to
raise
the
flag,
basically
that
you
know
whenever
you
do.
K
Please
bear
that
in
mind
and
also
put
your
opinions
on
the
pr.
If
you
think
something
should
be
different.
Just
let's
discuss
it.
It's
it's
just
a
proposal.
A
Awesome
so
like
the
workflow
change
from
a
fip
creator,
perspective
would
be.
When
writing
the
fip
think,
look
through
the
spec
figure
out
which
sections
of
the
spec,
your
your
pr,
is
touching
or
changing
so
like,
for
example,
with
the
one
that
we
just
talked
about
this
morning.
We'd
look
at
like
gas,
section
actors
section
right
which
of
those
sections
are
being
touched
grab
to
the
little
link
hugo.
I
love
your
gif
in
the
in
the
pr
to
link
to
that
section.
A
Put
that
in
the
front
matter
of
the
the
fit
itself
add
to
the
fit
section
around
spec
like
what
you're
changing
or
is
there?
Is
there
a
new
section
within
the
description
itself
for
like
what
has
changed
like
a
link
to
a
pr
to
the
spec
or
something
like
that?
It.
L
Yeah,
it
doesn't
really
need
to
because
we
will
be
able
to
process
all
the
markdown
from
the
pr
itself
which
we
actually
just
need,
the
the
the
labels
in
the
markdown
in
the
feed
markdown,
just
that
so
I
can
even
like
in
two
seconds
just
give
you
a
rundown
and
how
easy
you
can.
Are
you
seeing
the
the
spec
website?
Yep
yeah?
L
L
You
click
here
and
then
you
copy
paste
this
stuff
or
if
it
touches
multiple
ones,
you
can
copy
paste
all
of
them
and
put
an
array
in
the
front
matter,
and
it's
done
after
that.
We
we
kind
of
need
to
have
at
least
one
like
test
fib
pr,
so
we
can
make
sure
everything
works,
but
the
base
process
and
our
ideas.
It's
all
just
this,
the
all
the
fib
writer
needs
to
do
just
go
to
the
main
index
copy
paste.
L
A
K
Yeah
exactly
we
should
think
about
it.
You
know
imagine
what
it's
going
to
be
like
in
10
years
from
now,
and
you
know
a
few
thousand
flips
so
that
it's
gonna
be
really
interesting
to
have
that
that
thousands
of
steps
later.
L
Really
important,
like
the
release
cycle
on
the
spec
itself,
is
gonna,
be
really
done
in
parallel
with
fips.
L
Very,
like
other
changes
are
to
be
like
small
everything
will
come
from
the
fips
everything's
changed
from
when
we
we
mostly
stable
right
now.
Every
change
to
the
spec
itself
to
the
content
will
come
from
fib,
so
the
versioning
is
really
tied
to
the
to
the
feed
process.
H
On
that
topic,
I
was
just
wondering:
is
there?
Is
there
any
thought
into
when
there's
going
to
be
a
more
regular,
hard
fork
cycle,
it's
kind
of
been
like
very
sporadic
like
it's
like?
Sometimes
I
think,
there's
like
five
hard
forks
in
the
last
like
month
and
a
half
or
something
I
was
wondering
if
there's
gonna
be
a
regular
cadence,
because
that's
gonna
affect
how
the
specs
get
released
too
right.
So.
A
Yeah,
I
think
we're
gonna
be
somewhat
asymptotically
decreasing
there,
where,
like
you
know,
starting
out
from
a
pretty
agile
perspective
like
right
now,
yeah
pre-made
net.
We
had
like
one
like
every
week
and
a
half
or
something
which
is
pretty
fast
and
definitely
not
sustainable
in
the
long
term.
So
I
think
we're
gonna,
like
probably
for
the
next
couple
of
months,
be
aiming
for
something
like
once
a
month
in
a
good
case.
A
You
know,
of
course
you
never
know
when
things
come
up,
that
we
really
want
to
get
in
faster,
but
I
think
that
that
is
probably
decent
for,
like
the
first
three
three
to
six
months
and
then
probably
moving
to
more
of
a
quarterly
cadence.
After
that.
I
think
that
we
don't
want
to
have
like
specific
deadlines
and
times
in
a
schedule
or
anything
like
that,
but
just
trying
to
aim
for
ourselves
just
to
get
to
a
point
where
we're
bundling
more
changes.
A
It's
just
going
to
make
work
easier
for
all
of
us
to
stay
in
sync
as
well
so
yeah,
I
think
probably
it'll,
be
you
know,
aiming
towards
monthly
for
the
next
three
to
six
months,
yeah.
When
you
say
hugo
about
the
versioning
of
of
the
spec
tied
to
versioning
of
fips,
is
there
anything
we
need
to
add
to
the
pr
around,
as
as
a
fip
editor,
when
you
change
a
fip
to
accepted,
to
go
and
merge
the
spec
pr
associated
with
it,
just
to
make
sure
that
those
things
happen
in
sync?
A
Maybe
that's
already
in
your
pr,
but
just
making
sure
that
those
things
stay
tied
to
each
other?
Is
there
gonna
be
an
actual
version
number
in
the
spec
that
we're
gonna
be
bumping
or
anything
like
that.
K
The
reasons
right
now,
but
I
think
we
should
the
fit
editor
basically
before
they
hit
the
merge
button
for
the
feed.
They
should
check
that
a
pr
is
at
least
in
in
progress.
You
know.
Maybe
there
is
ongoing
discussion
in
the
spec.
You
know
for
phrasing
and
editorial
stuff,
but
that's
okay.
As
long
as
the
main
part
of
the
work
has
been
done,
it
should
be
okay,
but
it's
up
to
the
editor.
I
think
that's
the
best
approach
but
yeah.
K
If
we
missed
that,
please
to
the
pr
I
think
it's
there.
I
think
it's
there,
it's
being
discussed.
A
A
Awesome
that
is
it
for
our
scheduled
agenda.
I
don't
believe
we
have
any
other
issues
or
changes,
refreshing
the
issues
page
to
make
sure
yep
nope.
Anyone
else
have
anything
to
add
to
our
agenda
or
that
folks
want
to
discuss.
A
Cool
well,
thank
you
all
so
much
for
presenting
during
liftoff.
It's
been
awesome.
It's
gonna
be
continuing
to
be
a
really
awesome.
Week,
definitely
tune
in
the
rest
of
today
and
tomorrow,
still
a
lot
of
really
phenomenal
talks.
There's
gonna
be
some
cool
stuff
coming
out
with
in
juan
and
brewster
kale's.
Fireside
chat
in
a
couple
of
hours
so
check
that
one
out,
but
other
than
that
things
seem
smooth
sailing
with
the
upcoming
upgrade
and
yeah
from
here.
A
It's
hardening
stability,
improving
you
know,
sinking
as
steven
was
mentioning
lots
of
lots
of
fun
little
but
very
important.
Things
happening.
E
Yeah
there
are
yeah,
there
are
lots
of
your
folks
actually,
and
so
we
need
to
handle
all
this
and
yeah.
It's
yeah
just
need
some
time
to
do
all
this.
A
State
upgrades
yeah
definitely
always
always
more
work
to
do
on
that,
and
you
know
always
trying
to
make
things
better
so
that
helps
as
well.
E
A
Yeah,
it's
a
good
point
that
is
the
it
is
based
on
on
the
schedule.
It
is
at
5
pm
utc
instead
of
at
4
pm
utc
because
of
daylight
savings
time.
A
Well,
maybe
this
is
the
you
know,
nudge
for
me
to
hand
this
off
to
someone
else
who
then
starts
running
these
meetings
going
forward
such
that
I'm
no
longer
the
blocker
of
waking
up
insanely
early
in
the
morning,
but
I
think
we
can.
We
could
try
to
make
it
one
hour
earlier
if
that
works
for
other
folks.
For
those
of
us
who
do
follow
daylight
savings
time
such
that
it
stays
at
4
pm
utc,
because
I
know
that's
already
still
super
late
for
for
china.
A
A
Yeah
speaking
of
budget
happy,
you
know
happy
q4
and
daylight
savings
time
to
everyone.
It's
fall.
It's
crazy.
A
Then
have
a
wonderful
thursday
and
we'll
see
you
around
and
all
the
talks
hang
out
and
gather
town
in
our
little
lounge
and
have
a
wonderful
rest
of
the
week.