►
From YouTube: Kubernetes SIG Release - 2019-04-09
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
I
think
people
stroll
in
as
as
required.
So
let's
kick
this
off.
This
is
the
April
9th
edition
of
the
cig
release
biweekly
meeting.
This
is
a
meeting
that
will
be
recorded
and
on
the
internet.
So
please
be
mindful
of
what
you
say:
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct,
we're
gonna,
let
Tim
pepper,
kick
it
off
with
a
with
some
notes
regarding
the
rpm
and
deb
package
management
support
policies,
so.
B
There's
a
link
in
the
minutes
there
to
message
I
sent
out
to
sig
cluster
lifecycle
and
sig
release.
Google
Groups
I
would
definitely
welcome
some
feedback
or
discussion
there,
but
the
the
gist
is
that
we
had
a
packaging
problem
and
it
was
around
how
we
declared
our
dependencies
in
the
packages
and
it's
as
best
we
understand
at
this
point.
B
It
appears
to
be
a
conflict
between
how
we
lay
out
the
packages
in
our
repositories,
so
we're
constantly
just
adding
or
appending
to
the
the
directories
in
which
we
publish
the
files
and
the
way
we
articulate
in
the
specific,
the
the
metadata
around
the
packages
that
we
require
a
certain
version
of
something
and
then
on
the
client
side,
both
how
apt
or
yum
consume
those.
So
there's
like
three
different
variables
in
play
and
it's
kind
of
a
surprising
bug.
B
We
can
change
some
things
in
our
spec
files
to
make
it
easier
for
people
to
upgrade,
but
this
in
the
bigger
picture.
It
raises
a
question
of
what
should
we
be
doing
and
there's
some
semi
competing
proposals
and
those
then
get
into
things
that
are
a
bigger
discussion
around?
What
should
we
support
so
the
the
main
place
this
came
up
was
for
people
who
are
wanting
to
run
old
versions
of
things
and
versions
that
we
know
to
be
bad.
So
that
raises
a
question
of
like.
Should
we
do
that?
D
A
Right
I
think
if
we've
got
competing
parties
at
this
point
that
yes,
eventually
a
cap
is
the
end
state
that
we
want.
But
if
there
are
competing
ideas
we
should
throw
up
a
dock.
You
should
throw
up
a
doc.
Let
people
battle
it
out
in
the
dock,
come
to
some
consensus,
come
to
some
loose
consensus
at
least
and
then
and
then
and
then
lick
work
together
to
make
the
cap.
B
B
B
I
guess
this
is
kind
of
simulated
in
a
way,
but
as
we
produce
things
that
are
out
there
for
people
to
consume,
one
of
the
sets
of
things
that
Segura
least
produces
is
our
Pat
release
branch
content.
So
after
one
14.0
gets
released,
one
dot,
14.1
comes
out
and
so
on
so
forth
from
there
today,
those
come
out
at
a
somewhat
arbitrary
cadence.
B
We
say
maybe
a
couple
weeks
after
the
dot
zero
release,
we
published
the
dot
one
release
and
then
after
dot
one
it
tends
to
elongate
to
three
to
four
weeks,
but
that's
sort
of
it.
It's
a
open-ended
schedule
and
perhaps,
if
there's
a
CVE
that
would
trigger
something
to
come
sooner
but
I'm
curious.
If
people
think
that
we
should
be
doing
something
a
little
more
reliable
or
predictable,
there.
D
A
Yeah
I
sort
of
agree
I,
you
know
I
think
we're.
You
know
we're
at
the
mercy
of
CBS
when
they
come
up.
You
know
and
that
and
that's
kind
of
a
separate
case
to
be
handled
by
the
the
product
security
committee,
as
well
as
the
patch
release
management
team.
You
know
from
the
perspective
of
figuring
out
when
to
do
patches.
I
think
you
know,
part
of
you
know.
Part
of
the
thing
that
we
run
into
is
having
the
notion
of
of
a
team
in
the
first
place
right,
you
know
classically.
This
has
been
the.
A
So
I
think
that
this
is
something
that's
coming,
I
think
if
we
can
come
to
some
loose
consensus
on
what
that
schedule
should
be
in
the
near
term.
That
would
be
valuable.
I
think
you
know
I,
think
saying
three
to
four
weeks.
Three
to
four
weeks
per
patch
release
is
fair.
If
there
are
contrary
opinions,
I'm
curious
about
them.
E
F
So
I've
been
kind
of
shadowing
the
party
B's
team
for
some
time
now
and
this
issue
this
discussion
I
think
I've
had
with
Tim
prepared
before
what
I
would
suggest
is
if
we
could
see
what
adopt
major
projects
do
in
terms
of
pottery
pieces.
I
am
I'm
quite
familiar
with
Microsoft's
idea
of
a
I.
Think
it's
much
used
hush
said
the
I,
don't
know
which
one
it
is
where
they
basically
release
all
patches
for
all
their
products.
F
And
so,
if
you
have
things
like
say,
for
example,
I
see
you
have
much
requests
for
cherry
picks
for,
say:
qubit
caters
Kate's
of
1.1
14,
113
112.
You
could
kind
of
like
bundle
them
all
together
and
release.
It
say
a
dot
say
a
frequency
of
which
we
could
choose,
but
that
kind
of
idea
would
make
it
easy
for
somebody
like
me
who
has
to
operate
the
Kuban
at
this
cluster
to
kind
of
put
a
shadow.
F
So
if
I
have
say,
for
example,
disparate
fastest
running
or
something
of
that
sort,
so
I
think
I'm
all
on
trellises,
I
kind
of
support,
the
frequent
release
model
and
also
it
because
of
specifically
the
shadow.
The
ability
to
shadow
and
plant
upgrades
and
updates,
of
course,
given
the
fact
that
if
there
is
a
security
patch,
it
will
be
given
precedence
or
something
of
that
sort.
But
yet,
basically
that's
why
I'm
trying
to
say.
B
Similar
kind
of
came
up
last
month
ahead
of
the
security
related
fixes
that
were
released
all
too
and
the
as
those
were
being
triaged
by
the
security
team
and
I,
see
this
as
being
a
pattern
going
forward
that
could
repeat
it's
not
everything
is
a
critical
CBE
in
critical
CBE.
Surely
is
gonna
lead
to
a
more
rapid
rollout,
but
there
might
be
a
variety
of
things
that
are
fairly
low,
criticality
and
then
the
the
security
team
specifically
asked
in
that
last
month.
Well,
when's
the
next
release.
A
Yeah
and
I
think
for
the
the
Microsoft
Patch
Tuesday
like
it
is,
it
is
a
combination
of
of
not
just
you
know,
security
checks,
but
it's
you
know.
It's
overarching
updates
that
are
software
right,
so
I
think
it's
been
a
while,
since
I've
been
in
a
Microsoft,
Centrex
has
had
mini-world,
but
that's
what
I
remember
them
to
be.
If
they
were
higher
criticality,
they
they
were
released
as
needed.
So
I.
You
know,
I,
think
that
we're
not
far
away
from
that
and
I
think
that
we,
you
know
the
the
way
we
release
right
now.
A
The
patches
is,
we
have
a
general
schedule
and
we
we
tend
to
land.
We
tend
to
land
patches
like
soon
after
for
for
multiple
versions
for
us
to
get
in
lockstep
with
multiple
versions.
We
do
need
to
expound
on
like
what
it
means
to
be
a
patch
release
management
team.
I.
Think,
like
you
know,
some
of
that
work
is
already
in
progress
with
with
Tim,
but
it
is.
A
C
I've
been
with
a
few
open
source
projects
that
have
gone
from
irregular
patch
releases,
to
schedule
to
regularly
scheduled
patch
releases,
and
it
has
never.
It
has
never
been
a
disadvantage
to
having
stuff
regularly
scheduled
I.
You
know
in
the
projects
that
have
done
this,
everybody
likes
it.
The
users
like
having
the
regularity,
the
people
who
are
volunteering
on
the
patch
team,
like
having
the
regularity,
the
only
thing
I
would
actually
question
for
this
is
whether
we
actually
want
to
do
it.
C
A
I
mean
I
think
that
I
think
that
you
know
there
are
some,
maybe
diminishing
returns
for
doing
it
at
a
longer
cadence.
Given
our
current
release,
cadence
right,
you
know
given
where
we're
releasing
quarterly
at
you
know,
if
we're
waiting
longer
than
a
month
to
cut
a
patch
release,
then
it
it
might
even
make
more
sense
to
figure
out
how
to
move
to
the
next
version
right.
If
our
cadence
changes
I,
think
I
think
that
we
should
assess
that,
but
it's
I-I-I-I-I
kind
of
deferred.
A
D
Think
there
should
also
be
some
kind
of
provision
for
patch
manager
to
be
able
to
release
something
out
of
cadence
so
that
it's
easier
to
you
know
release
something
like
last
time.
When
we
had
a
kubernetes
release,
we
had
a
go
bug
and
we
weren't
sure
when
the
go
next
release
is
gonna
be,
and
we
created
our
own
containers
and
we
weren't
sure
when
the
next
container
is
going
to
be
so
predictability
helps,
but
also
releasing
something
so
that
the
project's
that
depend
on
us
on
that
bug
will
also
get
some
reprieve
right.
D
Yeah
I
think
when
you
look
at
to
the
example
of
Co,
we
did
not
act,
there's
no
easy
place
where
it
you
can
go
and
see
when
the
network
you
know
go
is
released,
so
there
is
no
defined
policy,
but
there
is
an
you
know
pattern.
So
we
also
have
a
pattern
of
about
monthly
releases,
but
I
think
it's
good
to
have
out
to
find
policy.
That
says
we
will
release.
We
will
do
our
best
to
release
every
month
and
if
there
is
anything
urgent,
the
patch
release
team
has
the
Liberty
to
take
a
call.
B
The
other
thing
I
haven't
gone
and
crunched,
but
anecdotally.
A
good
portion
of
the
patches
across
the
three
supported
branches
are
effectively
the
same.
Their
chart
picks
off
the
same
change
in
master
and
we're
I
need
to
put
it
in
the
counts
of
patches
per
release,
but
I
feel
like
we're,
we're
all
fairly
consistently
one
to
two
dozen
patches.
So
if,
if
those
are
mostly
the
same,
then
doing
that
once
a
month
where
it
overlaps
across
the
three
there's
not
a
huge
burden
on
the
patch
release
team
to
coordinate
that
more
closely.
A
A
You,
yes,
no,
maybe
say.
Of
course,
there
will
be
like
a
mailing
list,
update
and
all
that
stuff
and
hold
for
comments,
but
I
think
overall,
it's
a
good.
It's
a
good
idea.
It's
something
that
we're
kind
of
doing
already
and
I
think
we
have
the
infrastructure
in
place
to
be
able
to
do
it
consistently.
So
we
should
just
say
that
we're
going
to
do
it
moving
forward.
Okay,
so.
G
Sorry
about
that
yeah,
so
I'm
driving
right
now
so
part
of
the
noise
but
I'm
looking
to
iron
out
the
dates
of
the
survey.
So
when
does
it
get
released?
When
do.
G
A
G
That's
kind
of
the
lazy
consensus
or
what
we've
done
in
the
past
and
there's
really
no
formal
structure.
I
think
on
the
114
survey
is
like
this
is
a
good
idea.
Let's
try
it
here's
a
worker
that
didn't
work,
and
now
my
goal
is
to
start
to
iron
out
some
policies
there
how
we
handle
this
moving
forward,
just
not
ambiguous.
It's.
You
know
a
little
bit
more
clear
in
that
direction.
There
yeah.
A
For
sure
so
I
you
know
so
the
idea
of,
and
thank
you
again
Josh
for
having
this
idea
and
putting
forth
the
the
initial
questions
for
the
survey.
So
we
released
the
survey
for
the
first
time
in
113
and
that
came
out
that
came
out
as
the
release
cycle
late,
like
after
the
release
cycle,
had
started
right.
So
that
was
the
first
problem
right.
You
know
the
the
people
who
were
selected
did
not
have
enough
time
to
to
one
review
all
the
applications,
quote-unquote
applications
or
questionnaires
and
and
reach
out
to
the
appropriate
people.
A
Also
I
think
that
we
had
a
I
I,
won't
call
it
an
issue.
I
think
you
know,
I
think
it
was
a
nicety
it
like
that
that
we
can
garner
that
kind
of
interest.
But
we
had
over
200
responses
to
the
1:13
survey
right
and
like
and
is
the
release
of
starting,
as
the
people
have
have
assumed
these
new
roles
and
are
learning
how
to
lead
in
that
role,
as
well
as
figuring
out
how
to
mentor
people
and
who
were
the
people.
A
They
should
be
mentoring,
I
I,
don't
necessarily
think
it's
fair
for
them
to
have
to
try
to
sift
through
200
applications
right.
So
you
know
we
were
having
some
chatter
on
the
slack,
Channel
and
I
think
that
it's
reasonable
for
us
to
expect
it's
reasonable
for
us
to
to
land
the
survey
at
the
same
time
that
we're
opening
up
a
lead
selection
for
the
the
the
previous
cycle
or
for
the
next
cycle.
Rather
right,
so
that's
right.
A
Around
I
mean
we
haven't,
pinned
it
down
to
any
specific
date,
but
it's
usually
right
around
code,
freeze
or
and
by
usually
I
mean
for,
like
maybe
the
last
three
cycles
or
so
we've
we've
we've
had
it
around
there.
So
for
anyone,
who's
not
familiar
prior
to
having
the
survey
within
the
114
113
cycles
is
essentially
I
would
create
a
github
issue
that
saying
like
hey
we're
assembling
the
team,
a
bunch
of
people
would
shout
at
that
issue.
I
would
I.
A
Would
you
know
collate
the
people
that
were
shouting
at
the
issue
and
and
group
them
into
the
appropriate
categories,
or
you
know
fine,
try
to
find
a
spot
for
them
that
you
know
that
essentially
means
it's
first-come,
first-serve,
as
opposed
to
the
best
person
for
the
job
right
and-
and
you
know
there
are
additional
factors
to
consider
around-
you
know:
availability.
You
know
time
zones,
the
skill
set
required
the
ability
for
the
lead
themselves
to
be
able
to
practically
mentor
the
amount
of
shadows
that
they
have
coming
into
that
role
right.
A
So
there
are
a
lot
of.
There
are
a
lot
of
quantifiable
--zz
that
are
not
necessarily
quantifiable,
depending
on
who
the
person
is
right,
so
I,
so
I
think
that
one
it's
reasonable
to
bring
this
survey
forth
during
the
lead
selection
process.
The
the
question
that
came
up
from
that
and
then
well
and
then
close
it.
Let's
say
two
weeks
after
the
leads
are
selected
right,
I
think
that's
a
reasonable
time
frame
that
gives
you
about
a
maybe
a
month
in
a
week
or
something
right.
A
C
A
Okay,
so
so
I
mean-
and
that's
that's
completely-
fine
I-
think
that
in
that
case
we
need
some.
If
we're
gonna
decide
that
the
role
it
doesn't
need
to
exist,
like
you
said,
we
can
do
that
later
in
the
cycle.
If
we
decide
that
is
true,
then
we
need
some
contingency
of
who
would
handle
the
surveys
right,
I
I.
This
is
something
that
I
explicitly
don't
want
on
the
release.
Team
lead
I,
think
that
you
know
they
have
more
than
enough
to
wrap
their
hands
around
and
they're
getting
ready
to
be
a
lead.
C
Well,
so
that's
I
guess
that's
argument
to
actually
have
the
position
just
to
kick-start
the
shadow
process,
because
we
don't
necessarily
have
shadows
selected
for
the
release,
lead
position
right
away
and
in
that
case,
I
would
say
that
this
position,
the
emeritus
advisor
position,
should
be
something
that
sig
release
picks.
If
you
follow
me
so
that
we
can
pick
it
even
when
we
may
still
be
discussing
who's
going
to
be
the
lead
next
cycle
right.
A
So
that
and
and
I
mean
I-
think
that's
kind
of
like
bleeds
into
something
that
we
did
with
the
owner
Styles
starting
starting
this
release,
or
it
merged
I.
Think
yesterday
or
the
day
before,
so
we
redefined
some
of
the
owner
files
and
actually
took
the
time
to
decide
what,
like
the
concept
of
a
sub-project
owner,
are
sub-project
owners
for
the
release
team
sub-project
right.
It's
not
just
a
team.
It
actually
is
a
sub
project
within
sig
release,
which
means
that
we
should
define
sub
project
owners.
A
I
think
that
if
the
facto
sub
project
owner
has
has
always
been
understood
to
be
the
release
team
lead
right
there.
The
person
who
ends
up
as
the
approver
for
all
of
the
directories
and
subdirectories
related
to
the
release
cycle,
they're
the
one
who
gets
added
to
all
of
the
relevant
groups
so
that
they
can
give
access
to
people
for
the
relevant
things
and
buttons
that
you
need
to
to
hit
or
turn
during
the
release
cycle.
But
you
know
that
said
be
kind
of.
A
We
were
talking
privately
about
putting
up
the
and
it's
it's
merged
now,
so
it
is.
It
is
law,
quote/unquote
law,
the
previous,
the
N,
minus
four
or
so
release
team
leads
to
seed
the
to
seed.
The
sub
project
owners
file
I
have
volunteered
myself
as
a
sub
project
owner
as
well
for
for
the
release
team
I,
it's
something
about
the
release.
Team
HR
has
always
been
near
and
dear
to
my
heart
for
the
last
few
cycles.
A
So
I
was
volunteered
to
do
that,
but
I
think
that
we
should
leave
that
as
a
responsibility
for
the
release
team
sub-project
donors
right
so
that
would
include
the
previous
release,
leads
for
n
minus
four,
so
right
now,
that
is,
that
is
Aaron,
Tim
and
Josh,
and
and
then,
as
as
they
rotate,
they
can
either
decide
to
stay
in
or
bump
out.
It's
it's
I
don't
want
this
to
necessarily
be
a
necessarily
need
to
be
a
rotation.
I.
Think
that
you
know
more
hands
make
the
work
like.
A
G
Yeah,
real
quick,
going
back
to
the
dates
you
mentioned
two
weeks
after
their
leaves
are
chosen.
Could
we
only
maybe
clarify
on
that?
You
know
just
in
case
lesia
chosen
takes
a
little
bit
longer
or
whatever,
like
you
know,
maybe
we
should
pin
it
against
their
release.
Dropping
I,
don't
know
just
throwing
it
out
there.
So
when.
B
G
A
I
would
like
to
think
that
choosing
the
leads
or
is
as
easy
and
should
be
obvious
by
the
end
of
the
cycle
or
close
to
the
end
of
the
cycle
by
code.
Freeze,
I,
think
everyone
in
their
respective
roles
has
a
decent
idea
of
the
shadows
that
are
contributing
actively
contributing
the
the
shadows
that
are
actively
interested
in
taking
on
the
role
and
and
can
and
and
then
it
you
know,
I
think
it's
really
on
them
to
make
make
the
decision.
A
What
has
happened
classically
and
the
last
few
cycles
is
that
we've,
you
know,
we've
essentially
sent
a
ping
to
the
leads
and
said
like
hey.
This
is
around
the
time
that
you
should
be
considering
who
your
successor
is
going
to
be.
You
know
we
want
to
do
selection
on
X
date
or
this
either
cig
release
or
burden
our
release,
team
burned
down,
meeting
right
and
and-
and
you
know
it
should
be
a
fast
follow.
A
G
So
yeah
and
I
don't
disagree
at
all
with
any
of
that.
It's
more
about
formalizing,
a
deadline
date
that
you
get
you
put
like
in
a
git
repository
versus
you
know
we
selected
Oliver
leaves,
and
now
we
have
this
two
week
runway
to
get
all
of
our
shadows
in
line.
You
know
just
trying
to
standardize
a
little
bit
more,
but
not
just
agreeing
it
easy.
Just
like
the
lead
more
or
less
trying
to
finalize
the
timeline
yeah.
A
C
C
A
B
I
threw
that
on
the
agenda
just
because
we
hadn't
quite
gotten
to
the
very
end
of
that
and
Claire
had
mentioned
it
on
Monday
and
the
release
team
meeting.
So
it
turns
out
she
is
traveling,
but
she
had
said
if
there
was
anybody
around
who
wanted
to
discuss
it,
and
there
was
time
in
the
meeting
that
she'd
definitely
take
feedback.
But
I'm
gonna
have
everybody.
A
C
H
C
Manager
does
how
much
time
it
takes,
or
anything
like
that,
and
so
I
decided
to
go
ahead
and
check
how
many
of
the
role
handbooks
that
was
true
of
and
it
actually
turns
out
if
you
take,
you
know,
sort
of
four
facts
as
being
essential
information
for
somebody
to
volunteer.
That
is
a
summary
of
what
it
does.
A
C
It
takes
the
sort
of
general
timeline
right.
Is
this
a
front-loaded
or
code
freeze,
loaded
role
and
any
requirements?
There
are
only
three
of
the
role
handbooks
have
all
four
of
those
pieces
of
information,
so
I
want
to
track
her
there
to
try
to
get
all
of
those
into
shape,
I'll
be
filing
issues
against
all
of
the
rest
of
the
role
handbooks
to
say:
let's,
please
add
this
additional
piece
of
information
so
that
people
can
sign
up
for
it.
That's
it
make
everybody
aware,
because
some
of
you
will
be
named
on
some
of
those
issues.
C
A
Happy
to
see
that
the
enhancements
one
has
all
the
things
yeah,
so
this
is
this
is
this
is
really
great.
I
think
that
in
general,
for
for
people
writing
role
handbooks,
please
be
aware
that
if
it's
something
that
is
it's
something
that's
generally
applicable
to
kubernetes,
it
probably
belongs
somewhere
else
and
linked
out
from
the
handbook
right,
if
you're
saying,
like
here's
a
process
for
doing
blah
right,
that
should
probably
be
somewhere
else
right.
A
If
it's
a
process
that
everyone
needs
to
know
about,
don't
don't
kind
of
hide
that
information
within
within
a
handbook
I
encourage
all
the
leads
to
work
on
updating
your
handbooks.
Joshua
will
be
bugging
you,
but
this
is
an
additional
additional
push
before
he
gets
started
with
that
stuff
in
general,
you
should
be
updating
your
handbooks
throughout
the
cycle
right
and-
and
you
should
also
feel
free
to
question
everything.
That's
in
the
handbook
right
this
is
you
know
this
is
not
just
law
right.
A
This
is
an
accumulation
of
knowledge
from
each
of
the
people
who
has
held
your
role
in
the
past
right.
So
it
is,
it
is
like
one.
It
is
one
your
opportunity
to
make
your
voice
heard
to
your
responsibility,
to
make
sure
that
that
is
up-to-date
before
the
person
who's
going
to
be
succeeding
in
your
role
and
there
there
wasn't
a
three,
but
you
know
I
think
those
are
important
enough.
Okay.
A
So
so
please
please,
please,
if
you
are
a
a
role,
lead
and
and
working
in
the
cycle
or,
if
you're,
a
shadow
who
has
been
following
some
of
the
process
in
in
the
handbooks,
and
it
doesn't
make
sense
to
you
right
feel
free
to
suggest
improvement
right.
This
is
like
this
is
our
project
right.
This
is
our
community,
like
we
were
all
responsible
to
each
other
to
make
this
better
right.
So
that's!
That's
all
my
my
warm
fuzzy
spiel
on
that.
A
So
I
think
there
are
a
few
and
the
ones
that
have
all
the
things
I'm,
not
gonna,
see
I
signal
I
think
is
probably
one
of
the
more
phenomenal
handbooks.
The
release
lead.
One
is
really
good
the
enhancements
one
I
wrote
most
of
so
I
hope
it's
okay
and
those
are
the
ones
that
also
have
the
check
marks
on
them
in
Josh's
tracking
issue,
so
I
take
those
as
exemplars
and
and
try
to
squeeze
yours
into
the
model
of
those.
A
G
Yeah
I
don't
know
the
temple
would
blanket
apply,
but
I
know
it
just
rattle
off.
Like
four
bullet
points
of
an
effective,
you
know
volunteer
list.
Some
of
those
key
points
might
not
be
a
bad
thing
just
to
outline,
but
yeah
I,
don't
know
if
you
could
template
eyes
like
you
know
doc
versus
yes
signal
or
you
know.
That's.
A
C
G
A
G
Make
a
comment
on
that
is
coding,
I,
one
of
the
shadows
for
1:14
myself,
we're
working
on
totally
revamp
the
entire
Doc's
handbook.
So
we
got
that
kind
of
first
draft
in
there
where
it's
at
least
you
know
2018
or
2019
updated,
but
now
we're
gonna
drive
it
home
and
make
it
perfect.
That's
what
I
was
asking
about
the
poster
child
too,
but
that's
pretty
funny
about
it.
Now
toes
the
prereqs
in
there
and.
A
I
think
one
of
the
problems
is,
we
never
really
said
that
they
were
prereqs
rated.
We
I
think
it
was
one
of
the
cycles
that
I
was
in
that
we
were
like
hey.
We
should
do
handbooks
for
this.
We
should
like
write
what
these
like,
what
these
rules
actually
do
and
it
again
it's
one
of
those
things
that
improves
over
time.
I
think
you
know
every
every
time
we
we
look
at
the
release
team
selection,
qualifications.
We
we
look
at
the
the
shadow
selection
quality.
We
look
at
the
handbooks,
we
look
at
anything.
A
That's
in
the
cig
release
repo,
it's
like
hey.
We
should
probably
change
this
or
we
could
improve
this
because
we
did
this
over
X
cycle
right.
So
it
you
know
it's
the
it's
a
constant
iteration,
so
it
it's
fine!
Now
you
know
it's
fine
now,
but
we
should
lay
down.
You
know
we
should
lay
down
a
set
of
requirements
for
it.
For
that.
A
Cool
well,
we
are
at
the
end
of
our
our
set
of
agenda
topics.
If
there
are
so
I
mean
I'm
going
to
one
give
it
time
for
open
mic,
but
also
ask
that
you
know
I
should
have
done
this
earlier,
want
to
start
getting
into
the
habit
of
doing
this.
Anyone
who
is
on
the
call
who
like
this
is
their
first
call
they're
just
coming
to
cig
release
they're
trying
to
figure
out
what's
going
on.
E
E
Hey
I
found
great,
my
name
is
abu
bakr
siddiq
mean
ideas.
You
can
call
me
night
I've
been
following
the
community's
release
team,
since
113
I
just
wanted
to
check
out
what
happens
in
the
Sigrid
these
meetings
and
how
it
differs
from
them.
But
are
these
team
meetings
on
Mondays
and
come
back
with
these
team
meetings.
A
Well,
welcome
I,
you
know
so
in
in
in
general,
our
you
know,
our
focus
is
on
sig
release
at
large
I
think
there
is
often
a
misconception
that
sig
release
is
the
release
team.
The
release
team
is
merely
merely
one
of
the
sub
projects
within
sig
release,
so
we
have.
Currently
we
have
the
release
team.
We
have
the
licensing
and
compliance
sub-project.
The
patch
so
kind
of
like
release
engineering,
which
includes
patch
release
management,
is
another
sub
project.
A
I
I
Also
I
had
this
aspie
networking
and
I
met
Maria
there,
and
she
said
that
if
you
want
to
start
somewhere,
you
gotta
go
into
the
Ghoulies
and
actually
started
and
I'm
trying
so
I've
been
leading
the
meeting
for
the
past
two
three
months
and
I'm
really
get
my
head
wrapped
around
all
these
things.
Think
of
it
crying
I
am
getting.
You
understand
some
of
the
things
now
and
still
looking
to
start
looking
for
a
place
where
I
could
start
doing
things
and
like
help
in
any
way
that
I
could
possibly
be
sorry
if
I
was.
J
A
Not
at
all
welcome
to
the
meetings.
Thank
you
for
thank
you
for
popping
by
yeah.
You
you've
met
some
great
folks
on
on
cig
release.
I
think
that
you
know,
whenever
I'm
doing
a
meet
the
contributors
or
speaking
in
general,
to
people
about
kubernetes
I,
think
that
you
know
joining
the
release,
team
or
hanging
out
and
cig
releases,
one
of
the
single
best
ways
to
get
involved
in
the
project.
Because,
honestly,
if
you're
on
the
release
team,
you
get
thrown
right
into
the
fire
and
like
that
was
my
experience
for
doing
it.
A
You
know
that
I
think
a
lot
of
people.
You
know
a
lot
of
co-workers
have
had
the
same
experience
they're
like
wow.
This
was
like
really
exciting
to
do.
It
was
a
lot
of
work.
I
wasn't
expecting
the
amount
of
work
that
it
was,
but
it's
it's
like
one
of
these
really
valuable
experiences
where
you
are
essentially
forced
to
interact
with
the
community
at
large
right.
D
A
And
and
like
force,
not
in
a
bad
way
like
you,
have
the
opportunity
to
to
interact
with
the
community
at
large.
I
will
say
that
you
know,
for
you
know,
josh
has
been
working
on.
You
know.
Josh
and
Jim
have
been
working
on
these
improvements
to
the
shadows.
Selection
survey,
we're
hoping
that
you
know
having
a
functional
process.
There
will
allow
people
to
more
easily
contribute
to
the
to
to
the
release
team,
but
definitely
for
definitely
for
seek
release.
A
Overall,
you
know,
as
we
start
to
spin
up,
you
know,
so
we're
working
on
continuing
to
solidify
the
processes
around
the
release
team,
starting
to
work
on
the
license
and
compliance
efforts
right,
so
this
is
being
able
to
scan
and
do
reporting
for
all
of
the
all
of
the
dependencies
that
exist
across
kubernetes
right.
So
that's
all
of
the
projects
and
all
of
the
multiple
kubernetes
works
that
exist
right.
A
I
A
You
know
the
enhancements
and
communications
role
bleed
into
cig
p.m.
right.
So
you
know,
if
you
have
interests
there,
you
can
end
up
on
that
side.
You
know
the
and
then
there's
a
variety
for
like
bug
triage,
you
know,
bug
triage
doesn't
necessarily
have
like
you
know
it
touches
a
little
bit
of
everything
right,
but
it
you
know
the
opportunity
of
being
in
the
really
esteem
means
that
you
you
get
to
reach
out
to
these
these
different
these
different
groups
and
and
get
a
better
idea
of
what
you're
actually
interested
in
right.
A
A
K
K
K
K
K
A
For
sure,
welcome
to
the
party
I
think
that
I
think
that
in
in
general,
understanding
the
the
dynamics
of
the
release
team
it'd
be
great.
If
you
occasionally
popped
into
a
again,
anyone
is
welcome
to
pop
into
any
of
these
community
meetings.
The
release
team
meeting
in
specific
will
give
you
a
an
on-the-ground
view
of
what
the
release
team
is
doing
day
to
day
or
week
to
week,
so
they
start
off
as
weekly
meetings
right
now,
they're
on
Monday,
if
I'm
correct,
right,
Josh
or
anyone
on
the
release
team.
A
Currently
on
Monday
as
the
cycle
as
we
kind
of
like
iterate
through
the
cycle,
there
is
like
a
burn
down
period
and
at
the
end,
at
the
point
where
we
have
the
burn
down
period
starts
the
meetings
start
accelerating
to
like
Monday,
Wednesday,
Friday
and
then
Monday
and
then
like
during
the
last
parts
of
the
cycle.
It's
like
Monday
through
Friday
right.
Everyone
needs
to
be
in
lockstep
on
what
they're
working
on.
A
We
try
to
do
an
EU
friendly
one
as
well,
so
we
have
a
US
time
zone
friendly
one
and
you
time
zone
friendly
ones
for
the
first
part
of
the
cycle
and
then,
as
burndown
starts
to
kick
in,
we'll
have
the
the
Monday
Wednesday
Fridays
so
popping
into
one
of
those
I
think
you
know,
based
on
the
stuff
that
you're
working
on
your
interests
may
lie
towards
the
release
engineering
sub
project
as
well
and
I.
Think
that
you
know
between
you,
myself
and
Tim.
We
can
talk
about
the
VMware
stuff
to
you,
plus
one.