►
From YouTube: February 2021 OpenZFS Leadership Meeting
Description
At this month's meeting we discussed: release scheme and numbering; DirectIO PR; pool feature compatibility PR; force export PR.
meeting notes: https://docs.google.com/document/d/1w2jv2XVYFmBVvG1EGf-9A5HBVsjAYoLIFZAnWHhV-BM/edit
A
A
We
do
not
have
much
on
the
agenda
today,
so
lots
of
opportunities
for
discussion
and
q
a
so
I'll
start
with.
The
one
item
is
the
last
last
month's
meeting
we
talked
about
muhammad
from
seagate
was
talking
about
how
zfs
could
potentially
use
take
advantage
of
the
command
priority
interfaces,
and
there's
gonna
be
a
meeting
tomorrow
with
folks
from
seagate
to
to
talk
about
that.
So,
if
you're
interested
in
that
then
get
in
touch
with
muhammad
on
email
or
on
slack,
the
meeting
is
tomorrow.
A
B
B
Yeah
so
2o
pretty
much
has
everything
that
you
know.
The
only
big
thing
missing
from
at
the
moment
is:
let
me
go
back
so
right
now,
the
only
new
feature,
that's
in
master
that
isn't
in
2o
is
d-ray
right,
and
so
there
was
no
huge
rush
necessarily
to
get
2.1
out,
so
we
would
like
to
get
direct
iowa
in
it
as
well.
I
know
we'd
like
to
get
that
out
sooner
rather
than
later,
so
we're
working
to
get
that
work
wrapped
up,
but
it's
going
slower
than
I
would
have
liked.
C
No
yeah,
those
bugs
slightly
worry
me,
I'm
just
thinking
about
timeline
in
context
of
freebies
13
release
is
going
to
be
branched
this
week
and
no
release.
Obviously
in
march,
but
right
now
we
appeared
in
state.
You
know
in
in
master
and
present
state
of
master
sounds
better
to
me
rather
than
state
of
after
drop
in
something
that's,
as
you
said,
not
exactly
stable,
so
yeah.
B
C
C
No
I'd
say
it's
like
when
it
when
it
was
the
merge
was
done.
There
was
kind
of
discussion,
that's
in
between
you
and
matt
pasey,
and
the
idea
to
have
2.1
release
it
before
timeline.
So
we
would
go
to
12.
2.1,
but
now
2.1
is
delayed
and
we
appear
in
master
middle
of
nowhere
between
2.0
to
0.1
and
how
then
to
follow
stable
branch
for
release
and
after
release
yeah.
C
B
Yeah,
we
don't
want
to
maintain
more
versions
than
we
have
to
right,
so
I
guess
we
should
figure
out
what
exactly
you
guys
need
and
what's
the
best
thing
to
stabilize
on,
like
I
say,
2.0
is
the
thing:
we've
been
probably
the
most
stable
thing
out
there
right.
It's
seen
the
most
testing
and
it's
only
just
missing
that
one.
So
if,
if
if
the
need
is
to
have
derailed,
then.
C
C
A
B
C
Yeah,
I
I
have
no
problems
with
with
merging
the
things
that
can
be
emerged
that
that
just
what
to
do
is
already
with
the
code
that's
already
pushed
to
master
and
going
to
appear
in
this
particular
institution
already.
Shooting
is
already
branched,
just
not
13.0,
so
it's
going
to
get
too
stable,
we
would
have
to
revert
yeah.
A
B
C
A
B
Yeah,
so
historically,
we've
done
just
one
branch
basically
and
kept
it
up,
which
is
fine,
but
the
branches
used
to
be
pretty
long
lived.
You
know
a
year
18
months,
something
like
that.
We
had
thought
about
keeping
that
you
know
doing
that
again
this
time,
but
I
don't
know,
I
don't
know
that
we
thought
about
it
that
much.
We
could
certainly
keep
doing
point
releases
on
that
branch.
B
I
think
part
of
the
problem
is
at
least
on
the
linux
side.
The
distributions
would
much
prefer
to
have
something
to
stabilize
on
and
get
bug
fixes
for
just
like
right.
That
would
be
the
two
release
right
yeah,
but
I
think
they
would
view
a
change
from
like
2.0
to
2.1.
That
adds
a
major
feature
as
being
a
bit
of
a
problem
right.
A
B
A
Think
that
we
should
stick
to
like
each
major
release
is
one
branch?
That's
the
stable,
like
that's
the
stable
stuff.
You
want
to
be
on
the
stable
release
you
get
on
to
the
you
know
you
get
onto
the
latest
release
and
you
know
we
maintain
like
two
major
releases
at
a
time.
Roughly,
you
know
less
one
or
two
major
releases
at
a
time
right
at
most
right,
like
maybe
we're
doing
backwards
to
0.8
and
we're
doing
backwards
to
two
to
two
right
now,
but
not
more
than
that.
A
B
B
They
would
like
that
to
exist
for
a
while
right
and
that
had
been
two
out
we,
I
had
been
targeting
2-0
to
get
point
releases
for
a
long
time,
just
with
little
back
ports
and
fixes
and
keep
that
branch
maintained.
That's
still,
honestly,
what
I'd
prefer
and
keeping
two
branches
isn't
terrible,
but
if,
if
d
raid
goes
in
2.1
and
direct
io
goes
in
2.2
right,
it
gets
a
little
show
me.
So
many
ranges.
C
B
C
B
C
B
A
I
mean
if
you
want
to
maintain
end
branches
like
it's.
It's
no,
you
know
I'm
not
doing
that
work.
So
if
you
want
to
do
that,
work
go
ahead,
but
I
to
me,
like
it
seems
like
a
better
use
of
our
collect
the
collective,
our
effort
to
maintain
fewer
branches,
fewer
branches
through
release
branches
and
to
say,
like
yeah.
You
know
either
we're
putting
a
major
release,
we're
putting
a
a
major
feature
into
a
into
an
existing
release
or
to
say
that
we're
making
a
new
release
a
new
major
release
for
that
new
major
feature.
C
B
B
A
A
It
just
seems
to
me
like,
if
you're
I
mean,
if
you're
gonna
create
a
new,
if
you're
gonna
create
a
new
branch
and
you're
gonna
maintain
like
you're
gonna,
maintain
it
separately
as
like
there's
the
old
branch
and
then
there's
the
new
branch,
then,
what's
really
the
difference
between
calling
that
new
one
2.1
versus
2.
versus
3.0,
like
you
either
way
you
have
to
you
know
if
you're
saying
like
I
want
to
create
a
new
branch
and
maintain
and
we're
going
to
maintain
it
and
the
old
one.
B
B
Yeah
yeah
yeah.
I
guess
I'm
not
sure
how
to
answer
exactly
like
I'm
not
particularly
hung
up
on
the
number
of
it.
It's
just
how
many
branches.
To
maintain.
From
my
point
of
view,
I
would
prefer
to
maintain
fewer
right.
I
would
prefer
to
maintain
none.
If
people
want
to
help
step
up
and
maintain
a
branch,
we
can
get
a
maintainer
for
the
brain.
That
would
be
great.
B
C
B
Yeah,
so
I
mean
the
plan
of
record
for
2-1
was
to
get
direct.
I
o
in
as
soon
as
it
was
in
branch
it
and
hopefully
get
that
tag
release
out
in
q1.
So
you
know
sometime
in
the
next
two
months
at
least
branch
for
it.
I
don't
know
if
that
works
for
freebsd's
time
frame,
but
that
was
the
intention
and
I
was
going
to
maintain
a
2-0
and
a
2-1
branch.
B
A
That
kind
of
locked
you
into
being
dependent
on
this
open,
zfs
release
happening
in
the
right
time
frame
for
you.
What's
the
plan?
Is
the
plan
going
forward
that
freebies
d
will
continue
to
like
use
open,
dfs
master
and
then
and
then
it
will
line
this
up
again
and
have
this
risk
again
or
is
it
going
to
switch
over
to
to
release
to
open
zfs
releases
in
general.
C
C
B
C
So
again,
three
busy
major
branches
are
forked
on
quite
a
schedule
and
long
far
in
advance,
and
this
was
now
and
next
will
be
in
about
18
months.
So
it's
kind
of
schedule
more
or
less
strict.
It's
not
feature
based
it's
more
like
more
time
based
so
by
the
time
things
happen
next
time
we
should
bet,
prepare
better.
Do
it
and
coordinate.
B
C
C
A
Brian,
are
you
for
the
future
releases
like
let's
say
after
this
after
we
release,
whatever
release
has
direct
io
in
it?
Are
you
thinking
that
minor
releases
like
2.2,
2.3
2.4
would
would
also
be
branches
that
we
would
maintain
like
in
parallel
with
with
previous,
you
know,
2.02.1,
or
would
we
not
have
those
generally,
and
we
would
just
have
a
two
one,
one
two
one,
two
two
and
three.
B
B
I
don't
know
three
four
or
five
months
whatever
it
is
six
months,
something
like
that
from
something
a
little
more
frequent,
and
it
was
an
open
question
about
how
those
branches
would
all
get
maintained
right
if
we
just
maintain
the
last
one
or
we
do
something
like
you
know,
maintain
the
last
one
and
then
like
say
2.0.
We
just
maintain
for
a
longer
time
kind
of
like
an
lps
sort
of
thing.
A
I
think
it'd
be
nice
to
be
able
to
look
at
the
number
and
then
understand
like
okay.
This
is
part
of
the
whatever
you
know
like
2
2.2
is
part
of
the
two
release
branch
right
and
so
like
within
two,
it's
all
just
accumulating
versus
being
like.
Oh,
you
know,
this
is
2.6
well
in
2.
in
2.4
we
made
that
a
maintained
branch.
So
it's
like
you
know,
four
five
and
six
are
are
together
and
then,
like
you
know
one
and
in
one
two
three
are
together.
You
know
what
I
mean
like.
A
A
B
What
would
we
consider
a
major
release?
I
guess
would
be
a
question
then
like
what
denotes
something
as
a
major
release,
as
opposed
to
a
minor
release
so
like
with
the
current
version
numbering
we've
pretty
much
adopted
semantic
versioning.
So,
within
those
release
branches,
we've
cut
we're
pretty
much
guaranteeing
like
no
api
changes
for
that
kind
of
thing.
No
library
changes
so
we're
keeping
those
changes
out.
B
B
B
C
B
C
The
more
important,
even
not
library
interfaces,
but
that
too,
but
much
more
often
happens
between
kernel
user
space.
So
practically
you
can
update
your
kernel
and
still
be
able
to
boot
and
then
update
world
and
separate
step,
so
at
least
that
has
to
work
if
not
well.
Of
course,
you
can
just
have
applique
previous
applications
in
jail
with
previous
applications
and
libraries
and
all
also
supposed
to
work
with
newer
kernel
at
least
one
way.
C
B
A
A
A
C
Yeah,
I
think
the
main
we
should
do
is
write
some
kind
of
timeline,
some
plan.
What
versions
will
be
released
when
of
where
they
be
forked
from
and
how
long
they
are
going
to
be
supported?
Something
like
that
we
got
to
that
last
year
or
two,
because
it
was
quite
random
before,
but
now
it's
pretty
stable.
All
releases
are
announced
at
few
months
in
advance
from
branching
and
then
holds
up
regularly
updated
every
few
weeks.
C
C
A
I
don't
think
that
we
can
be
well.
I
don't
think
that
we
want
to
be
quite
as
strict
as
the
calendar
strictly
calendar-based
freebsd
I
mean
open.
Zfs
is
a
smaller
and
a
younger
project,
but
having
having
the
plan
written
down
somewhere,
including
like
branching
and
what's
gonna,
be
maintained
for
how
long
and
whatnot
would
be
would
definitely
be
good.
B
I
think
that's
something
we
should
have
to
decide
if
that
constitutes
a
major
release
or
or
what
or
what
kind
of
support
guarantees
we
want
to
offer.
For
that
all
right,
I
think,
for
the
200
release.
We
definitely
want
to
maintain
that
for
a
year
two
years,
whatever
it
is,
whatever
makes
sense
for
that
and
then
maybe
the
newer
two
releases
don't
get
sport
for
quite
as
long.
A
A
B
A
Together
cool,
oh
I
I
did
have
one
other
question
for
you,
brian,
getting
getting
back
to
the
actual
the
the
non-release
work
for
for
direct
ido
who's
who's
working
on
that
now
is
that
I
know
ryan
atkinson
was
doing
a
lot
of
work
on
that.
Is
he
still
working
on
that?
Are
you
working
on
that?
Is
anybody
else.
B
B
B
B
I
don't
know
off
hand
what
the
full
request
number
is
for
that,
but
there's
an
implementation
there
that
lets.
You
basically
set
a
property
that
lets
you
limit,
which
features
get
automatically
enabled
when
you
do
a
pool
upgrade
and
which
ones
get
complained
about
when
you
do
a
vpool
status,
so
you
can
make
sure
that
you
lock
in
a
particular
compatibility
level,
be
great.
If
people
can
look
at
that
and
give
feedback
on
it,
there's
also
an
open
pull
request
for
the
forced
export
work.
We
talked
about
a
few
months
back
too.
A
B
I
think
the
forced
export
stuff
could
benefit
from
some
people
looking
at
it
just
to
make
sure
they're
happy
with
the
design
decisions
that
are
being
made
there,
because
it
touches
a
lot
of
things
like
the
transaction
handling
how
to
unwind
things.
It
all
looks
pretty
reasonable,
but
it
touches
a
lot
of
that
stuff.
So.
A
C
A
It's
the
second
again
2nd
of
march,
not
september,
contrary
to
my
tweet,
which
I
don't
know
where
september
came
from.
But
september
is
what
came
out
of
my
fingers
when
I
typed
that
yeah.
So
the
next
meeting
will
be
at
the
same
time
as
this
one
o'clock
pacific
on
march,
2nd
and
again,
if
you're
interested
in
the
interfaces
with
disk
drives
there'll
be
that
meeting
tomorrow
tomorrow
morning,
pacific
time,
all
right
thanks,
everyone.