►
From YouTube: Kubernetes Release Engineering 20200609
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
today
is
June
9th.
This
is
a
release.
Engineering
meeting
of
the
that's
excuse
me
right.
It's
a
sig
release,
release
engineering,
subject,
sub
project
meeting.
This
is
a
meeting
that
will
be
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
got
a
few
things
to
cover
today
and
I
would
ask
for
any
of
the
release,
managers
or
anyone
who
is
on
the
call
to
take
a
moment
to
add
anything
that
you
want
to
the
agenda.
So
we
can
discuss
that
in
a
bit.
I
think
we
we've
got
Marco
here.
Actually
so
I'm
not
sure
if
there
are
any
updates,
but
Marco,
do
you
want
to
talk
a
little
bit
about
triage.
B
A
A
So
this
was
initially
scheduled
for
April
and
we
had
some
issue
in
April.
So
the
issues
were
on
the
Google
internal
side.
Changing
this
unraveled,
a
few
things
and
their
internal
systems
that
they've
been
working
out.
It
sounds
like
they
have
since
worked
been
just
about
done
with
working
that
stuff
out,
so
we're
ready
to
try
again.
A
There
is
going
to
be
that
internal
flip
on
the
Google
side,
and
then
our
piece
will
be
essentially
cutting
cutting
our
infrastructure
over
to
from
Google
infrastructure
over
to
Kate's
infra
right,
so
the
PRS
are
already
in
flight
and
I've
been
kind
of
keeping
those
up
to
date.
In
the
background.
So
when
we
need
to
pull
the
trigger,
we
should
be
able
to
do
that
fairly
easily.
A
That
will
trigger
kind
of
a
change
in
our
release.
Process
you'll
be
required
as
a
release
manager
to
now
promote
the
container
images
that
you're
pushing.
This
is
a
change
from
being
able
to
automatically
within
nago
push
your
images
directly
to
a
to
production,
so
within
the
within
the
know,
Mach
phase
the
of
the
stage
and
release
essentially
the
variables
just
get
swapped
right.
It
goes
from
staging
Kate's,
GCR
I/o
over
to
Kate's
GCR
IO
and
the
backing
of
the
backing
registry.
A
For
that
are
our
GCP
account
has
write
access
into
those
buckets
so
from
the
Google
from
the
Google
side
and
from
that
project.
We're
able
to
do
that
once
we
move
over
to
kubernetes
infra
will
be
using
staging
projects
and
from
the
staging
project
for
the
image
fish
to
be
successful.
Our
image
we'd
have
to
do
an
image
promotion
for
those
actually
the
land
from
the
case
staging
kubernetes
JCP
project
over
to
Kate's
artifact,
broad,
/,
kubernetes
right.
A
A
A
A
D
A
Think
that
maybe
we
should
send
a
quick
note
out
to
people
that
cherry-pick
deadline
is
coming
up
and
maybe
do
that
more
consistently.
I
know
it's
part
of
the
part
of
the
patch
release
team
handbook,
but
that
handbook
is
kind
of
in
flux
and
a
little
bit
out
of
date.
So,
let's,
let's
do
that
if
any
of
the
release
managers
want
to
take
care
of
that,
just
raise
your
hand
all.
A
So
the
next
section
we're
talking
about
well
one
any
questions:
okay,
okay,
so
for
the
June
17th
patches,
important
to
note,
there
will
be
a
few
changes
inbound,
which
include
CV
fixes
for
the
the
CNI
CNI
man
in
the
middle
attack
that
was
announced
on
June
1st.
So
it's
important
that
we
are
on
top
of
it
for
that
actually
cycle,
not
that
we
all
always
that
we
usually
are,
but
let's,
let's
just
make
sure
that
the
communication
is
pretty
tight
there.
There
are
a
few
things
to
be
aware
of.
A
One
is
the
one:
are
the
the
changes
within
kubernetes
kubernetes
that
have
been
back
boarded
as
well
as
they're
the
changes
that
have
been
made
to
the
Deb
and
RPM
specs,
so
starting
in
1:18
for
and
and
the
and
the
the
117
and
116
variants
for
the
patches
that
are
going
out,
losing
the
numbers
on
off
the
top
of
my
head
I?
Think
it's
like
117
917,.
C
A
A
So
just
be
aware
that
we
are
starting
in
that
release,
we
will
be
bundling
the
the
cni
plugins
package
with
the
cubelet,
the
for
the
Deb's
and
rpms.
So
the
reason
that
we're
doing
this
is
to
actually
allow
us
to
do
upgrades
of
the
the
cni
plugins
right
so
prior
to
this
release,
the
latest
C&I
plug-in
available
in
our
package
stream
was
zero,
seven
five
or
is
zero.
A
Seven
five
right
now,
and
the
reason
that
we
have
not
done
updates
for
that
is
because
an
update
to
CNI
plugins
within
our
package
dream
will
affect
every
potentially
every
are
a
lot
of
the
cubelet
packages
within
our
package
stream
right.
So
the
cubelet
takes
us
a
dependency
on
kubernetes
E&I
package
and
the
depends
is
greater
than
or
equal
to,
which
means
that
any
potential
older
version
of
kubernetes
are
probably
all
of
the
older
versions
of
kubernetes.
A
If
you
were
to
install
today
using
a
deborah
RPM
and
actually
following
the
the
dependence
not
doing
any
node
eps
witchcraft
you'll
end
up
with
you'll
end
up
with
the
newest
version
of
CNI
of
the
kubernetes
CNI
package
that
we
pushed,
which
means
there
is
an
entire
matrix
of
of
versions,
version
skew
that
we
haven't
tested
and
it's
kind
of
not
impossible
but
unreasonable
to
at
this
point.
So
we
wanted
to
make
sure
that
newer
versions
of
the
cubelet
would
have
the
correct
version
of
CNI.
A
This
is
a
little
better
because
we
can
actually
bundle
and
lockstep
right.
So
if
we
know
that
119
has
you
know,
119
is
compatible
with
a
new
version
of
the
corona,
the
CNI
plugins.
If
it's
0,
8
7
or
whatever
the
next
few
versions
come
out
by
the
time
that
that
we
cut
the
119
release,
then
we
can.
We
can
add
that
we
can
add
that
package
as
well,
so
so
I
think
it's
a
net
improvement.
It
allows
us
to.
A
It
allows
us
to
remove
the
kubernetes
CNI
package
altogether,
rather
remove
the
specs,
for
it
not
necessarily
remove
the
package.
The
older
versions,
older
in
support
versions
of
the
debs
and
rpms,
will
still
require
that
package
to
be
present,
but
for
119
and
and
forward
or
118
4
and
all
of
the
other
patches
forward
that
that's
kind
of
how
that
will
be
set
up,
and
this
this
takes
care
of
a
long-standing
question
of
how
do
we
release?
A
How
do
we
release
kubernetes
E&I
right?
What's
the
overall
process
for
that,
so
we're
getting
to
the
point
where
we
no
longer
will
need
to
directly
release
it,
and
maybe
we'll
get
to
the
point
where
the
required,
the
required
bits
for
C
and
I
are
actually
bundled
in
the
capelet
from
a
code
perspective
and
not
a
packaged
perspective.
A
There
was
some
discussion
there's
some
discussion
on
the
mailing
list
for
cig
network
and
release
engineering
a
while
back,
and
we
can
probably
reignite
that
to
see.
If
so,
there
are
a
few
things
that
we
take
dependencies
on
for
thee
for
the
cni
plugins,
but
it's
very
possible
that,
because
other
CN
eyes
are
actually
responsible
for
for
handling
handling.
A
lot
of
you
know
implementing
you
know
implementing.
D
A
And
and
different
things
like
that,
there's
a
possibility
that
we
do
depend
on
like
that.
Loopback,
the
loopback
plug
in
that's
in
that
package
and
I
believe
may
be
the
bridge
plug-in
that's
in
the
package.
But
if
those
were
part
of
the
qiblah
upstream
and
there
would
be
less
need
to
even
have
even
have
a
scene,
I
plugins
bundled
so
we
can
kick
off
that
conversation
once
we
know
the
bundling
is
actually
successful
right.
You
want
to
take
a
few
incremental
steps
here
and
see
where
we
get
so
any
questions
on
that.
A
A
Sorry
I
have
some
sniffles
today,
all
right.
So
next
topic
we
are
talking
about
the
consolidation
of
the
patch
release
team
and
branch
managers.
Right
so
we've
been,
you
know:
we've
been
building
up
this
crew
for
a
little
bit
and
I
believe
we
have
about
9,
plus
people
between
branch
managers
and
patch
release
team
I.
Think
that's!
A
You
know.
I've
seen,
I've
seen,
Carlos
and
Sasha
and
and
Daniel
really
step
up
to
do.
Some
of
the
work
on
the
patch
release
side
take
some
of
that
load
off
of
Tim
and
I
during
the
patch
release
phase.
So,
if
you're
aware
of,
if
you've
been
around
for
cutting
a
release
and
more
specifically
cutting
a
patch
release
or
a
are
a
minor
dot,
zero
release
for
kubernetes,
you
know
that
the
process
takes
about
say
four
hours
and
change
plus
plus
some
additional
time.
A
For
so
that's
for
the
the
mock
stage
and
mock
release
as
well
as
it's
closer
to
five
might
be
closer
to
five
yeah,
the.
So
that's
for
the
mock
stage
and
release
and
then
the
Mott
and
then
the
actual
stage
and
release.
And
then
you
add
some
time
for
doing
announcements
plus
plus
cutting
the
Deb's
in
rpms,
reaching
out
to
the
the
build
admins
on
the
Google
side
and
cutting
the
Deb's
in
rpms
right.
A
A
Working
on
that
and
kind
of
the
what's
what's
been.
Additionally,
nice
is
that
you
know
for
the
team.
We
have
a.
We
have
a
few
people
in
it
different
and
a
bunch
of
different
time
zones
and
having
the
advantage
of
having
people
start.
The
release
process
before
we
get
in
for
the
day
means
that
we
can.
We
can
work
on
other
things
throughout
the
work
day.
So
that's
been.
That's
been
super
helpful.
I
think
they
have
all
done
an
awesome
job.
A
So
all
of
that
said
thank
you
for
your
super
awesome
work.
Everyone
Carlos,
Daniel
and
Sasha
are
officially
the
entire
team
are
officially
release.
Managers
carlos
daniel
and
sasha
have
effectively
been
promoted
as
a
result
of
this
consolidation
so
congrats
deal
and
thank
you
for
the
work
that
you've
been
doing.
A
So
some
housekeeping
that
happens
as
a
result
of
that
I
staged
a
few
PRS
now,
most
of
which
are
now
merged
to
essentially
change
the
language
and
a
bunch
of
different
places.
So
if
you're
opening
a
cherry
pick,
it
will
now
say
that
you
should
reach
out
to
the
release
managers
group
instead
of
the
patch
release
team
things
like
that
and
I've
kind
of
done.
It
done
an
initial
sweep
of
a
few
areas
to
make
sure
that
we
hit
every
area
that
had
a
mention
of
specifically
the
patch
release,
github
team,
which
no
longer
exists.
A
We
also
had
a
PR
for
kubernetes
org
that
did
some
consolidation
of
our
of
our
github
teams
and
also
added
some
some
nice
things,
which
was
essentially
nesting
all
of
the
github
teams.
So
if
you
are
part
of
a
sub
project
within
cig
release,
there
is
a
top-level
cig
release
notification
group
right
that
we
can
use
for
you
know
bugs
or
something
is
really
on
fire.
We
need
to
contact
everyone.
A
We
could
use
help
with
a
review
or
something
the
that
notification
group
is
there
and
will
ping
everyone
on
every
sub
project
within
cig
release,
which
funny
enough
is
actually
I,
think
the
number
is
actually
less
than
the
people
that
we
had
on
the
cig
release,
github
team
prior
all
right
so
I
think
going
through
them
really
quickly.
We've
got
you
know
the
the
licensing
release,
engineering,
release,
team
sub
projects
and
then
with
within
those
for
the
release
engineering
side.
A
We've
got
the
release
managers
group,
which
gives
access
to
kubernetes
kubernetes
to
do
things
like
doing
cherry-pick
approvals
right
and
overall
write
access
to
the
repo
we've
got
the
milestone
maintainer
group,
which
will
remain
separate
and
within
the
release
team
we
have
the
sake.
Release
leads
the
the
release
team
leads,
which
gives
some
write
access
to
kubernetes
kubernetes
for
the
leads
and
lead
shadows,
and
then
also
the
CI
signal.
Team
I
think
is
the
other
team
that
we
have
so
those
are
all
properly
nested.
A
So
if
that's
something
that
you
wanted
to
do,
please
be
careful
noting
that
there
may
be
groups
under
you
are
within
your
team
that
might
not
necessarily
need
or
want
that
access,
then
yeah
and
be
aware
of
the
notification
team.
The
the
seek
release
notification
team
does
have
quite
a
few
people
on
it,
so
just
be
careful
with
with
with
pings
use
that
only
if
you
need
to
we'll
be
talking
about
a
additional
cleanup
or
of
the
of
the
the
github
teams.
A
I
think
our
teams
are
pretty
clean
at
this
point,
but
within
the
github
administration
team
we've
been
talking
about
having
a
few
different
teams
for
different
purposes.
So
originally,
if
you've
seen
the
the
initial
layout
of
github
teams,
we've
had
the
it
will
be
sig,
seeing
foo
API
reviews
and
PR
reviews
and
test
failures
and
bugs
and
miscellaneous
right.
So
that
was
kind
of
the
initial
layout
and
there
were
about
six
or
so
teams.
A
We
found
that
a
lot
of
that
was
a
lot
of
that
was
not
used
and
the
teams
that
do
exist
today
are
kind
of
out
of
date,
so
we're
we're
kind
of
going
from
sig
to
sig
and
working
on
cleaning
up
those
teams.
The
new
structure
will
essentially
be
top-level
sig
fou
within
the
top-level
sig
fou
will
be
sig,
fou
leads,
which
will
include
the
the
chairs
and
technical
leads
for
that
sig
and
then
sig
food
PR
reviews
right,
which
will
be
a
ping
group
for
people
who
are
interested
in
in
doing
PR
reviews.
A
So
if
you
are
interested
in
doing
PR
reviews
for
us
when
we
create
this
team-
or
let
us
know
ahead
of
time-
feel
free
to
you
know
ping
me
or
ping
Tim
or
mention
in
the
channel
that
you're
interested
in
doing
something
like
that,
and
we
can
get
you
added
to
that
team
when
we,
when
we
create
that
to
you.
So
that
is
so.
That's
kind
of
that
for
the
github
teams.
There's
still
some
work
to
do
on
the
on
the
consolidation.
A
So
we're
gonna.
Try
to
deduplicate
the
information
within
the
release:
managers
handbooks
for
the
sake
of
making
a
little
easier
to
read,
as
well
as
as
well
as
having
fresh
or
content
right,
I
think
there's
some
things
that
have
been
progressively
updated
in
the
branch
manager,
handbook
and
and
there's
staler
content
within
the
patch
release
team
handbook.
So
we
wanna
make
sure
that
those
handbooks
stay
up
to
date.
All
the
time
and
yeah
yeah
I
know
that
was
a
wave
of
stuff,
but
release
managers
awesome
background
by
the
way
Carlos
release
managers.
A
Yay,
okay,
so
one
one
thing
to
note
is
that
we
do
have
a
bit
of
a
a
bit
of
a
blurb
within
the
the
branch
manager
handbook
for
for
release,
manager,
associates
and
I.
Think
that
that
is
maybe
insufficient.
That
blurb
will
also
be
pulled
out
into
kind
of
like
the
onboarding
doc
and
walk
through
some
of
the
general
expectations.
A
One
of
the
expectations
for
you
know
for
release
managers.
You
know
this
is
former
patch
release
team,
as
well
as
branch
management
is
to
establish
a
mentorship
relationship
with
with
the
release
manager
associates.
So
if
you
are
I'm
pretty
sure
it's
happening
I'm,
you
know
based
on
reports
and
all
that
stuff.
But
if
you
are
a
release,
manager
associate-
and
you
are-
you
feel
like
you're-
not
getting
feedback
from
us
about
tasks
that
you're
working
on
or
you're
unsure
of.
A
What's
work
on
next,
how
to
take
the
next
steps
we
want
to
one
feel
free
to
reach
out
to
myself
for
Tim
to
chat
about
that
too.
We
want
to
make
that
path.
A
lot
clearer.
Another
reason
for
the
consolidation
is
that
we
I
think
we
did
not
do
a
good
job
in
really
explaining
what
the
trajectory
from
you
know,
kind
of
evolving
from
a
an
associate
to
to
a
branch
manager
to
a
patch
release
team
member
was
I.
A
Think
it
was
harder
to
make
the
delineation
between
patch
release
team
member
for
being
promoted
from
a
branch
manager
to
a
patch
release
team
member
and
honestly,
so
many
so
many
of
the
duties
are
the
same
you're
doing
PR
review
you're,
doing
you're,
doing
the
mechanics
of
actually
cutting
the
releases,
as
well
as
documentation,
PR
review
and
in
general,
just
representing
us
across
the
across
the
project.
So
so
this
I
think
this
made
a
lot
of
sense
and
the
overall
feedback
on
the
PRS
was
was
positive.
So
yeah,
that's
that's
that
so
stay
tuned.
A
If
you
find,
if
you
find
yourself
running
into
stale
documentation
around
the
release
engineering
process,
please
let
us
know,
please
feel
free
to
help
clean
up
links,
as
you
can
I
would
say,
for
the
link
cleanup
just
give
me
a
few
days
because
I'll
be
working
on
the
consolidation
of
the
handbooks
and
in
that
I'll
be
sweeping
a
few
repos
or
there
are
a
few
references.
There's
still,
one
I
have
to
clean
up
for
the
kubernetes
website,
but
yeah
that
some
of
that
stuff
is
in
progress
related
to
related
to
clean
ups
and
new
documentation.
A
A
A
D
A
D
D
Version,
it
has
been
definitely
interesting
because,
like
the
whole
process
itself
is
quote-unquote
simple,
but
all
of
this
has
been
possible
because
you
taught
us
how
to
do
everything
and
so
going
through.
It
has
been
also
like
when
we
do
the
steps
we
have
well.
We
don't
have
to,
but
it's
useful
to
documented,
so
that
we
can
leave
like
the
Tracey
behind,
so
that
more
people
can
do
it
in
the
future
and
yeah.
So
right
now,
I
was
waiting
for
my
initial
PR
it
to
be
accepted.
Yes,.
D
A
C
A
So
so
that
said,
our
our
process
for
updating
go
has
been.
This
has
been
essentially
dark,
magic,
it's
it's
something
that
was
not
well
known
by
a
lot
of
people,
it's
something
that
was
not
documented
there,
maybe
three
or
four
people
in
the
project
that
knew
how
to
do
it
and
those
are
some
of
our
more
bandwidth
constrained
contributors.
A
A
If
you
want
to
check
those
out
right,
so
it
should
say
like
rel
ends:
go
lang,
update,
walk
through
or
something
part
one
in
part
two,
so
we
did
those
we
did
that
recording
a
few
weeks
back
and
you
wouldn't
expect
it.
But
a
lot
of
the
update
is,
is
just
updating
images
in
different
places
right
and
promoting
them,
and
then
you
know
swapping
a
variable
to
use
the
new
image
and
so
on
and
so
forth.
So
I
won't
go
into
the
process
here.
A
Check
out
those
videos,
there's
about
I,
think
close
to
three
hours
of
content.
As
we
talk
through
a
lot
of
that
stuff,
it's
I
think
it's.
It's
been
interesting
to
me
to
discover
how
that's
done
and
I
think
I
think
the
videos
are
generally
interesting.
We
keep
a
it's
it's
nice
and
peppy.
You
know
if
you
want
to
check,
does
that
go
for
it.
A
So
some
notes
on
the
on
the
go
updates.
I
am
working
through
some
Veronica's
working
through
the
Veronica
Marquis
working
through
the
the
go
one.
Thirteen
twelve
update
I
am
pushing
the
boulder
up
the
hill
on
the
the
go
114
for
update,
so
we're
kind
of
working,
those
in
tandem,
I
believe
the
one
one
thirteen
twelve
update
is
going
to
first,
which
is
why
it's
more
important
for
them
to
continue
moving
forward.
The
114
ones
are
blocked
by
a
sed
B
bolts
update.
A
There
are
some
unsafe
things
happening
in
their
package
right
now
that
we
want
to
make
sure
that
we
bumped
a
new
version,
the
new
version,
which
does
not
exist
yet
before
merging
a
PR
for
for
the
114
for
update.
There
are
also
some
scalability
concerns
that
have
been
since
worked
out
and
those
were
present
in
I
believe
114,
0
and
114,
and
one
does
have
been
since
worked
out,
I
think
from
114
to
forward
so
we're
we're
ready
from
the
go
side.
A
We
just
want
to
make
sure
that
we're
also
ready
from
the
sed
side
before
before
bumping
that
up
so
within
the
notes.
I
I
started
a
skeleton
of
of
what
the
of
what
the
update
doc
is
going
to
look
like
so
I
mentioned
that
we
will
be
putting
a
bunch
of
things
in
the
handbooks
directory
within
the
release.
Engineering,
a
folder
on
cig
release,
so
we'll
be
doing
that
this
is
kind
of
the
first
PR
that
has
something
landing
in
that
handbooks
directory
and
the
reason
it's
handbooks
and
not
role
handbooks
they're.
A
No
longer
really
any
release
manager
roles
right.
So
these
are
just
kind
of
handbooks
right.
So
the
as
I
do
that
consolidation
you'll
see
more
and
more
stuff
move
into
that
handbooks
subdirectory,
but
this
will
be
the
first
doc.
So
it's
linked
in
the
notes.
If
anyone
is
interested
in
doing
some
initial
initial
review,
it's
really
just
a
skeleton
it
it
lets.
A
Unfortunately,
the
go
updates
so
tricky
things
to
understand.
The
go
updates
are
also
sometimes
paired,
with
required.
Update
to
Basel
and
I
know.
I
just
said
everyone's
favorite
word.
So
what
we've
done
to
make
it
a
little
easier
to
our,
but
what
Eric
has
done
fada
of
fada
bot
fame
to
make
it
a
little
easier
to
do.
Updates
for
basil
in
kubernetes
kubernetes,
there
is
a
repo
called
repo
infra
repo
infra
create,
has
some
tools,
tools
that
are
generally
useful
across
multiple
repos.
A
So
the
initial
idea
for
this
repo
was
to
repo
in
first
kind
of
this
thing
that
you
import,
and
then
you
get
all
the
bells
and
whistles
that
of
tools
that
we've
been
building
within
repo
infra
right.
Not
too
many
repos
are
hooked
into
repo
infra
kubernetes
kubernetes
is
one
the
case.
Release
repo
is
also
one.
A
So
if
you've
noticed
you're
you're
able
to
do
the
you
know
be
able
to
do
a
hack,
update,
all
or
hack
verify
all
within
kubernetes
release
the
scripts
that
are
doing
the
verification,
don't
actually
live
in
that
repo
in
our
repo.
They
live
in
repo
infra
right.
So
it's
kind
of
a
framework
to
allow
you
to
do
a
few
things
easier,
so
that
does
like
go
updates.
It'll,
update,
it'll
update
some
scripts
and
and
basil
files
based
on
based
on
changes
in
go
mod.
A
If
you
have,
you
know,
if
you've
changed
a
few
files
it'll,
if
you've
changed
a
few,
what
you
can
call
it
go,
go
files
within
the
packages.
It'll
it'll
update
that
stuff
it'll
it'll
make
sure
that
the
right
basil
files
are
in
place
or
rewrite
them
for
the
verify
step.
It'll
do
things
like
verify
the
boilerplate
so
that
you
have
a
copyright
header
on
your.
You
know
on
your
your
Co
packages
or
your
your
your
shell,
scripts
and
so
on,
and
so
forth.
So
does
little
a
little
updating,
little
verification
stuff.
A
So
we
have
that
in.
We
have
that
in
kubernetes
kubernetes.
Are
we
leverage
in
kubernetes
kubernetes
and
the
one
of
the
one
of
the
niceties?
That's
the
that
repo
infer
includes.
Is
the
the
basil
go
rules
right,
so
every
if
you're
familiar
every
version
of
go,
they
tend
to
release
a
new
version
of
the
space.
Will
go
rules
right
so
how
to
do
go
like
things
within
basil
right
so
every
now
and
again,
a
new
package
for
that
gets
published
or
a
new
release
for
that
gets
published,
and
we
want
to
pick
that
up
right.
A
Because
we
have
so
right
now,
kubernetes
at
master
is
at
version
repo
in
froz
row,
zero,
5
right
repo
in
four
zero
zero
five
includes
basil
rules.
I
think
like
0,
20,
2.1
or
3,
which
support
up
to
go
one
13:11
and
go
114
three
great,
so
to
be
able
to
do
the
113,
12
and
114
for
updates.
We
need
to
update
repo
infra
to
include
the
new,
the
basel
go
rules
and
anything
that
needs
to
be
bumped
and
skylark
or
skylib
or
whatever
they're
calling
it
today.
A
A
So
if
we
has
to
work
on
the
master
side
and
then
and
then
back
port,
the
repo
in
for
a
bump
to
a
few
of
the
branches
that
have
a
similar
go
version,
so
all
of
the
active
support
branches,
the
one
118
117
116
I-
got
stuck
on
the
previous
repo
in
for
a
bump
on
the
118
branch.
So
I'm
going
to
just
update
that
PR
when,
when,
when
master
is
ready
to
bump
to
repo
and
from
zero
zero.
A
D
A
D
A
A
A
We
are
fairly
far
away
from
being
able
to
do
that,
but
we're
trying
to
assess
the
different
things
that
it
would
be
required
to
make
that
happen
if
y'all
are
interested
in
looking
at
that
issue
and
how
much
support
it
has
its
kubernetes
kubernetes,
eight
eight
five,
five
three
and
you
know
you'll,
see
a
variety
of
comments
from
different
kind
of
senior
members
of
the
project,
essentially
complaining
about
basil.
So
that's
a
that's
a
fun
issue
too,
to
read
through
it'll.
Give
you
some
context
about
why
we
want
to
make
that
kind
of
change.
A
Sasha
I
believe
opened
a
sister
issue
within
kubernetes
release
to
talk
about
removing
basil
infrastructure
from
from
our
repo
right,
so
basil
overall
becomes
easier
to
remove
when
we
stop
using
it
stop
taking
a
dependency
on
it
in
in
smaller
repos.
So
we're
trying
to
we're
trying
to
set
some
example
there.
A
We
do
lose
kind
of
the
niceties
of
being
able
to
import
some
verification
and
update
scripts,
but
I
think
it's
a
minimal,
minimal
wind
that
we
were
getting
out
of
that
and
I
think
overall,
removing
basil
on
our
side
on
the
release
site
on
the
kubernetes
release
repo
side
I
will
make
it
easier
for
us
to
understand
what's
happening
in
our
tests.
So,
okay,
that's
that's
it
for
go
and
basil
updates,
I!
Think
and
now,
with
a
few
minutes,
left
I
see
no
new
things
on
the
agenda.
A
A
A
B
A
So
next
week,
Thursday
so
I
hope
to
see
a
bunch
of
you
there
for
that
Tim
and
I
will
be
working
on
the
deck,
but
yeah
we'll
be
talking
about
I.
Guess
it's
been
a
while
now
that
the
the
community
meetings
have
gone
monthly,
so
it's
been
a
while,
since
we've
done
an
update
to
the
community,
so
we'll
be
scraping,
be
scraping
a
bunch
of
the
emails
that
I've
sent
over
the
past
like
six
months
or
so,
and
putting
together
some
presentations
based
on
that
we've
done
a
lot
of
later
Joseph.
A
We've
done
a
lot
of
really
phenomenal
work
and
could
not
have
been
done
without
this
awesome
team.
So
I
want
to
heavily
heavily
heavily
congratulate
and
pat
you
on
the
back
and
I'm
going
to
shout
it
loud
during
the
community
meeting.
So
thank
you
again
for
the
work
that
you've
been
doing.
It
is
made
our
infrastructure
or
faster,
better,
stronger
and
I.
Think
we've
we've
built
a
real
sense
of
camaraderie
around
this
group,
so
yeah
your
team.