►
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
Hello
everyone.
This
is
the
first
ever
release
a
perspective
for
the
cluster
API
team.
In
this
meeting,
we'll
basically
take
a
look
back
at
the
1.4
release
that
1.4
release
cycle
that
we
just
finished
and
try
to
see
what
try
to
recall
what
went
well
about
the
release.
A
What
could
have
been
improved
about
the
release
and
then
we'll
discuss
through
each
of
those
items
for
a
bit
and
then
and
then
try
to
come
up
with
action
items
for
the
upcoming
release,
teams
right
action
items
on
how
the
overall
release
process
can
be
improved.
A
So
for
that,
let
me
just
share
the
link
to
this
talk.
We
are
going
to
use
a
release
team
meeting
notes
as
usual
at
the
top
I
just
added
the
section
for
the
retrospective.
A
So,
let's
take
a
few
minutes
now,
if
you
want,
you
can
turn
off
your
cameras
or
put
away
and
then
just
list
down
the
points
that
you
think
went
well
in
the
release
and
think
why
list
on
the
points
that
you
think
could
have
been
improved
in
the
release
and
while
doing
this,
if
you
see
a
similar
point
from
someone
else
that
you
would
also
like
to
mention
just
plus
one
it
or
if
you
find
some
other
points
that
you
really
connected
with
this
plus
one,
then
once
we
have
once
we
have
a
list
of
points
here,
we'll
go
through
them
and
then
we'll
as
a
group,
discuss
and
then
come
up
with
action
items
for
what
we,
what
we
just
discussed
does
that
sound
good
for
everyone?
A
Okay,
yeah!
Let's,
let's
take
a
few
minutes
and
start
writing,
start
writing
whatever
you
feel
went
well
and
whatever
could
have
been
improved
in
the
last
release.
I'll
stop
screen
sharing,
but
yeah.
Please
go
ahead
for
now.
A
B
C
A
Okay,
this
is
a
good
set
of
points
to
get
started,
so
we'll
try
to
alternate
between
what
went
well
and
what
could
have
been
improved
so
that
not
as
so
as
to
not
pile
upon
any
one
thing,
and
once
we
go
through
each
of
these
points.
Let's
start
writing
down
some
action
items
on
how
what
should
be
considered
for
the
next
series
team
or
what
should
we
considered
for
the
next
time
right,
we'll
we'll
start
we'll
start
with
what
went
well,
the
first
point
who
who
wrote
this
first,
one.
D
D
I
think
that
at
least
helped
a
lot
to
get
the
teams
kind
of
in
sync
to
know
what's
going
on
and
what
was
blocking
or
not
blocking
other
teams.
So,
as
the
comms
team,
we
didn't
really
know
what
was
going
on
with
the
the
CI
team
as
much.
So
that
was
a
really
nice
way
to
be
able
to
give
insight
into
to
kind
of
the
holistic
process.
A
Thanks
that
sounds
good,
so,
basically
we
should
continue.
The
regime
should
continue
having
regular
sync
UPS
weekly
sync
upset.
That
makes
sense
of
a
sense.
Okay,
let's
do
one
what
could
be
improved,
I
think
I
wrote
this
oh
and
I.
Think
for
president,
do
you
want
to
just
speak
about
it.
E
Yeah,
it
is
not
a
big
deal,
but
category
is
still
require
maintenance
to
to
be
around
yeah
yeah.
If
we
can
fix
it,
it
will
make
the
release
team
owns
the
release
from
A
to
Z
yeah
nearly
yeah.
So
there
is
not
still
let
it
fly
to
figure
it
out,
but
okay,
yeah.
A
Definitely
agree,
I
believe,
basically
having
automation
around
the
release
process
so
that
it
falls
down
to
like
someone
approving
a
PR
would
be
ideal
so
that
the
release
team
can
work
through
getting
the
PRS
out
getting
the
release
process
PR
out,
and
then
someone
from
the
maintainer
will
just
have.
Someone
from
the
maintenance
will
just
have
to
approve
the
peer
right
instead
of
having
to
spend
a
lot
more
time
on
tagging
the
release
tagging
the
comments,
pushing
them
waiting
for
the
images
to
be
ready
and
then
release
publishing
the
release
and
so
on.
A
So
it
takes
up
a
lot
more
time
for
a
maintenance
to
be
involved
with
the
release
team,
especially
on
the
day
the
release
is
being
cut
so
yeah,
definitely
plus
one
for
that
yeah.
Let's
do
one.
What
went
well
yeah
the
releases
and
the
process
of
cutting
releases
was
smooth
like
this
is
kind
of
again
what
we
around
the
same
topic
yeah,
even
though
we
have.
A
We
depend
on
a
maintainer
to
actually
do
this
it
during
this
release
cycle
there
weren't,
really
that
many
hiccups
that
came
up
and
we
were
about
to
cut
any
of
the
releases.
Fortunately,
all
of
them
went
really
smooth
and
that
that
was
good
and
it
that
went
really
well.
A
What
could
be
improved,
CI
signal
flakes
are
still
a
pain.
Yes,.
E
There
is
again
me,
and
you
can
mix
it
up
with
the
the
second
one.
So
yeah,
let
me
say
CI
is,
is
the
the
key
point
for
for
a
release
and
I
think
that
my
point
is
that
we
have
to
find
a
way
to
share
the
knowledge
behind
how
to
issue
triage,
how
to
debug
of
failures
in
CI
et
cetera
Etc,
so
we
don't
depend
always
on
Stefan
or
Killian
or
yubaraki,
jumping
on
on
one
of
them.
E
E
Every
week
I
don't
know
on
Friday
or
whatever,
whenever
it
is
convenient
for
a
group
of
folks.
If
there
are
flakes,
we
do
a
egg
session,
let's
fix.
Let's
speak,
let's
try
to
fix
flakes
who
As
Time
joins,
and
so
we
start
basically
spreading
the
knowledge
around
this
happen
is
my
suggestion.
I
was
discussing
this
with
Stefan
before
he
went
to
PTO,
but
it
could
be
nice.
E
We
need
to
share
this
knowledge
and
I
think
that
in
e,
my
my
suggestion
is,
if
we
can,
let
me
say,
add
to
the
CI
team,
basically
the
the
goal,
to
try
to
learn
how
to
do
this.
It
is
a
good
chance
because
you,
you
combine
people
which
express
the
interest
in
the
cnci
senior
with
people
that
is
offering
knowledge,
and
so
it
could
be
a
way
to
maximize
the
effort
that
me
Stefan,
Kilian
and
others
will
do
in
making
these
public
sessions
being
joined.
A
Okay,
I
wrote
a
rough
note
on
the
action
item
that
you
described
for
physio.
That
is
definitely
good
because
I
think
in
this
release
one
thing
that
came
up
one
thing
that
was
constantly
observed
was
there
wasn't
clear
boundary
on
what
the
CIA
team
is
supposed
to
do
in
terms
of
fixing
flakes
right
is
it
is.
A
Are
they
just
supposed
to
take
a
look
and
report
that
the
flakes
were
available
are
happening
or
are
they
also
supposed
to
debug
kind
of
those
Flakes
and
do
a
little
more
analysis,
or
that
was
a
little
unfair?
It's
a
silk.
Go
ahead.
F
Yeah,
can
you
hear
me?
Okay,
yes,
for
context
yeah,
when
Stefan
and
I
were
like
putting
together
the
docs
for
the
roles,
we
actually
went
back
and
forth
on
this
question
quite
a
bit
and
we
weren't
sure
if
we
should
include
fixing
the
flakes
as
part
of
the
rule.
In
the
end,
we
decided
not
to
to
start,
because
we
were
worried
that
it
would
be
too
much
and
we
didn't
want
the
first
release
theme
to
just
be
overwhelmed
and
it
to
be
too
big
of
a
time
commitment.
F
So
we
decided
to
just
keep
it
as
a
triage
monitoring
role
for
now
and
then
we
said
we
can
revisit
this
later.
So
I'm
really
glad
we're
revisiting
this
and
that
you're
sharing
these
observations.
E
Yeah
I
I
kind
of
agree,
let
me
say:
I
I,
don't
think
that
we
should
set
on
the
team
and
the
the
honest
to
fix
everything,
because
it
required
knowledge.
I.
Think
that
the
the
team,
the
the
let
me
say,
the
being
enrolled
in
the
CI
team
should
be
for
them
an
opportunity
to
learn
and
I.
I
will
try
to
make
this
way,
so
they
don't
feel
the
pressure
to
feel
it,
but
they
are
offered
the
possibility
to
learn
and
if
they
do
it,
the
better
yeah.
Okay,.
A
Moving
on,
let's
do
one
100.
This
is
me
yeah
having
a
good
set
of
documentation
and
having
the
list
of
tracking
issues
that
we
had
for
all
of
our
items
right.
The
entire
release
process,
the
kubernetes
version
bomb
and
the
release
implements
helped
in
the
entire
release
cycle
because
they
acted
as
guides
for
the
entirely
cycle.
A
So
that
was
a
huge
plus
one
for
me,
and
the
action
item
here
would
basically
just
be
that
we
should
make
sure
that
the
release
docs
are
up
to
date
and
are
constantly
updated
with
any
changes
that
you're
doing
and
I
agree
with
Cecile
the
Stefan
helped
in
creating
all
of
these
docs.
So
big
thanks
to
him
so
for
basically
enabling
the
Smooth
release
class.
A
Okay,
let's
do
one
what
could
have
been
improved
parking
initiative
course
was
not
clear
still
to
the
release
team.
That's
this
kind
of
fall
with
what
we
already
discussed
in
discussion
or
about
issue
triage
citaj,
I,
don't
know
who
wrote
this
point.
C
Yeah,
that
was
me
yeah,
it's
still
I
think
Paul's
internet,
but
also
all
the
upcoming
issues.
It's
not
only
just
the
tests
old
upcoming
issues
to
the
repo.
How
that,
like
those
should
be
handled
like
to
that
CIA
team
members,
always
watch
and
try
to
challenge
them
or,
if
not
paying
the
maintenance,
or
that
was
a
bit
unclear,
I.
Think
from
the
sea
team
point
of
view.
That's
why
I
just
brought
it
up
cool
I
know
we
did.
E
Seal,
do
you
remember
what
is
the?
What
was
the
intent
for
this
area.
F
Yeah,
so
the
intent
initially
we
had
said,
was
for
the
release
team
to
be
monitoring
and
triaging,
as
in
like
opening
filing
issues
and
checking,
if
there's
already
a
known
issue
for
flakes
that
were
coming
up
and
being
in
charge
of
essentially
assessing
if
the
CI
signal
was
blocking
before
release,
but
not
to
investigate
issues
and
not
to
fix
them.
F
E
Yeah-
and
let
me
say,
maybe
this
follow
a
little
bit
on
me,
because
I
continue
to
do
triage
without
waiting
for
the
release
team
to
take
a
look
at
the
stuff.
First
to
all
the
issue
not
being
from
flakes
I
I,
don't
know,
let
me
say
if
the
the
release
team
would
want
to
take
care
of
also
of
everything,
of
all
the
incoming
issue
and
do
a
first
triage,
I'm
kind
of
okay,
a
little
bit
worried
by
expanding
the
scope.
A
F
F
It
was
a
big
ask
if
it
was
people
that
were
going
to
be
like
newer
at
you
know
the
project,
so
we
still
wanted
them
to
be
able
to
rely
on
everyone
else
who
was
around
and
we
wanted
the
release
team
to
be
a
more
I
guess:
excess
accessible
thing
that
more
people
could
participate
in,
so
that
we
don't
because
the
the
main
goal
is
to
extend
or
expand.
Who
can
do
releases
right
and
not
it
be
always
the
same
few
folks
or
the
same
group
of
maintainers.
A
I
have
one
question
here:
I
think
that
might
be
talking
about
two
things:
one
is
triaging
CI
itself,
and
this
is
bug
and
issue
triage.
That
comes
into
the
repo.
Like
someone
reports,
a
new
bug
or
someone
opens
a
new
issue
into
repo
that
triaging
should
not
fall
on
the
CI
team
right.
That's
this
community
in
the
general.
Maintaining
issues
on
the
project
and
I
believe
that
is
full
Cuts
question
right.
Do
we
do
we
Mark?
F
Yeah
sorry
I
completely
missed
that
I
thought
we
were
still
talking
about
CI,
so
yeah
for
Bergen
issue.
Triage
I,
don't
think
it's
fair
to
rely
on
the
CIT
to
triage
every
single
bug,
but
maybe
it
could
be
something
like
the
CI
team
is,
should
be
aware
of
bugs
that
have
been
triage
that
are
potentially
release
blocking
that
they
should
be
communicating
with
maintainers
and
keeping
track
of
the
release
blocking
bugs
I
think
there's
a
huge
distinction
between
all
bugs
and
release
blocking
bugs.
F
I
guess
one
follow-up
question
is
like
it
seems
like
I
think
comms
was
pretty
clear
as
a
scope,
CI,
maybe
a
bit
less,
because
we
kind
of
just
threw
a
bunch
of
things
in
there.
Do
people
feel
like
it's
too
much
like
it
should
be
split
into
multiple
roles
or
cooked,
better.
C
C
By
splitting
you
mean
having
back
trash
team
separate
and
citing
separate,
like,
for
example,
as
kubernetes
releasing.
That
is.
C
G
F
E
I
think
that
I
agree.
So
if
I
read
the
bug
issue
triage,
so
maybe
the
scope
was
not
clear.
So
let
I
suggest
that
in
this
iteration
we
try
to
make
the
scope
of
the
CI
team
cleaner
or
clear
and
maybe
in
a
follow-up
iteration.
So
in
the
release
theme
that
will
start
in
August
if
I'm
not
around,
we
are
the
separated
bug,
triage
team
that
is
responsible
for
all
the
issue
that
comes
in
not
from
CI.
A
C
Yeah
I
cannot
agree,
but
if,
if
there
would
be
a
bad
Chef
scheme
separately,
I
think
that
people
who
are
in
the
maybe
should
like
select
it
so
that
they
have
more
knowledge
about
the
KP.
Because
I
know
it's
not
always
straightforward
to
pack
chairs
every
issue,
and
sometimes
you
need
a
deeper
knowledge
about
the
whole
project,
so
yeah
it
might
be
challenging.
In
my
opinion,.
E
Yeah,
that's
fair
I
think
that
we
have
to
strive
for
a
balance
between
experienced
people
and
people,
starting
in
in
all
the
in
all.
The
in
all.
The
teams,
because
also
looking
at
for
flakes,
is
not
a
simple
exercise,
so
yeah
that
that
that's
I
think
an
overall
good
suggestion
to
to
try
to
balance
the
expertise
in
the
in
the
in
the
teams.
A
I
have
one
follow-up
question
so
for
this
new
issue:
clearance,
team
or
bhaktriage
teams,
the
team-
that's
responsible
about
realizing
issues
that
do
not
come
from
CI,
the
the.
A
E
I
think
that
that
is
is
up
to
Define.
Let
me
say
behind
personally
behind
the
release,
theme
and
release
process,
and
all
this
team
I
see
two
main
to
main
goal.
One
is
to
achieve
something.
The
second
one
is
to
increase
the
number
of
people
that
that
have
the
same
knowledge.
So
for
sure,
in
this
idea
of
issue
trash
team,
there
is
a
a
clear
area
to
what
they
could
share:
I'm,
not
sure
what
they
do
they
have
to
achieve.
We
have
to
probably
figure
it
out,
but
it
is
for
the
next
release.
E
A
Okay,
yeah,
but
one
thing
that
clearly
seems
to
be
something
that
we
need
to
do
is
Define
scope
for
the
CIT
right
right
now,
it's
kind
of
like
the
bucket
for
everything.
That's
clearly
not
a
comms
team
or
clearly
not
something
that
these
team
is
supposed
to
do
so.
Defining
the
scope
would
be
helpful,
at
least
for
the
next.
A
Okay,
let's
do
two
one
100.
We
were
able
to
hit
the
milestones
and
it
didn't
feel
like
we
was
clambling
right
at
the
end.
I,
don't
know
who
wrote
this.
D
That
was
me
I
know
we
had
some
some
hiccups,
but
I
I
felt
like
with
the
schedule
things
were
known,
teams
could
kind
of
get
into
place
on
their
own
autonomously,
and
so
it
wasn't
a
mad
dash
every
Tuesday
to
go.
Oh
shoot
today's
the
day
right
so
I
I
think
that
was
really
really
awesome.
D
A
Cecile
has
a
common,
the
goal
of
bakria
just
to
oh,
this
is
the
old
comment.
It's
the
same
way.
F
A
A
Okay,
let's
do
one
what
could
be
improved,
reviewing
the
tools
that
we
already
have,
so
that
we
don't
create
unnecessary
work
for
users.
Okay,
this
is
this
is
something
I
wrote
is
one
thing
I
observed
was
probably
at
the
beginning
or
in
the
early
days
or
early
weeks
of
of
the
release
cycle.
A
The
release
team
and
all
of
its
members
would
greatly
benefit
if
they
could
review
the
set
of
existing
tools
that
you
already
have
within
the
project
right
and
and
also
take
a
look
at
the
entire,
the
setup
of
how
our
test
Creator
setup.
What
tools
that
we
have,
what
tools
we
already
have
for
creating
releases
like
the
GitHub
actions
that
automatically
creates
draft
releases
and
so
on,
because
one
thing
I
observed
is
not
everyone.
A
That's
part
of
the
release
team
is
aware
of
what
cluster
API
has
at
the
moment
in
figuring
out
on
what
needs
to
be
done
to
what
needs
to
be
done
to
be
able
to
like
generate,
for
example,
release
notes.
A
Or
how
or
how
should
we
configure
our
test
grid
so
by
editing
raw
configs
at
certain
locations,
and
so
on
so
doing
this
overall
review
at
the
beginning
of
the
release
cycle
would
be
helpful.
Yes,
what
I
did.
E
A
E
E
A
Most
of
what
should
have
been
reviewed
or
would
have
been
reviewed,
is
in
the
documentation
is,
is
in
the
released
inbox.
So
probably
the
thing.
E
I
think
that
needs
to
mute
himself.
That's
good.
A
Got
it
okay,
yeah,
so
reviewing
the
talk
would
probably
in
be
the
good
starting
point
so
that
everyone
in
the
team
is
just
aware
of
the
set
of
tools
available.
The
configurations
available
and
everything.
A
A
E
A
A
Active
rotation
among
team
members-
okay,
this
is
something
I
wrote
is
with
the
the
release
team.
The
idea
was
to
basically
spread
the
knowledge
across
a
lot
of
people
and
not
just
limit
it
to
a
few
and
one
of
the
things
that
would
have
helped
probably
a
little
more
within
this
was
within
the
release
team
members,
since
we
have
a
lot
of
Shadows
and
the
leads,
if
you
could
rotate
some
of
the
responsibilities
during,
let's
say
some
of
the
patch
and
leases
that
we
have
every
month
right,
so
that
would
have
helped.
A
But
unfortunately,
that
didn't
happen
to
the
extent
I
would
have
like
to
see
in
the
past
cities.
It
ended
up
being
the
same
subset
of
people
from
each
of
the
teams
working
on
every
release,
every
patch
released
so
for
the
next
recycle.
C
E
Yes,
I
I
I
think
that,
let
me
say
it
happens
that
a
person
could
meet
to
the
release
team
and
then,
for
any
reason,
it
cannot
still
fulfill
the
commitment.
I
think
that
we
should
simply
oh,
there
is
an
open
sport
in
the
in
the
com
team
who
want
to
step
in
and
even
and
let
volunteer
to
Japanese
in
the
middle.
If
someone
else
cannot,
but
let's
try
I
think
that
we
should
try
yeah.
A
Yeah
Joe
I
think
you
already
ran
first.
D
Yeah,
so
I
I
really
liked
the
idea
of
responsibility
rotation.
Do
you
have
like
a
takeaway
or
an
action
item
on
like
how
to
best
do
that,
like?
What's
your
thought
on
that.
A
For
one
thing,
I
would
say
is
set
up
this
expectation
early
in
the
release
cycle
itself,
so
that
everyone
knows
that
yeah
at
some
point,
I
will
want
to
try
it
out
and
they
start
considering
it.
One
thing
is:
maybe
some
of
the
Shadows
when
they
join
the
team,
their
expectation
might
be
to
just
okay,
I'll
I'll,
just
observe
what's
happening.
That
is
my
role
in
this
team.
A
C
Yeah
I
just
wanted
to
follow
up
on
purpose
comment
about
shallows
like
maybe
we
should
have
a
clear
documentation
about
off-boarding
in
in
cases
where,
let's
say
lead
or
adults
cannot
really
continue
so
that,
but
the
challenges
that
I
see
is
here
is
let's
say
if
lead
observes
that
one
of
the
Shadows
or
like
two
are
not
that
active,
that
they
are
not
coming
forward
and
saying
like
hey.
I
cannot
really
continue,
maybe
whose
responsibility
it
would
it
be
like.
E
Yeah
so
I
I
will
before
I
will
try
to
answer
to
the
rotation.
I
think
that
one
thing
that
we
can
do
that
every
team
can
do
at
the
beginning
they
can
Define
all
the
first
page.
I
will
do
as
a
release
lead
and
this
person
will
follow.
The
second
page
will
be
done
by
this.
The
person
that
follow
it,
and
so
you
you
shall
you
should
I
I.
E
Don't
think
that
we
should,
let
me
say,
art
Define
this
stuff
down,
but
it
should
fall
on
the
release
leads
comes
lead,
CI
leads
to
ensure
that
everyone
gets
into
rotation
answering
to
for
cut
question.
Let
me
say:
I
I,
always
assume
that
we
are
between
professional
and
people
with
a
certain
degree
of
maturity,
and-
and
there
is
no
shame
if
so,
there
is
no
shame
in
going
to
ask
to
a
person
a.
E
Why
are
not
sure
showing
up
can
I
help
you
etc,
etc,
like
there
is
no
shame
in
for
a
person
telling
I'm
sorry
I
got
on
a
unexpected
task
from
my
employee
and
I
have
to
give
priority
to
it
is
or
I
have
personal
problem
or
whatever
so
I
think
that,
of
course,
let
me
say,
code
of
conduit
drives
the
relation
between
people,
but
doing
the
fair
question
is:
is
not
bad
and
giving
ferration
is
not
bad,
so
if
then,
it
is
necessary
to
escalate.
E
A
D
Oscar
spent
a
lot
of
time
making
sure
everybody
felt
comfortable,
doing
different
jobs
and
setting
those
expectations.
So
the
the
weekly
release
was
handed
off
to
to
multiple
different
people
to
allow
them
to
do
it,
since
that
was
a
smaller
scope
of
work,
as
opposed
to
the
large
release
notes,
some
people
didn't
feel
comfortable
doing
that.
So
there
was
a
lot
of
internal
team
communication
happening
through.
D
We
can't
do
private
groups,
but
we
kind
of
like
a
group
DM
is
what
we
used
in
the
comms
team
and
that's
what
we'll
be
using
in
the
new
release.
Release
leads
team,
and
so
that
way
we
can
have
that
open,
open
form
of
communication
back
and
forth,
and
if
we
notice
somebody
disappearing,
which
we
probably
should
have
done
in
the
comms
team,
we
noticed
that
two
people
dropped
off.
We
should
you
know
we
should
have
escalated
and
said.
Okay,
do
we
need
more
people
I
think
we
felt
internally?
D
We
had
it
under
control
for
the
comms
team,
so
that's
kind
of
why
we
didn't
bring
it
up,
but
I
think
there's
probably
enough
enough
people
that
want
to
join.
That.
Would
you
know
if
we
would
have
put
a
call
into
action
to
say
who
wants
to
to
help
kind
of
join
and
be
on
the
comps
team
we
could
have
brought
in
one
or
two
more
people,
so
I,
really
like
that
idea
of
trying
to
ask
to
backfill
when
people
have
to
step
out,
because
those
those
things
do
happen.
G
I
think,
adding
to
the
point
with
Joe
said
and
also
connecting
to
the
point
setup
guidelines
for
off-boarding.
Do
you
think
it?
It
would
be
beneficial
if,
somewhere
in
between
the
release
cycle,
we
reach
out
in
the
community
asking
if
anyone's
interested
to
be
part
of
any
of
the
teams
within
the
release
team.
A
Yeah
that
that
I
would
say
basically
depends
on
if
you
have,
if
the
team
has
of
no
shows
and
if
you
need
to
backfill
so
that
it
doesn't,
the
all
of
the
work
doesn't
fall
on
like
one
or
two
people
within
that
team.
So
I
don't
know
if
we
want
to
set
up
clear
timelines
on
okay,
we'll
do
this
announcement
at
this
during
this
week
in
the
daily
cycle.
I
think
it's
mostly
going
to
be
just
Case
by
case
basis.
F
Yeah
I
think
we
just
want
to
plus
one
what
true
and
fabric
said.
I
think
our
boarding
is
probably
something
we
most
like
I
think
we
should
have
a
defined
checkpoint
a
few,
maybe
a
few
weeks
after
the
release
team
starts
where
it's
not
even
like
an
opt-in,
it's
just
by
default.
We
check
with
every
release
team
member
like
hey.
F
Do
you
still
want
to
be
on
the
release
team
because
things
might
have
changed
and
for
people
who
haven't
been
showing
up
until
then
we
and
if
they
don't
answer,
then
they
can
just
be
removed.
I
think
we
should
take
the
action
of
like
confirming
people
on
the
dock
and
then,
if
they're
still
active
keeping
them
if
they're
not
active
anymore,
removing
them,
because
you
don't
want
to
be
in
a
situation
of
like
unsaid
awkwardness,
where
people
are
not
showing
up
but
they're,
still
part
of
the
tag
and
they're
getting
tagged
every
single
time.
D
A
I,
don't
see
any
hints:
okay
go
going
on
to
the
next
one.
He
don't
have
a
lot
of
time
trying
to
determine
the
release.
Notes.
Prefix
took
a
lot
of
comp
Steve
that
I
know.
Joe
wrote
this.
D
Okay,
I'm
just
gonna,
keep
beating
this
dead
horse,
no
I
think
we're
making
great
progress.
I
think
we
have
a
lot
of
the
areas
defined.
I.
Think
Killian
put
a
note
on
the
the
issue
to
hey.
Let's
move
forward
with
this,
so
we've
deleted
a
lot
of
areas
we'll
move
that
forward.
D
A
Sounds
good,
okay,
I,
don't
know
who
wrote
this
but
yeah,
maybe
the
CIA
team
and
the
cons
teams
could
sink
a
bit
more
so
that
both
are
aware
of
the
activities
within
the
team.
C
Trust
me
I
felt
like
we
could,
as
a
team
or
like
maybe
just
lead,
I'm,
not
sure,
think
more
and
you
know
just
see
what
are
the
activities
they
are
doing
within
the
team
and
get
to
know
about
it.
Okay,.
C
I
think
it
was,
it
was
enough,
but
some
other
I
don't
know
questions
would
arise.
So
I
thought
maybe
it's
it's
better,
but
yeah
you're
right.
We
could.
Team
meetings
are
also
good
to
to
discuss
those.
F
F
I.
Think
it's
player,
like
people
probably
feel
more
comfortable,
like
you
know,
asking
questions
going
back
and
forth
being
vulnerable
rather
than
like
having
to
do
this
all
in
public,
where
everyone
can
see
so
I
think
a
balance
has
to
be
found,
but
at
the
same
time,
because
you
know
really
seems
to
have
visibility
on
one
another,
it
probably
didn't
help.
What
forget
was
feeling
about
not
knowing
what
was
going
on
yeah.
D
Yeah
so
I
think
Cecile
to
your
point
of
the
private
channels.
Oscar
did
go
and
request
a
private
channel,
but
was
denied
I
forget
the
exact
reason
for
the
denial,
but
that
that
was
the
exact
reason
that
that
was
requested.
Was
people
felt
safe
to
ask
the
silly
questions
I'm
quite
comfortable,
asking
really
dumb
questions.
That's
okay,
but
I
know
a
lot
of
people.
Don't
want
to
do
that
right.
So
that's
kind
of
why
we've
stuck
with
the
private,
DM
or
private
Channel
kind
of
situation,
so.
D
A
For
the
the
only
problem
with
having
the
dedicated
slack
channel
is
at
the
end
of
every
recycle,
we'll
have
to
like
remove
our
Dan
people
and
I,
don't
know
how
easy
or
how
hard
it
is
to
remove
people
from
a
slack
Channel.
It's
probably
just
easy
to
add
because
send
an
invite
they'll
be
able
to
add
themselves
yeah.
That's
the
only
thing
we'll
have
to
consider
I
think
the
takeaway
here
is.
A
F
Yeah
in
terms
of
coordinating
release
tests,
though
I
still
feel
like,
as
we
should
try
to
do
this
in
public,
because
there
is
a
lot
of
value
in
that
stuff
being
out
there,
even
if
you
think
for,
like
the
next
release
team
being
able
to
look
at
previous
threads
and
what
happened
and
why
something
was
done.
A
certain
way,
I
think
is
useful.
There
was
a
situation
very
similar
to
this
for
the
kubernetes
release
team.
F
Actually
like
a
few
years
ago,
I
don't
know
if
any
of
you
remember,
but
sigris
had
a
chat
and
it
they
also
had
a
channel,
and
it
turned
out
at
one
point
that
the
chat
had
become
kind
of
the
main
Central
Point
for
coordinating
all
release
activities
and
the
steering
committee,
actually,
you
know,
asked
them
to
stop
doing
that
and
move
the
activity
back
to
the
channel,
because
it
wasn't
open
and
inclusive
and
other
people
weren't
able
to
have
visibility
and
ask
questions
about
what
was
going
on.
F
But
having
a
chat
for,
like
you
know,
hey
you
know
at
the
doctors
they're
not
going
to
be
able
to
attend
the
meeting
or
like
more.
You
know
detailed
Logistics,
stuff,
I
think
is
fine,
but
for
posting
about
you
know
blocking
bugs
or
delaying
the
release
or
things
like
that
that
could
matter
to
others.
I
think
we
should
try
to
whether
that's
like
the
public,
happy,
Channel
or
separate
public
happy
channel
for
those
who
care
I
mean
having
it
in
public
is
a
really
good
thing.
Yeah.
A
Ugly,
definitely.
C
A
Okay,
moving
on
the
newer
release
would
be
cut
on
a
given
date,
but
never
sure
about
the
time.
D
And
this
is
me-
and
this
is
less
of
a
a
real
issue
and
more
of
just
like
a
hey
every
start
and
everything
it.
You
know:
2
p.m,
two
UTC
or
what,
like
you
know,
just
to
be
around
more
more.
E
D
Than
anything
right,
so
that's
that
was
kind
of
just
an
unknown.
A
D
B
Yeah,
just
on
that
I
mean
it's
a
practicality
thing,
but
it's
probably
going
to
be
like,
like
you
said,
to
UTC
for
UTC,
which
is
overlap
between
EU
us,
which
I
think
everybody
on
the
release
team
so
far
has
been
based
in
I.
Don't
think,
we've
had
a
situation
where
somebody
is
like
based
in
China
or
Pacific,
where,
like
the
time
zones
are
well
off,
but
then
the
other
issue
is
having
a
start
time.
I
think
is
a
really
good.
D
B
A
And
this
actually
goes
back
to.
We
need
maintainers
while
cutting
the
release
process,
because
the
maintainer
has
to
stay
around
till
the
entire
images
are
published,
just
to
be
able
to
hit
that
publish
release
button
okay,
which
is
not
ideal.
So
if
you
can
address
that,
that
would
be
great
okay.
Moving
on
okay,
I
think
we
already
discussed
this
on
how
to
manage
no
shows.
So,
let's
move
to
the
next
one
30
release
publicly,
so
everyone
is
aware
of
how
the
whole
release
process
works
from
beginning
to
the
end.
C
It
tells
me
I
know
we
we
discussed
about
this
and
then
that
was
postponed
for
some
some
reasons,
but
maybe
it
would
be
very
helpful
if
we
could
do
that
somehow
like
manage
that
even
we
could
rotate.
Maybe
if
there
are
some
volunteers
who
wants
to
do
that,
if
that's
okay,
of
course,
I'm
I'm
really
interested
at
least
so.
A
Yeah
yeah
I
I
agree
with
the
idea
behind
the
process
is
that
this
needs
to
be
more
public
and
having
rotation
will
probably
help
with
this.
But
the
I
I
couldn't
figure
out
a
good
way
to
record
this
or
make
this
public,
because
the
process
is
just
simply:
okay,
push
the
tags
and
then
wait
for
40
minutes
for
the
images
to
be
ready
and
then
push
run
three
commands
so
that
it
opens
up
PRS
and
then
wait
for
another
40
minutes
for
the
images
to
be
read.
A
So
there
wasn't
like
a
continuous
flow
that
we
could
record
and
show
okay.
This
is
how
we
cut
that
release.
So
maybe
involving
people
in
the
rotation
is
probably
a
better
idea
for
them
to
become
aware
of
how
the
release
is
cut
and
have
Hands-On
with
it.
C
A
F
Yeah,
we
actually
do
this
in
kab
Z
for
our
releases,
like
we
don't
have
a
relief
team
or
anything
like
that,
but
we
try
to
get
whenever
we
do
a
release.
One
of
the
maintainers
starts
a
zoom
meeting
in
the
slack
and
just
says:
hey
I'm
cutting
the
release.
If
anyone
wants
to
pair
and
then
anyone
is
welcome
to
just
join
and
watch
and
like
you
said,
I
mean
there
is
the
inconvenience
of
sometimes
you
just
have
to
wait
for
Stuff.
F
F
Even
if
it's
not
much-
and
there
isn't
much
to
do,
it's
a
good
option
to
opportunity
for
people
to
ask
questions
or
see
what's
happening
or
how
it's
done
and
demystify
it
and
I
think
it
also
kind
of
solves
the
situation
that
or
the
question
that
you
had
just
before.
There
wasn't
really
a
clear
time
at
which
we
would
start.
F
So
if
you're
gonna
do
like
some
sort
of
Zoom
meeting,
then
you
can
say
like
Hey
we're
gonna
meet
at
you,
know
nine
Pacific
and
kick
off
the
release
process
and
it's
kind
of
like
a
war
room
like
if
you
need
it,
you
use
it.
If
you
don't
need
it,
you
don't
need
to
use
it.
If
everything
goes
well,
you
just
stop
the
call
after
10
minutes,
but
if
something
goes
wrong,
then
at
least
you're
all
together
in
a
call-
and
you
can
coordinates
like
that.
E
Yeah
that
we
did
already
this
something
in
the
past
and
I.
This
is
where
I
learned
to
do
the
release
doing
this
session
with
veins
and
Andy
before
so
definitely
plus
one
and
even
in
in
my
experience,
even
even
if
there
are
time
that
we
have
just
wait.
E
A
Okay,
that's
all
of
the
points
and
also
we
are
over
time
thanks.
Everyone
for
joining
this
was
a
great
perspective,
a
bunch
of
action
items.
Thank
you.
Everyone,
and,
thanks
again,
for
the
successful
1.4
release
cycle,
see
you
all
around
bye.