►
From YouTube: Kubernetes SIG Release 20191202
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,
hello,
everyone.
This
is
December
2nd.
It
is
a
sig
release,
meeting
kubernetes
sig
release
meeting.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people.
A
So
we
don't
have
anything
on
the
agenda
today.
I
know
that
people
are
still
recovering
from
Cuba
and
some
people
are
flying
out
to
you
are
currently
at
reinvent
this
week.
So
we'll
probably
have
a
lighter
group
today.
If
there
are
people
who
are
interested
in
topic,
talking
about
specific
things
feel
free
to
shout
them
out.
If
not,
will
we
can
go
through?
We
can
sleep
through
some
of
the
sig
release,
board
or
sig
release
and
release
engineering
boards,
so
yeah
anybody.
B
B
A
A
Well.
How
do
we
actually
do
intend
testing
for
some
of
the
release
tools
right
where
they
have
the
requirement
to
need
actual
repos
to
do
their
thing?
Okay,
make
sense,
so
I
think
it's
I,
think
it's
a
possibility.
I
think
it's
something
that
we
would
II.
Would
he?
What
do
you
think
Tim?
We
could.
We
could
probably
spin
up
a
repo
to
do
that.
D
C
A
All
right,
so,
let's
yeah,
let's,
let's
go
about
doing
that
for
moving
into
the
next
cycle.
It
do
I
have
a
note-taker
by
any
chance.
Does
anyone
want
the
illustrious
the
illustrious
honor
of
doing
notes
for
this
meeting?
I
can
get
okay
awesome.
Thank
you,
Dan,
all
right.
So
great
idea.
Let's
Dan,
add
that
as
an
action
item
and
the
second
part
of
it
is
what
to
choose
for
testing
I.
Personally,
don't
have
opinions,
I,
I,
really,
don't
I
think
we
should.
A
We
should
choose
a
framework
that
is
I'm
not
rather
I'm,
not
super
opinionated
about
it.
What
I
mentioned
in
the
issue
is
that
I
think
that
we
should
like
one
increase
test
coverage
is
good.
We
should
strive
towards
it,
however,
we're
doing
it
to
that.
We
should
try
to
be
consistent
across
the
repos
and
the
orgs
that
we're
touching.
So
if
we're
using,
if
we're
using
ginko
and
go
mega
in
several
places,
we
can
also
glean
patterns
right
from
from
multiple
repos.
A
So
if
that
makes
sense,
we
should
do
that
and
then
finally,
there
was
a
talk
about
like
table-driven
tests
versus
what
was
kind
of
already
here.
I
think
there
were
some
assertions
floating
around
and
this
I
I
usually
lean
towards
the.
What
would
Dave
Cheney
do
usually
when
I'm
looking
up
ghosts
ghosts
if
I
end
up
bumping
into
a
Dave
Chaney
article
Dave
likes
table-driven
tests,
I,
don't
have
opinions,
I
think
the
I
think
table
driven
tests.
A
E
Yeah
now
I
think
I
think
the
question
was:
if
we
use
testify,
can
we
use
table-driven
tests?
I
I
have
I,
haven't
seen
much
of
testify
yet,
but
I
think
that
doesn't
really
matter
like
it
does.
It
is
not
mutually
exclusive.
We
can
use
table-driven
tests
when
we
use
the
assertions
from
testify,
I
think
the
problem,
or
it
might
be
a
different
case
if
we
use
the
test
Suites
from
testify,
which
we
currently
don't
do
so
long-running
long
story
short
as
we.
E
The
way
we
are
set
up
right
now
with
testify
allows
us
to
do
table-driven
tests
and
also
I,
don't
have
any
strong
opinions
about
which
framework
we
would
use
I
think
we
should
check
if
we
have
enough
matches
or
assertions
we
care
about.
That's
that's,
basically
it
other
than
that
I.
Don't
care
about
any
of
the
frameworks.
A
E
Yeah
but
treated
more
like
in
it,
I
I
personally
prefer
black
box
testing.
Yes,
but
yeah
as
outlined
in
the
in
the
issue,
comment:
that's
my
personal
preference
still
like.
If
we
do
black
box
unit
tests,
we
probably
want
some
and
to
end
tests
or
something
we
might
even
want
some
additional
white
box
testing
so
treat
it
like
an
it
from
and
treat
it
like.
My
personal
preference,
I
if,
if
other
people
have
other
preferences,
yeah
fine
with
me.
B
A
A
B
A
E
A
Sure
so
I
think
I'm
really
loving
the
the
fact
that
we've
we've
we've
kind
of
done.
The
we've
kind
of
done,
like
the
overview
of
the
release
team
I,
think
you
know,
cig
release
is
most
popularly
known
for
the
release
team
and
the
work
that
we've
done
there
over
the
law
over
the
all
of
the
cycles.
Basically,
and
now
seeing
the
the
release
engineering
squad,
the
release
managers
group
sub-project
start
to
build
itself
out.
A
We've
we've
done
talks
at
you
know
at
san
diego,
at
barcelona,
around
the
release
engineering,
so
we've
kind
of
been
doing
the
the
sig
intro
as
a
intro
to
the
release
team
and
then
kind
of
the
deep
dive
as
an
intro
to
release
engineering,
and
I
think
that
that
has
gone
well.
It's
it
gives
people
enough
flavor
about
what
we
do
day
to
day.
A
I
think
that
now
that
we're
we're
getting
a
better
idea
of
what
we
need
to
do
in
release
engineering
and
have
actually
started
taking
steps
down
that
path,
I
think
that
tutorial
would
be
interesting
to
bring
in
more
contributors.
I
think
that
we
have
a
good
group
already,
it's
always
lovely,
to
see
more
faces,
especially
now
that
we're
seeing
more
work
I
think
we're
starting
to
carve
out
exactly
what
work
goes
where.
So,
what
would
we
want
to
do
for
the
tutorial
so.
C
C
F
A
Hold
on
before
we
continue
I
think
we
need
to
get
some
clarification
on
what
we
can
and
can't
do
for
the
maintainer
tract,
because
the
maintainer
tract
is
classically,
been
a
talk
max
to
people
and
either
an
intro
and
a
deep
dive
or
a
combined
90-minute
talk
with
max
two
people.
So
I
need
to
confirm
that
we
can
do
a
tutorial
and
have
up
to
four
people
for
this,
because
I
think
this
might
be.
D
Because
the
classic
form
is
usually
people
bring
some
laptops
and
they
work,
and
in
this
case
it
is
mostly
taped.
They
will
not
be
able
to
do
that
much.
It
is
mostly
dead.
We
are
going
to
show
okay.
This
is
how
it
looks
like
in
that
case,
the
typical
talk
given
90
minutes
will
work,
but
you
know
tutorial
form,
I,
guess,
from
the
recessionary
side,
getting
things
done
as
a
beginner
yeah.
A
You
know
what
I
was
just
thinking.
What
might
be
interesting
is
if
we
do
a
so
we've
done.
You
know,
we've
done
a
few
of
the
kind
of
release,
cuts
to
staging
and
release
process,
and
we
have
those
recorded.
It
could
be
cool
to
do
the
release
portion
of
that
on
stage,
because
that
is
what
is
it
20
minutes
or
so
we
can
go
through
the
process.
C
Are
sort
of
of
why
I'm
asking
who
the
intended
audience
is
because
which
direction
we
go
within?
This
would
also
start
to
point
out
a
particular
forum.
So
some
of
these
things
like
where
the
conversation
has
drifted
just
in
a
moment
to
me
that
starts
feeling
like
a
contribs
Ummat
topic
more
than
a
main
conference
deep
dive,
but
we
have
we
have,
though,
we've
got
at
least
four
things
as
a
possibility,
one
contribs
on
it
targeting
existing
contributors
and
there
I
mean
it's.
C
Certainly
one
of
the
more
frequently
asked
questions
we
have
these
issues
all
through
the
release
cycle
and
every
release,
like
is
this
even
sig
leads,
are
saying:
oh
wait:
how
do
I
get
my
stuff
into
the
release?
So
there's
there's
one
potential
set
of
audiences,
a
relatively
skilled
set,
but
on
contribs
Amit
focused
or
again
it
can
trip
summit
getting
more
contributors
to
contribute
to
the
process,
as
opposed
to
get
their
stuff
into
a
release
and
then
out
at
the
main
conference.
C
There's
the
standard
CFP,
where
let
like,
if
you're,
saying,
bring
the
release
process
to
the
people.
That
would
be
a
very
broad.
The
people,
including
non
contributors,
but
describing
how
stuff,
whether
it's
their
stuff
or
just
something
that
they're
interested
in
a
new
feature
or
something
comes
into
a
release.
How
things
are
made
or
the
deep
dive
could
be
a
place
where
we
we
do
it
in
the
maintainer
track,
but
our
are
trying
to
bring
new
people
into
the
process
to
contribute
towards
it.
So
there's
a
there's
a
lot
of
potential
different
audiences.
A
Form
so
it
sounds
like
we
need
to
chew
on
this
a
little
bit.
What
I
did
notice
is
we
didn't
really
have
we
should
we
should
do
something:
release
engineering-related
for
the
next,
for
the
Mexican
trip
summit
right
and
maybe
have
that
be
a
collaboration
between
release
engineering,
working
group,
working
group,
LTS
and
working
group,
Kate's
infra
beefing,
if
it's
just
a
let's
all
put
our
heads
together
on
the
next
iteration
of
whatever
weird.
C
C
Main
conference
cfb,
okay
contribs,
it
is
different,
maintainer,
Strack,
sig,
intro
and
deep
dive
is
different.
We
don't
have
to
have
those
three
things
decided
in
the
next
two
days.
If
we're
gonna
do
something
within
the
standard
CFP
to
the
full
conference.
We've
got
two
days
to
decide
that
content
and
that's
where
I'm
not
sure
about
the
tutorial.
But
if,
if
it's
a
tutorial
proposed
within
that
main
CFP,
we've
got
two
days.
C
Yeah
and
I.
Think
it's
good,
it's
good
as
a
sig
for
us
to
sort
of
have
a
vision
for
which
of
these
which
content
were
targeting
for
which
places
so
we're
not
so
self
conflicted
or
redundant
it
that
we're
maximizing
our
effort.
Because,
really,
realistically,
we
have
a
limited
number
of
people.
There's
a
lot
of
work
to
prepare
presentations,
especially
something
that's
like
a
90
minute
tutorial.
There's
a
lot
of
work
that
goes
into
that.
A
If
you
decide
to
go,
have
you
decided
to
go
main
conference
track
with
a
tutorial
that
if
you
have
multiple
submissions
and
this
one
gets
accepted
or
the
other
one
gets
accepted
it
it's
kind
of
not
a
great
position
to
be
in
it's
not
an
awful
position
to
be
in
because
you
get
to
talk,
but
it
it's
a
bad
position
to
be
in
if,
if
other
people
are
leaning
on
you,
two
to
work
together
on
a
talk
and
the
talk
gets
kicked
out
because
this
gets
accepted
or
the
other
way
around
right.
So.
F
A
So
here's
the
the
difference
right.
So
there
is
the
time
pressure
that
Tim
mentioned,
but
maintainer
track
talks
as
long
as
there
there
is
space
there
usually
accepted
right.
So
if
you
do
this
under
the
guise
of
sig
release
within
the
maintainer
track,
and
it's
something
that
we'll
go
we'll
go
to
Amsterdam
but
has
a
high
excuse
me,
I'm
recorded,
has
a
high
probability
of
being
accepted
for
the
maintainer
track
for
Amsterdam
right.
That
is
also
the
different
deadlines.
A
So
if
there's
something
that
you
want
to
so
I
think
part
of
what
Tim
is
saying
is
like
we
need
to
align
on.
Are
we
doing
this
in
multiple
places?
Are
we
doing
this?
So
we
did
a
release.
Engineering
talk
as
well
as
so
we
did
to
release
engineering
talks
right,
one
around
building
the
cloud
native
kernel
and
what's
the
kind
of
the
evolution
of
release
engineering
across
the
time
that
essentially
Tim,
Hawken
and
and
Matt
Michael
Rubin
did
their
talk
about
the
cloud
native
distro
and
where
we've
evolved
since
then
as
community.
A
So
if
there
are
people
interested-
and
it
sounds
like
there
are
people
interested
in
doing
the
release,
engineering,
deep
dive
or
a
cig
release
talk
on
the
maintainer
track,
and
that
is
available
to
you.
We
just
need
to
tighten
up
what
we
want
to
do
if
you're
saying
that
you
also
want
to
submit
a
main
track
talk,
that's
a
different
story.
Right
and
I.
C
So
I
fully
support
this
as
a
deep
dive
for
the
sig
@q
con
I
do
worry
that
the
the
amount
of
content
there
would
be
a
challenge
to
do
in
a
deep
dive
like
the
90
minutes
might
be
or
closer
to
an
hour
might
be
more
appropriate
and
then
there,
because
the
audience
is
perhaps
contributors
like
we.
It's
unfortunate
that
we
split
that
day.
Zero
can
trim
some
it
stuff
is
going
to
be
existing
contributors.
C
We're
like
the
new
contributors
are
there
but
they're
off
in
a
separate
workshop,
where
the
main
conference
has
just
anybody
and
everybody.
So
if
the,
if
the
intended
audiences
new
people
to
who
could
come
and
contribute
to
this
process
and
be
interested
in
the
tooling,
they
say
you
demonstrate
that
would
be
better
in
the
main
conference
as
a
deep
dive.
But
then
you
get
the
time
constraint.
C
A
A
If
we
do
a
deeper
session
during
the
contributor
summit
right
for
for
existing
contributors,
the
while
existing
contributors
are
not
new
contributors,
they
may
be
new
contributors
to
us
right
and
what
we've
noticed
over
the
last
few
cycles
in
building
out
the
release
managers
group
is
that
it
has
been
pretty
useful
to
have
someone
that
was
already
familiar
with
sig
release
and
and
our
processes
to
get
bootstrapped.
So
a
lot
of
the
people
who
are
release
manager
associates
right
now
are
also
former
release.
Team
members
right.
F
A
So
so,
let's
so
let's
hold
this
and
it
sounds
like
we're
not
doing
a
main
track,
but
we'll
do
a
maintainer
track.
So
let's
hold
this.
The
people
who
are
interested
I
suggest
you
all
get
together,
tighten
up
a
proposal
that
Tim
myself
and
Caleb
can
review,
and,
and
we
can,
we
can
kick
some
ideas
around
sound
good,
yep
cool.
A
B
A
A
A
C
So
two
things:
we've
we've
just
kind
of
started
this
and
we
in
the
first
go-around
from
like
a
release
manager,
branch
manager,
perspective.
We
brought
in
a
whole
bunch
of
associates
and
we've
had
a
little
bit
of
uptake,
but
compared
to
like
as
a
percentage
of
the
people
who
initially
volunteered
I'm
I
I
don't
want
to
be
negative,
but
realistically
we
had
a
very
low
percentage
of
engagement
and
promotion
to
the
next
level,
but
it's
also
early
days.
C
We've
only
been
doing
this
a
few
months
really
at
this
point,
so
I
want
to
see
that
be
more
clearly
successful
that
we're
actually
we're
getting
more
people
engaged,
we're
actually
succeeding
and
promoting
people
up
to
higher
levels
of
activity
and
towards
reviewers
and
approvers
and
more
ownership
and
I
do
think
that
that
takes
a
like
a
fair
amount
of
time.
It's
not
gonna
just
happen
in
a
couple
of
months,
so
I
would
like
to
see
a
little
more
continuity.
There.
C
C
A
Those
were
those
were
the
three
so
to
answer
each
of
them,
so
one
is
a
so
so.
The
sig
release
chairs
also
happened
to
be
release
engineering
sub
project
owners
right,
which
means
we
own
the
the
processes
and
repos,
and
all
that
good
stuff
and
access
for
all
of
the
release.
Engineering
tools,
as
well
as
the
groups
therein.
So
that
includes
the
release
managers
group.
A
So
as
a
sub
project
owner
for
release,
engineering,
I,
don't
plan
on
going
anywhere
right
and
I
think
that
as
some
project
owners,
it
is
our
responsibility
to
make
sure
that
there
is
continuity
throughout
each
of
these
steps,
built,
helped
build
out
this
ladder
and
and
improve
the
processes
right.
So
we
just
merged
a
and
improvement
to
the
branch
manager
handbook
which,
which
a
few
of
you
have
reviewed,
I'm,
going
back
with
a
few
more
sweeps
of
that
stuff.
A
So
I
think
that,
on
the
from
the
sub
project
owner
aspect,
nothing
is
changing.
I
will
still
be
there
to
provide
that
kind
of
oversight
from
a
I,
I
would
say:
I
was
going
to
write
an
email
reply
to
Tim
and
it
was
like
Thanksgiving
weekend
and
all
that
good
stuff
and
I
was
like.
You
know
what
we'll
just
we'll
just
chat
this
out
on
Monday,
so
I
think
that
part
of
it
is.
We
need
to
try
to
separate
the
people,
because
this
comes
up
fairly
frequently
with
regards
to
our
access
Tim,
myself
Caleb.
A
The
sake
chair
should
not
necessarily
be
delegated
access
to
those
things
right,
so
we
we
hold
that
access
as
technical,
it's
like
Zig
release
doesn't
have
technical
leads,
but
we're
essentially
holding
that
access
as
technically
it's
or
knows
owners
of
the
release.
Engineering
sub-project
right
so
I
think
that
you
know
this.
This
comes
up
with
regards
like
github
the
github
administration
team,
when
they
asked
us
about
like
oh
well
you're
taking
over
this
thing,
but
like
should
sig
chairs.
A
Have
that
like
not
necessarily
but
release
like
sub
project
owner
should-
and
we
just
happen
to
be
both
of
those
things
right
so
so
here
I
think
it's
important
to
to
delineate
between
the
roles
that
people
may
hold
right.
So,
in
my
instance,
I
happen
to
be
released.
Sub-Project
release,
engineering
sub
project
owner,
but
also
a
sig
chair,
also
a
patch
also
a
branch
manager
right.
So
what
I
was
going
to
pose
to
you?
A
Tim
was,
as
a
branch
manager
have
I,
been
doing
a
good
job
right,
because
I
think
that
that
is
part
of
the
that
is
part
of
the
consideration
for
promotion
into
patch
release
team
right.
It
should
not
be
a
as
a
sub
project
owner.
It
is
my
responsibility
to
ensure
continuity
across
the
entire
team
right
and
ensure
improvement
across
the
entire
team,
but
separately
as
a
branch
manager
have
I
been
doing
the
job.
That
would
would
be
records.
That
of
me
being
promoted
into
patch
release.
C
Well,
I
would
also
say
it's
may
be
a
demotion
because
it's
like
it's
a
small
bit
of
grunt
work
off
on
the
side,
but
if
you
view
it
as
a
promotion
activity
where
patch
release
is
the
ultimate
place
to
be
I,
I
feel
like
that's
just
that.
That's
not
what
it
actually
is,
but
that
aside
I
I
think
the
what
I
would
be
looking
at
is
again
how
many
of
the
people
coming
in.
Are
we
activating?
So
if
sasha
is
being
promoted
up
to
branch
managers
he
prepared
to
take
over
for
you?
A
So
what
we've
done
essentially
between
I'll
give
you
time
to
answer
to
so
we
what
we've,
what
I've
tried
to
do
across
the
last
few
cycles
is
one
kind
of
look
at
the
process.
Myself.
I
think
that
a
lot
of
the
we
have
some
parallels
between
this
and
the
release
team
right,
where
you're
trying
to
learn
the
thing
while
doing
the
thing
while
teaching
the
thing
to
someone
else
right
are
teaching
it
to
multiple
people.
A
A
Cool
cool
so
again-
and
this
is
this-
is
a
thing
where
I
I
don't
disappear,
right,
I'm
still
going
to
be
the
the
the
reason
that
I
have
kind
of
been
interested
in
this
ladder
that
we've
created
over
the
last
few
cycles.
It's
essentially
prior
to
this
I
had
not
worked
on
any
of
the
release
engineering
aspects
of
it
right.
So
we
had
two
sig
chairs
who
have
like
actually
cut
cut
a
kubernetes
release
and
I.
Wasn't
one
of
them
and
I
was
okay.
A
Hold
on
I
need
to
really
understand
this
end
to
end,
if
I'm
going
to
be
useful
in
improving
some
of
this,
so
the
final
step
for
me
is
as
patch
release
team.
That's
the
one
thing
I
have
not
touched
so
I
want
to
look
through
the
docs.
I
want
to
be
one
of
the
people
doing
the
stuff
and
improving
it
while
I'm
doing
this
stuff,
and
also
there
is
so
from
the
patch
release
team
aspect.
I
think
everyone
is
going
to
be
fine
there.
A
There
are
times
where,
like
Tim
and
I
may
like
diem,
and
you
know
there
are
times
where
we're
talking
about
stuff
we're
like.
Should
we
explicitly
not
do
this
thing
so
that
we
can
see
someone
step
into
it?
See
someone
pick
up
that
responsibility
and
by
moving
out
of
branch
management,
I,
think
that
we'll
have
there
will
be
more
of
an
opportunity
for
people
to
step
into
the
things
that
I
do
clandestinely,
sometimes
so.
A
A
B
A
Yeah
so
the
first
round-
and
this
kind
of
lends
itself
to
what
Tim
was
talking
about
earlier
about
the
maybe
a
lack
of
participation,
I-
think
that
the
first
round
what
we
essentially
did
was
we
brought
in
a
lot
of
the
we
brought
in
a
lot
of
the
people
who
had
applied
as
branch
manager
shadows
for
the
previous
release
cycles.
I
guess,
116
and
brought
them
in
as
the
initial
group
and
we
brought
in
14
13
14.
So,
if
know
something
like
that,
maybe
yeah
it
was
a
lot.
A
It
was
a
lot
and
yeah
and
I
think
that
you
did
initially.
We
didn't
know
what
we
wanted
to
turn
this
into.
We
have
a
little
bit
of
a
better
idea
now,
but
not
maybe
not
a
clear-cut
path,
and
because
we
didn't
really
have
that
clear-cut
path.
I
found
that
it
might
be
necessary
to
bring
some
people
in
that
are
used
to
doing.
This
have
done
this
before
kind
of
carving
this
path
out
on
the
release
team.
A
So
the
second
batch
of
people
that
we
pulled
in
so
Taylor
is
in
that
batch
Sasha
or
you
part
of
that
batch
mark
Oh.
Kenny
are
all
former
release
team
members
right,
so
it's
there's
kind
of
there's
kind
of
a
want
to
pull
in
people
who
are
used
to
being
unfamiliar
with
something
and
maybe
banging
their
head
on
it
a
little
bit
until
it
works,
reporting
back
status
and
but
kind
of
being
self
motivated
to
get
this
stuff
done.
I
think
that
we
didn't
necessarily
get
that
out
of
the
first
batch
of
people.
A
I
think
that
it's
a
stronger
group
now
but
they're
all
so.
A
lot
of
people
in
the
group
still
and
I
would
like
to
see.
I
would
like
to
see
I
want
to
say
three
or
four
branch
managers,
a
solid
set
of
three
or
four
branch
managers
available
and
trained
before
we
consider
opening
the
group
again
right.
So
all
of
that
to
say
that
there
we're
currently
not
accepting
applications
for
for
a
new
release,
manager,
Associates
I,
think
that
we
should
do
it
by
selection
did
by
a
selection
of
individuals
who
have
been.
A
Because
some
of
the
stuff
we
haven't
even
discovered
yet
we're
getting
a
better
idea
of
the
things
that
need
to
be
fixed
and
we're
starting
to
weave
multiple
plans
together
of
how
to
fix
those
things
as
you've
seen
across
the
last
few
cycles.
But
there
is
still
going
to
be
some
unknown
territory
and
the
people
who
get
involved
in
this
have
to
be
okay
with
not
having
a
clear-cut
plan
and
and
how
to
get
the
thing
to
completion.
G
To
add
to
that,
I
think
that
it
has
been
nice
I
did
definitely
this
release
I
absolutely
felt
that,
and
it's
trying
to
get
my
footing
about
me,
try
to
kind
of
understand.
What's
going
on,
watching
PRS
I
really
appreciated
the
deep
dives
in
these
meetings
that
we've
had
brief.
You
know
you
Tim
Pandit,
what's
going
to
go
through
and
and
Sasha
as
well
in
terms
of
kind
of
pulling
apart,
how
these
things
actually
work,
and
so
I'd
say
it
might.
A
Right
so
we're
doing
something
right.
Everyone
I
think
we're
doing
something.
Okay,
so
I
have
say,
said:
we're
gonna,
leave
that
PR
open
to
play,
see
consensus
until
tomorrow,
I
think
we
can
still
do
that
and
then
I'm
going
to
move
forward
with
the
owners,
file,
changes
and
and
the
kubernetes
org
github
team
changes
they're
fairly
minimal
changes,
most
of
them
are
drops
a
few
of
them
are
so
I
think
the
only
real
change
outside
of
comments
is
granting
sacha
access
to
the
release
managers
group
on
github,
that's
I,
think
that's
the
big
change.
A
C
Yeah
I
think
the
the
key
here
is
that
we're
we're
looking
for
a
long-term
commitment.
This
isn't
just
bouncing
through
a
promotion
track.
Our
end
goal
is
to
get
skills
growing
contributions
growing
in
a
sustained
way,
so
that
we
have
people
who,
who
really
can
own
things
for
quite
a
period
of
time
and
and
that
we
can
get
into
more
of
a
stable
state
delivery
place.
A
A
We
have
these
great
contributors
that
that
come
around
and
we
have
them
for
a
quarter
to
do
this,
like
very
well-defined
work
at
this
point
on
the
release
team
and
then
and
then
that
that
you
know
that
contributor
kind
of
maybe
they've
they
float
off
and
they
do
something
different.
They
jump
into
a
different
role.
We're
here
we're
trying
to
we're
trying
to
create
very
sharp
swords,
we're
trying
to
create
an
arsenal
of
people
who
can
we
can
send.
A
We
can
send
to
cube
con
to
deliver
a
presentation
on
foo
or
we
can
have
build-out.
You
know
have
talked
about
strategy,
you
know,
and
and
and
mentor
a
set
of
people
for
some
new
project
that
we're
going
to
be
working
on
right.
So
we
need
to
build.
We
need
to
build
this
team
into
a
set
of
leaders
and
I
think
that
that
is
happening.
So
thank
you
to
everyone
who
has
been
participating
in
this
over
the
last
few,
the
last
few
cycles.
A
A
Cool
I
would
say
that
let's
not
walk
the
board
with
with
eight
minutes
left.
We
have.
You
know
we're
moving
into
one
eighteen,
so
for
the
people
who
are
listening
for
the
people
who
are
on
the
call,
please
take
some
time
to
go
through
the
tasks
that
are
currently
milestone
for
one
seventeen
that
are
assigned
to
you,
be,
you
know,
be
forthright
about
the
you
know.
The
things
that
you
can
can't
won't
won't
be
able
to
wrap
up
by
the
end
of
the
cycle
since
we're
we're
here.
A
Basically,
the
cycle
is
done
in
in
less
than
a
week
at
this
point
and
start
planning
on
what
you
want
to
tackle
for
for
118.
If
there
are
things
that
you
want
to
speak
to
us
about,
there's
something
that
you
saw.
Flyby
and
you're
interested
in
working
on
you're
stuck
on
something
like
our
dm's
are
always
open,
or
if
you
want
to
talk
in
a
public
arena,
you
know
it's
sig
release
and
release
management
on
slack
or
the
mailing
lists.
Let's
yeah,
let's
go
118.