►
From YouTube: 2019-10-08 Rook Community Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
we
have
the
1.1.2
released
last
Wednesday
and
I
know
there
are
some
things
that
have
been
backported
since
then
I,
don't
know
of
any
burning
issues
to
get
that
release
out
those.
So
I'm
thinking
you
know
one
dot,
one
dot
three
would
be
next
week,
potentially,
unless
somebody
has
something
more
urgent.
A
B
Okay,
title
No,
yeah
and
I
should
probably
a
factor
that
rebates
that
rather
with
yeah
I,
just
master.
A
And
then
some
of
these
other
things
you
know,
there's
ads,
set
version
check.
Oh
this,
this
isn't
really
urgent,
but
there's
some
things
around.
Removing
OSDs
automatically
no
Dimitri
metion
had
questions
around
at
least
about
whether
that's
a
good
idea,
because
if
it
was
to
use
just
down
for
a
bit-
and
he
expects
it
to
come
back,
he
doesn't
want
Brooke
to
remove
it
so
that
there's
anyway,
that
seemed
around
safe
to
destroy
OS
teases.
As
a
good
question
to.
A
B
A
A
A
A
A
B
A
A
A
A
C
So
we
got
two
bots.
The
first
one
is
called
merge,
Fi,
which
basically
allows
us
to
get
smoother
backboards
by
applying
labels
to
PRS
particular
labels,
points
to
particular
release
branches.
So
the
workflow
is
the
following:
you
spin
a
PR
on
master,
then
you
have
reviews
from
dinner's.
Then
you
get
approvals,
NCI
goes
dream
and
then
someone
from
the
maintainer
is
T
emergency.
C
C
Yet
I
think
it
is
but
correct
me
if
I'm
wrong
Travis
the
CI
will
run
and
if
the
CI
goes
green,
then
vertifight
will
also
merge
the
back
port
PR,
as
well
as
removing
the
branch,
so
that
basically
maintainer
is
don't
have
to
care
about
back
pours
anymore
in
terms
of
the
only
in
terms
of
just
approving
and
merging
manually
again,
the
only
thing
they
have
to
do
is
just
to
resolve
conflicts.
If
there
are
any.
So
that's
for
the
the
first
pot
yeah.
A
And
one
comment
around
that
too,
and
it's
been
awesome
to
have
that
in
place.
It's
simplified
backwards,
a
lot.
So
the
the
point
of
approval,
then
for
back
boards
is
when
whoever
has
merge
access
merges
to
master.
They
should
look
for
that
backboard
tag
and
if
they
think
it
must
be
bad
backported
and
we
add
the
tag,
but
you
know
if,
if
we
don't
think
it
should
be
merged,
we
should
remove
the
tag
before
merging
to
master
and
anyway,
as
part
of
merging
to
master.
A
We
should
have
in
our
mind:
should
this
be
back
ported
and
I
don't
remove
the
tag
accordingly.
So
then
the
butt
can
do
the
right
things
just
immediately
at
that
point,
and
we
don't
have
to
revisit
whether
to
back
port
and
in
the
future
is
just
at
that
point.
It's
considered
approved
if
the
tags
there
and
it's
merged
to
master.
C
Yeah,
so
then
you
also
resolved
the
permission
issue
for
the
bot
to
grab
yourself.
Okay,
so
we
have
all
the
workflow
in
place
and
yeah.
Just
like
Silas
mentioned
it's
a
little
bit
more
like
common
sense,
but
we're
still
trying
to
get
some
control
over
what
is
going
to
be
backported.
By
definition,
every
bug
fixes
can
be
recorded,
but
people
might
be
tempted
to
backboard
features
as
well
things
that
we
don't
actually.
So
that's
for
the
first,
but
the
second
one
is
basically
a
commitment,
I
guess
if
you
really
want
to
bring
some
quality.
C
Although
the
project
people
really
have
to
understand
that
the
contribution
known
not
only
mean
providing
code
but
also
providing
good
documentation
and
proper
commit
messages
as
well,
so
the
bot
actually
ensures
that
the
commit
has
commits
title
as
well
as
a
comic
body,
a
comic
message
in
it
explaining
what
the
code
is
about.
If
it's
a
bad
fix.
C
If
it's
a
feature
so
that
yeah,
when
someone
looks
at
the
kid
history,
then
we
all
remember
what
happened
for
this,
for
this
particular
commit
so
yeah,
it's
funny,
because
today
I've
read
something
on
Twitter
and
this
is
this
was
about
documentation,
but
I
think
this
can
really
apply
to
to
get
nice
get
messages
as
well
for
comments.
Is
that
a
thing
that
it
was
saying
that
when
you
write
documentation
or
then
from
you
know,
when
you
write
get
message,
get
commit
messages?
C
It's
like
writing
a
love
letter
to
yourself
in
the
future
so
that
when
you
just
get
it
or
when
you
come
back
to
that
specific
comments,
then
you're
super
happy
to
see
that
everything
was
well
explained.
So
yeah,
that's
actually
yeah.
This
was
really
interesting.
Yeah
I
think
it's
a
nice
way
to
put
it
so
you're.
Basically,
thinking
is
stuff
in
advance.
By
doing
so
so
we're
trying
to
enforce
that
for
every
and
any
new
or
regular
contributors.
C
A
Next
thing
I
got
an
agenda,
is
so
formalizing
rook
API,
so
there's
you
know,
there's
been
this
well
rook
as
a
storage
platforms
for
kubernetes
we
haven't
yeah.
We
haven't
really
put
effort
into
what
that
API
looks
like
we've
put
more
effort
into
the
storage
providers
themselves
and
in
doing
so
when
there
are
features
and
storage
providers.
A
Anyway,
I
created
a
first
draft
of
a
doc
for
what
features
we
might
consider
or
might
be
reusable
by
the
different
storage
providers.
It's
a
really
early
draft,
but
if
you're
interested
in
that
discussion,
let
me
know
and
I'd
be
happy
to
share
the
doc
with
you.
So
we
can
just
expand
that
list
and
look
at
what
and
how
we
can
expand
that
API
to
be
as
useful
as
possible
and
it'll
just
be
a
good
thing
for
the
community.
A
B
This
is
just
the
first
issue:
I,
don't
know
what
is
your
preference
to
get
to
one
big
commit
or
a
big
PR
or
a
lot
of
smaller?
So
this
is
the
first
version
and,
for
example,
the
proper
persistent
storage
handling
is
missing,
so
it
can
install
now
so
and
those
who
can
work
create
inferior.
That's
what
can
be
done
with
this
operator
as
of
now
and
all
of
the
resource,
customary
source
definition
handling
and
all
of
this
part
and
I'm
planning
to
create
more
order
to
request.