►
From YouTube: Kubernetes Release Engineering 20191014
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,
this
is
the
Monday
October
14th
edition
of
the
release
engineering
sub
project
meeting.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say.
What
you
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome.
People
should
be
easy,
so
we're
gonna
get
started
with
before
we
get
started.
I
want
to
see
if
anyone
has
topics,
if
not
we're
going
to
run
the
board
today,.
B
C
B
A
All
right,
tippy
arse,
you
are
probably
referring
to
the
image
builders,
one
Tim;
yes,
okay,
all
right
so
kind
of
the
move
for
this.
So
anyone
who
is
aware
of
the
image
builder
pusher
setup
that
we've
got
test
infer
kind
of
has
it
set
up
so
that
they
can
arbitrarily
build
images
on
post
submit,
and
there
are
a
few
interesting
things
that
come
with
being
able
to
set
that
up.
So
we
had
an
issue
open
and
due
to
to
about
kind
of
determining
what
the
image
building
policy
was
going
to
be
for
the
K
release.
A
We
were
talking
about
what
should
go
in
the
image
and
after
a
while
I
kind
of
realized
that
we
went
back
and
forth
and
we
kind
of
left
it
open
for
a
Slyke,
ace
and
I
are
going
to
talk
later
today
about
what
that
process
should
look
like
or
but
we
kind
of
left
it
open
to
the
point
where
it
was
impossible
for
someone
to
do
work
on
this
without
getting
clarification
from
us.
So
there
are
a
few
things
that
I
noticed
which
didn't
exist
before
within
tests
infra
there
is
a
there
is
an
image.
A
A
So
one
of
the
cool
things
about
this
setup
is
this
variance
file
right.
So
you
can
see
the
variance
file
in
use
if
we
go
to
the
cubic
ins
été
test
right,
so
the
very
file
here
it
has
a
few
variants
of
it
defines
a
configuration
right
configuration
variable
as
well
as
a
few
different
variants
for
go
version.
The
kubernetes
version,
the
basel
version
so
on
and
so
forth.
Right
when
you
call
one
of
these
variants,
while
using
while
using
that
builder
image,
it
will
build
what
you
specify
based
on
those
variants
right.
A
So
we
could.
We
could
potentially
wire
our
our
images
to
do
something
very
similar.
What
I
wanted
out
of
this
was
I
wanted
some
means
to
automatically
build
images
right
on
commit,
and
so
there
was
a
consideration
for
a
small
portion
of
time
about
whether
or
not
we
were
going
to
move
our
images
to
test
in
for
just
for
the
sake
of
getting
that
benefit.
But
since
we've
even
barely
broached
that
topic,
we
can
now
do
it
for
any
repo
right.
A
I
have
no
idea
where
it
is:
oh,
okay,
it's
probably
a
JS
filter
I
mean
go.
A
A
So
we
have
a
few
setup
here
and
for
someone
who
has
seen
a
does
not
seen
a
proud
job
before
this
is
essentially
it's
essentially
a
kubernetes
manifest
right
with
some
sugar
on
top
of
it
right
so
annotations,
which
define
where,
where
we
want
the
the
job
to
report
into
on
test
grid.
So
we
have
a
cig
release.
Image
pushes
and
sake
release
master
informing,
and
we
can
view
these
boards.
A
Well,
let's
go
to
the
image
pushes
alright,
so
flaky
jobs,
and
this
is
kind
of
where
the
PR
came
from.
So
we've
got
a
few
things
to
notice
about
this
job.
One
is
the
decorate.
True
decorate
true
turns
on
pod
utilities,
which
are
again
some
sugar
around
building
testing
for
jobs.
If
you're
building
a
new
job
and
testing
for
you
should
use
pod
utilities,
the
next
piece
is
branches
are,
is
run,
have
changed.
A
Post
Smiths
are
after
your
PR
emerges
their
set
of
jobs
that
will
be
triggered,
so
you
can
define
that
by
just
specifying
those
limits,
your
repo
name
of
the
job,
the
cluster
it's
running
on.
This
is
important.
It's
running
on
the
testin
for
a
trusted
cluster,
because
the
trusted
cluster
has
access
to
some
of
the
credentials
and
the
most
important
one
is
the
credentials
that
we're
using
to
to
trigger
jobs
within
GCP
right
across
various
projects.
A
So
now
that
we've
got
the
CNC
F
so
for
each
GC
BP
project,
there
is
basically
we've
granted
permissions
too
proud
to
run
within
the
project
right
and
that's.
If
anyone
wants
to
see
that
at
some
point
it
is
in
I
know:
I'm
all
over
the
place.
I
will
bring
this
back
together
in
just
a
bit:
slash
gates,
IO.
A
A
This
will
ensure
that
they
have
access
to
staging
access
to
the
GCS
portion
of
that
GCP
project,
as
well
as
setting
up
owners
and
and
the
image
promotion.
Stuff
is
not
really
important
to
this,
but
essentially,
we've
got
configs
for
we've
got
configs
for
a
set
of
different
staging
repos
within
I.
Think
it's
groups.
A
Yeah,
so
here
you
can
kind
of
see
I'll
speed
through
it,
since
it's
got
email
addresses
but
yeah,
and
you
can
read
more
about
it
here:
Automation
of
Google
Groups
maintenance.
So
we
we
use
that
file
to
automate
the
Google
Groups
maintenance,
and
then
we
use
those
we
use.
Those
email
addresses
to
grant
privileges
to
GCP
for
gzp.
A
All
right
so
back
to
this
job,
so
just
firing
the
image
builder
container
and
we
can
go
look
at
the
config
for
that
image
builder
container.
But
the
entry
point
is
run
dat
Sh,
which
essentially
passes
all
the
arguments
that
you've
given
it
over
to
the
Builder
script
and
then
there's
a
project
so
Kate's
staging
release
test
a
scratch
bucket.
A
A
Alright,
so
down
here
and
I
realized,
maybe
I
should
make
that
bigger.
Okay
right,
so
it
it
parses,
a
few
flags
log
directory
a
scratch
bucket
a
project
whether
or
not
allowed
dirty
will
determine
whether
or
not
it'll
allow
you
to
run
the
job
on
the
repo
if
the.
If
the
repo
is
not
clean,
or
rather,
if
things
have
not
been
committed
to
the
repo
right
variant
with
these
are
the
variant
files
I
was
specifying
before.
So.
If
you,
the
I,
was
talking
about
before.
A
So
we're
checking
to
see
if
the
last
the
last
flag
is
a
positional
argument,
we're
checking
to
see
if
the
image
directory
has
been
provided
and
if
not
we're
going
to
set
an
exit
code
of
one
right.
If
it
is
provided,
then
we're
going
to
use
that
as
the
image
directory
CD
into
the
root
directory
and
then
run
the
build
jobs
right.
So
the
CD
route
is
due
to
two
right.
A
Basically,
I
want
to
see
if
there
is
a
build
workspace,
it's
not
I'm
gonna
get
rev
parse
get
the
top
level
of
that
and
then
CD
into
that
right
and
then
the
run
builds
job.
Do
it's
doing
a
few
things
like
setting
the
scratch
bucket?
It's
taking
the
working
directory,
copying
the
working
directory
up
to
basically
tearing
it
and
then
uploading
it
into
the
scratch
bucket,
and
then
it's
it's
referenced
for
the
GCP
job,
the
GCB
job
right.
So
basically
on
TARDIS
a
workspace.
A
Then
it
gets
the
variants
that
you
may
have
specified
if
it
doesn't
see
any
of
the
variants,
it's
going
to
just
try
to
run
a
single
job
with
your
default
config
right
and
then
it
this
sync
wait.
Group
is
essentially
a
mutex
that
waits
for
each
of
those.
If
it's
not
a
single
job,
it's
going
to
wait
for
each
of
these
jobs
to
complete
before
returning
a
set
of
errors
across
these
shops.
Basically,
we
don't
want
to
block
on
the
failure
of
one
job
if
the
rest
and
the
chain
could
potentially
succeed
right.
A
So
the
PR
to
actually
answer
Tim's
question
the
PR
changes
a
few
things
so
we're
taking
out
the
CD
2
root
directory
because
it
was
actually
within
the
scope
of
within
a
different
function
scope.
So
it
was
essentially
seeing
if
it
could
CD
into
the
directory,
but
not
actually
doing
that,
which
means
the
jobs
that
were,
which
means.
Essentially,
we
weren't
going
to
the
image
directory.
So
so
this
tool
was
only
working
for
top
level.
A
So
we
can
look
at
my
changes
really
quickly.
I
also
did
a
test
build
of
the
builder
tool
and
then
ran
that
locally
to
see
if
it
would
work
right.
So
my
change
is
due
to
do
right.
We
add
a
validate
image
directory,
so
I
noticed
that
these
were
these
are
failing
and
they
kind
of
should
not
fail.
If
they're,
if
certain
I
mean
they
kind
of,
should
fail
early.
A
If
there
are
certain
prerequisites
that
were
are
not
met
right,
so
validate
image
directory
basically
takes
the
image
directory
that
you
specified
with
options
tries
to
stat
it.
If
it
doesn't
exist,
then
it'll
return
that
the
image
directory
doesn't
exist
immediately
right.
If
the
file
info
says
that
it
actually
is
a
directory,
maybe
it's
a
file
that
was
named
the
same
thing.
A
If
it's
not
actually
a
directory,
it'll
actually
fail
it'll
fail
again
right,
then
we
take
the
build
the
cloud
bill,
build
file
and
the
docker
file,
and
let's
just
go,
let's
loop
through
them
again
check.
If
they
is
try
to
satin.
If
they
don't
exist,
say
they
don't
exist
right.
So,
let's
bail
out
of
anything
or
Alyssa
bail
out
of
stuff
super
early
before
actually
submitting
it
to
cloud,
build
just
renaming
the
uploading
working
directory
to
uploading
image
directory.
A
Remove
removing
this
piece,
because
there's
really
no
reason
to
specify
this
config
since
we're
going
to
assume
that
the
default
is
cloud
build
yanil
and
if
we're
actually
seeding
into
the
directory,
then
it
will
be
called
called
cloud
build
yeah
mode.
It
won't
be
appended
with
the
with
the
basing
with
the
directory
name.
Excuse
me,
then
running
build
jobs
right.
B
A
Okay,
alright,
so
we
did
a
few
things
so,
okay
right,
so
the
cloud
build
for
the
Debian
builder,
for
example,
all
right.
It's
just
doing
a
simple
go,
build,
show
Deb's
with
some
environment
variables
set
so
see
you
go
so
you
go
off,
the
OS
is
Linux
and
our
architecture
is
amd64
and
it's
really
just
doing
a
build.
So
it's
using
the
cloud
builders
docker
file
right
and
you
can
read
more
about
this
stuff.
If
you
want
to
here
great.
A
So
the
substitution
loose,
the
substitution
option
is
a
allow
loose
essentially
allows
you
to
if
some
of
the,
if
some
of
the
variables
that
you
specify
are
incorrectly
specified,
it
won't
bomb
on
those
the
right.
So
the
the
the
cloud
builders
docker
container
is
essentially
just
it's
an
entry
point
to
docker
right.
So
we're
saying
docker
build
here.
Are
the
tags
right?
I'm
gonna
use
the
get
tag
of
the
thing
that
just
merged
as
well
as
tag
it
with
latest
write
and
then
build.
A
What
do
I
want
to
build
I
want
to
build
the
the
current
directory
right
and
then
yeah,
so
this
images
portion
will
again
using
the
tagged
and
the
latest
it'll
check
to
see
if
these
were
actually
pushed,
as
these
are
not
pushed
specifying
them
in
images.
These
are
actually
not
pushed
to
the
container
registry.
Within
that
GCP
project.
It
will
fail
right
here,
we're
also
adding
a
module
for
for
the
dead
builder
and
the
reason
for
the
module
is
essentially
because
cloud
build
likes
to
see
a
workspace
where
everything
is
self-contained.
A
So
for
submitting
the
Deb
stuff
to
that
workspace,
we
essentially
need
to
make
sure
it's
self-contained,
so
it
can
build.
It
can
build
itself
without
having
to
look
to
the
top
level
modules
file.
The
top-level
go
mod
and
go
go
some
so
separate
module
for
that
and
again
it's
a
small
amount
of
dependency.
So
it's
not
too
onerous
to
maintain
the
RPM
builder
very
similar.
A
B
A
So
this
will
rebuild
the
the
the
sums
for
the
for
the
the
NGO
repos
that
you're
importing,
as
well
as
there's
some
other
stuff
that
it
does
so
we
also
add
the
hack
dot
tools
in
the
second,
so
I
made
some
very
cosmetic
changes
to
the
docker
files,
because
I
basically
wanted
to
trigger
that
run,
have
changed
so
really
they're.
Just
spacing
things
around
the
docker
file
in
the
go
mod
for
the
next
time.
I
ran
the
update.
A
You
can
see
that
the
release
build
Debs
gets
pulled
in
because
it
recognizes
it
as
a
module
now
and
then
in
tools.
We're
also
adding
hacks
hack,
slash
tools
that
go
we're
also
adding
a
blank
import
for
that
sub
module,
and
the
reason
for
that
is
so
if
someone
go-go
gets
the
top.
If
someone
go
gets
the
repo,
they
will
still
have
the
dependencies
of
the
lower
sub
modules
within
that
right.
A
So
if
they
go
get
as
they
go
get
the
top
level,
the
top
level
will
include
all
the
dependencies
for
all
of
the
sub
modules.
If
you
add
one
here,
this
kind
of
pack
is
used
across
like
tests,
infra
and
I-
think
K
org
and
within
the
cluster
API
projects,
essentially
to
make
sure
that
before
someone
starts
working
on
the
project,
they
have
all
the
dependencies
that
they
need
and
that's
yeah.
That's
that's
kind
of
it
right.
So
when
these,
when
you
know
when
this
runs,
what
else
was
changed?
A
Yeah
I
just
moved
very,
very
little
of
the
logic
around
to
make
sure
that,
like
one
we're
actually
seeding
into
the
directory-
and
we
wanted
to
see
if
we
you
know
we're
in
the
working
directory
if
it's
the
right
working
directory,
like
let's
just
print
that
out,
if
not
you
know,
if
not,
let's
bail
and
before
we
start,
we
do
the
validate.
We
do
the
validate.
So
we
fail
early.
That's
that's
it!
It's
a
pretty
simple
go
script.
B
I
would
hope
that
that
was
useful
for
people.
If
you
look
at
the
the
minutes
for
somebody
to
to
see
this
PR
command
and
implicitly
understand
all
of
those
other
things
that
chain
together
to
make
that
work,
I'm
guessing
most
of
our
attendees,
don't
understand
that
big
picture,
so
I
would
imagine
that
was
useful
orientation
to
people
day.
A
So,
yes,
we're
waiting
for
that
to
merge
once
that
merges
I'm,
going
to
make
another
cosmetic
change
to
one
of
these
files
to
let
that
build
trigger
and
part
of
the
reason
this
is
happening
right
now,
at
least
is
I
know.
Dimms
is
working
on
some
improvements
to
getting
the
cap
G
tests
working
the
cap
chant
and
tests
working
I'm,
so
he
also
wants
to
verify
that
he
can
build
kind
of.
He
wants
to
start
building
the
flow
of
run.
The
test.
The
test
is
successful.
A
He
is
also
asking
for
like
a
rebuild
of
the
containers
that
would
run
the
jobs
and
I
was
like
this
should
be
automatic.
We
like
I
was
like.
Let
me
just
wire
this
up.
I.
Think
it's
simple
enough!
Now
that
Kathryn
has
added
some
of
those
improvements,
so
this
was
not
possible,
maybe
a
month
month
and
a
half
ago
for
folks
on
the
call.
This
is
like
relatively
new,
so
we're
gonna
I,
don't
know
if
aces
on
the
call,
but
you
know
we're
gonna
chat
later
about
getting
back
into
the
the
image
stuff.
C
B
Okay,
all
right!
Well,
we've
got
so
we
got
a
dozen
people
on
the
call.
You
just
spend
a
half
hour
describing
something
that
probably
took
you
many
many
hours
to
come
to
understand.
Originally,
if
the
dozen
people
on
the
call
spin
that
same
many
many
hours,
we've
just
invested
100
hours
coming
to
understand
what
you
already
know
so
sharing
that
knowledge
saves
everybody
time
and
allows
them
to
get
to
contributing
code
sooner
yeah.
A
A
So
in
in
you
know
talking
about
that,
you
know
we
have.
We
have
introduced
a
new
set
of
release,
manager,
associates
and
I
know.
A
few
of
you
are
asking
me
like.
How
do
we
do
this?
What
is
what
is
this
role?
Even
right?
The
role
is
loosely
defined,
and-
and
it's
you
know,
the
reason
for
that
is
essentially
like
we
want
to
bring
in
people
that
we
can
trust.
It's
I
realized
this
cycle
that
it's
even
easier
to
bring
in
people
that
we
already
trust.
A
So
the
selections
for
the
release
manager
associates
were
only
made
from
previous
release.
The
previous
release
team.
So
this
time
around
I
want
you
to
ask
questions
like
Tim
asks,
like
I
saw
a
PR
I,
don't
even
know
how
it
works
like.
Can
you
walk
me
through
that
right?
The
the
role
essentially
exists
to
pay
down
release
engineering,
technical
debt
right,
so
every
time
you
see
a
thing
that
might
be
wrong,
there's
a
good
chance
that
it
is
wrong.
A
Okay,
like
if
it's
undocumented,
like
there's
a
good
chance.
Someone
doesn't
understand
it
right
so,
like
your
job
as
a
release,
manager
associate
is
to
go
figure
it
out
right
and
like,
and
that's
that
really
is
the
job
like.
That's
so
all
the
stuff
that
you
learn
from
the
release
team
investigating
things
across
multiple
kubernetes,
repos
and
reporting.
A
You
know
reporting
status
across
getting
information
from
multiple
SIG's
and
reporting
status
back
to
us
like
that's
what
I
want
you
to
keep
doing,
but
you
have
the
freedom
to
be
a
lot
more
like
you
have
the
freedom
to
choose
your
own
adventure
right,
you're
interested
in
image,
building
fix
our
images
if
you're
interested
in
figuring
out
how
a
Nago
works
like
read
through
and
go,
and
then
document
it
for
us
right
if
you're
interested
in
lots
of
stuff
right,
okay,
right,
one
of
the
things
I
want
to
happen
is
to
you.
A
You
know
for
us
to
rewrite
rewrite
the
release
tools
that
we
have
right
now
in
go
right.
If
that's
something
that
you're
interested
in
right,
maybe
take
a
moment
and
trying
to
find
my
PR
right,
maybe
take
a
moment
and
look
at
this
PR
right
and
you
know,
and
I
can
I
can
walk
through
it.
It's
fairly,
you
know
this
one's
fairly
simple
again:
I
am
NOT,
a
I
am
NOT,
some
mega
go
coder
or
anything
like
that.
A
It's
it's
just
usually
me
spending
a
few
hours
banging
my
head
on
a
wall
and
trying
to
like
hack
on
something
right.
So
you
know
this
one
is
you
know
this
one,
essentially
we're
adding
a
branch
fast
forward
tool
right
and-
and
it's
doing
exactly
the
same
thing-
that
the
the
bash
based
branch
fast
forward
tool
is
doing.
But
you
know
this
is
I
essentially
wrote
this
up
to
to
demonstrate
that
like
yes,
we
can
do
this,
so
let's
start
doing
this.
A
So
if
people
are
interested
in
doing
this
kind
of
stuff
like
what
I
would
love
to
land
first,
like
alongside
this
tool,
is
a
package
detail
right,
so
we
have
a
set
of.
We
have
a
set
of
libraries
quote
unquote
in
bash
that
we
use
for
a
lot
of
the
things
that
we
do
in
the
and
the
kubernetes
release
repo
right
so
and
they
do
things
like
make
sure
that
logs
exist
when
to
rotate
logs,
how
to
get
the
token
or
get
the
the
authorization
URL
for
pulling
things
from
github
or
pushing
things
to
github.
A
All
right,
so
if
you
go
to
Lib
and
we
can
take
common,
for
example,
there's
release
Lib
and
then
there's
also
get
lip
right.
So
common
does
some
stuff
like
right.
It's
you
know.
It
sets
some
pretty
printing
stuff
for
your
terminal
and
log
echo
right
so
log
echo
will
write
to
logs
and
also
standard
out.
A
We
can
specify
common
exit
and
common
eggs
at
zero
or
one
right
and
no
kind
of
rap
our
exit
codes
within
within
some
of
these
scripts
right,
the
one
that
I
thought
for
ever
was
like
ask
yarn
I
was
like
who
is
yourn
what's
going
on?
Finally
realized,
like
that's
ask
yes
or
no
all
right,
so
this
little
problem
to
you
during
some
script
to
answer
yes
or
no
right
so
branch
fast
forward
is
an
example
of
that
it
will.
You
know
once
you've
verified
that
the
fast-forward
looks
good.
A
It
will
ask
you
like
hey:
did
you
go
verify
it?
Okay,
are
you
sure
you
want
to
push
it
now
cool
right,
so
we
have
that
in
a
few
scripts
as
well
step
header,
step
powder,
if
you
specify
step
header
it
will
capture
like
the
function,
call
or
something
and
say
let
go.
This
is
step
one
of
blah
right
and
then,
but
you
get
the
idea
right.
So
these
are
common
functions
that
we
do
across
across
a
lot
of
the
scripts.
There's
release
Lib
and
again
common
functions.
A
It
will
you
know,
it'll
get
a
job
cache
from
something
that's
in
in
prowl
or
saved
to
GCSE
storage
as
a
result
of
a
prowl
build
run
so
pulling
the
logs,
and
you
know,
and
and
doing
some
fancy
Wow
lots
of
okay,
okay,
alright,
to
find
what
the
to
find
what
the
the
job
cache
is
that
what
the
build
number
is.
So
we
can
determine
what
the
next
build
number
is
going
to
be
setting
the
build
version.
A
So
these
build
versions
are
eventually
used
in
how
we
do
the
staging
and
releasing
of
kubernetes
versions
right
and
again,
I
won't
I
won't
try
to
like
I,
don't
understand
all
of
it
as
well
right.
So
that's
exciting
so
like
this
is
an
opportunity
like
if
you're,
like
wow
I've,
never
seen
this
like.
Oh,
go
check
it
out.
A
lot
of
it
is
easy
to
read.
Some
of
it
is
doing
black
magic.
So
take
some
time
with
this
stuff,
we've
we've
run
into
you
like.
A
Well,
we've
broken
the
bill
because
someone
missed
the
comma
or
so
so
take
time
and
take
care
with
making
changes
to
these
files
and
reading
through
them.
Checking
the
release
bucket,
see
if
see
if
it
exists,
but
again
you
get
the
idea.
Those
are
those
are
functions
used
for
releasing
these
are
functions,
to
figure
out
how
how
we
push
things
to
get
or
how
we
get
things
from
get
right.
A
So
it's
like
here's,
the
repo
here
you
know,
here's
the
root
of
you,
know:
here's
the
the
kubernetes
repo
like
and
so
on
and
so
forth
right.
So
the
reason
you
know
I'd
love
to
get
to
a
place
where
kubernetes
kubernetes
depends
on
this
repo
and
it
depends
on
the
repo
primarily
because
of
the
push
build
script
right
and
so
Ben
had
opened
a
an
issue
to
remove
the
like
to
move
the
push,
build
script
over
to
kubernetes
kubernetes
right
because
then
they
kind
of
like
they
can
build
without
us
right.
A
So,
if
we
break,
if
we
break
kubernetes
release
at
any
one
time,
it
doesn't
affect
the
CI
process.
It
may
affect
the
staging
and
release
process,
but
it
won't
affect
day-to-day
operations
for
like
the
kubernetes
project
if
anyone's
working
on
like
main
kubernetes
right.
So
the
problem
we
see
here
is
that
push
filled
sources,
the
common
library
at
the
gate,
Lib
library
and
the
release,
Lib
library,
which
means
it's.
Essentially,
it's
essentially
tied
to
where
it.
Wherever
these
libraries
live
right,
we
could
move
it.
A
We
could
do
packy
stuff
to
move
it
around,
but
it
makes
sense
to
leave
it
where
it
is
for
the
moment,
at
least
so,
to
move
it.
We
would
need
to
make
these
libraries
portable
right
and
then
that
kind
of
leads
back
into
starting
to
write
common
utilities
and
starting
to
write
rewrite
some
of
these
things
and
go
instead
right.
A
So
yeah,
that's
some
of
my
thought
process
around
it
again.
If
people
are
interested
in
doing
this,
we
should
probably
merge
this
soon
as
Ultem
I'm
going
to
look
back
over
it
and
and
it's
not
in
the
critical
path
for
anything.
So
it
probably
makes
sense
to
just
get
it
in
it
can
be
used
as
an
example
yeah
few
more
things
to
do.
But
you
know
it's,
you
know
it's
also
asking
yes
or
no,
or
you
know
doing
a
prompts
for
you
know,
and
then
there's
like
there's
some
get
stuff.
A
It's
you
know,
pin
to
my
repo
right
now,
but
that's
going
to
be
fixed
right.
Does
a
branch,
regex
and
yeah
says
so
a
lot
of
the
things
that
it's
doing
this
in
in
that
library
that
you
saw
checking
if
the
branch
exists
or
syncing
the
repo
or
just
getting
the
rev
first
right
or
a
short
ref
first
merge
base
stuff
like
that
right,
so
those
were
things
that
were
all
required.
I,
essentially,
don't
want
to
try
to
rewrite
all
of
the
library
all
of
those
libraries,
but
I
want
the
way.
A
We
write
the
tools
to
determine
what
we
need
in
the
libraries
right.
So
that's
why
we
took
like
a
small
tool
branch
fast
forward
to
start
carving
out
what
is
required
there
right.
So
any
questions
on
that
I
know
I'm
kind
of
like
jumping
around
all
over
the
place
like
that.
But
this
is
what
the
inside
of
my
head
looks
like
kubernetes,.
A
A
All
right,
so
what
I
usually
do
before
I
start?
This
is
I
will
go
to
add
cards
right.
So
one
the
way
the
board
is
organized.
It's
fairly
comprehensive,
oh
there's,
a
backlog,
there's
a
to-do
section
in
progress,
things
that
are
being
actively
reviewed,
which
are
PRS,
will
end
up
in
the
review
in
progress,
and
then
there
are
set
of
done
columns.
A
So
I
started
adding
done
columns
based
on
tied
to
the
tied
to
the
release
cycle
so
that
we
could
kind
of
we
could
fairly
easily
if
we
wanted
to
do
like
kind
of
build,
a
brag
sheet
right
and
and
kind
of
like
obsess
over
the
things
that
we
were
working
on
the
the
previous
cycle,
because
I
think
classically,
we
have
not
tried
to
track
some
of
that
stuff.
So
there
was
a
done
column
and
done.
Column
was
basically
everything
before
one.
Sixteen
that
we
can.
A
You
can
see
that
there
was
quite
a
bit
of
work
done
in
one
sixteen
and
then
there's
quite
a
bit
of
work
already
done,
even
though
one
seventeen
has
really
just
started
over
there
right.
So
everything
that
gets
pulled
into
done,
whether
it
gets
closed
or
merged
as
a
PR,
will
automatically
get
pulled
into
this
column
right
now.
What
I'll
do
first
is
I,
usually
go
to
add
cards.
I
will
search
for
the
area,
release
engineering
and
across
all
repos
and
I'll.
A
Just
check
to
see
if
there
are
any
cards
open,
are
closed
that
are
actually
related
to
release.
Engineering
like
this
is
tagged.
This
release
engineering,
but
it's
only
tagged.
This
release
engineering
because
it's
a
proud
bump.
That's
touching
multiple
areas
right,
so
it's
not
super
relevant
to
us,
and
then
you
can
see
that
a
lot
of
these
are
a
lot
of
these
or
problems
so
cherry-pick
a
update
to
use,
go
one
twelve
that
counts
come
on.
A
Alright
and
I
can
see,
there's
pretty
much
nothing
there.
That's
this
should
be
in
kubernetes
release,
actually
leave
that
out
yeah.
So
since
I
since
I
last
checked,
there's
nothing
new
right,
but
let's
talk
about
some
of
the
stuff.
That's
in
progress
so
determining
image.
Building
process
we've
chatted
about
that.
Quite
a
bit.
A
A
Should
we
bump
go
right
and,
depending
on
when
the
newest
co
release
has
come
out
that
will
determine
whether
or
not
we
should
do
it,
because,
because
Italy
like
there
I
think
there
are
two
times
in
the
year
where
the
go
version
will
the
new
go
version
will
come
out
right
around
the
time
that
we're
about
to
release
and
we're
like?
Oh,
it's
too
late,
not
gonna.
Do
that,
so
that
kind
of
happened
for
for
113.
A
A
Me
if
I'm
wrong,
it's
either
out
or
the
pre
announcement
just
hit
for
it,
so
it
should
be
coming
soon,
not
good,
okay,
all
right
yeah,
so
I,
you
know
so
in
in
1:13
the
performance
regression
I
will
be
I
believe
be
handled.
So
at
that
point
we
can
start
moving
some
of
our
stuff
over,
so
that
PR
is
kind
of
like
just
waiting
in
the
wings
and
looks
like
liggett's
working
on
that.
A
A
A
Right,
so
if
anyone
wants
to
check
out
what
those
annotations
are
the
config
for
ker,
it's
basically
something
that
will
run
around
branch
cut
time
and
it
will
look
for
jobs
that
have
fork
per
release.
True
set
to
it
and
basically,
basically,
what
it
will
end
up
doing
is
helping
us
to
generate
these.
The
very,
very
important
boards
that
we
use
to
determine
whether
a
release
is
ready
to
cut
alright.
A
So
you
can
see
some
of
these
boards
if
we
go
to
116
blocking,
for
example,
right
alright,
so
you
can
see
like
basil,
build
116
right
compared
to
basil,
build
master
right.
So
if
I
specify
master
in
a
job
and
it
Forks
out
it
will
it
will
fork
it,
it
will
fork
and
rename
the
job
to
something,
that's
relevant
for
that
branch
right.
So
you'll
see
the
same
in
like
1/16
blocking
115
blocking
down
so
like
the
last
supported
1:13
blocking
right.
So
this
this
config,
the
config
for
Kerr,
is
responsible
for
doing
that.
A
Right
and
yeah,
it
explained
yeah.
It
explains
the
flow
for
this
here
right,
the
job
name
ends
and
master.
It
will
be
replaced
with
whatever
the
current
release
is
or
whatever
the
next
release
was
going
to
be.
So
you
specify
it
when
you
run
the
when
you
run
the
config,
which
I
forgot,
how
did
you,
but
it's
documented
and
other
branch
management,
playbook
and
yeah
that
will
take
care
of
creating
the
jobs
for
the
117
branch
when
it's
time
to
create
those
jobs
which
will
be
when
we
cut
our
first
beta.
A
A
A
A
Right
so
here
write
annotations
for
parolees,
true
for
release
replacements.
So
if
it
notices
this
field
somewhere
extra
publish
file,
it'll
switch
it
from
extra
publish
file,
Kate's
master,
our
verdict,
eights
beta,
and
essentially
what
that
does
is
it
will
change
the
version
marker
file
from
master
to
beta
right
the
version
marker
files
will
be
used
in
CI.
A
A
So
that's
kind
of
what
that's
kind
of
what
the
job
config
looks
like.
So
on
a
periodic
it
will
they're
there
a
set
of
different
rules
that
it'll
do
for
different
types
of
jobs
right
so
periodic
s--.
If
it
ends
in
master,
it
will
be
replaced
with
whatever
the
newest
version
is
and
then
the
stuff
that
is
targeted
for
if
it's
yes
it'll
also
add
it
to
the
all
board
right,
I'm.
So,
depending
on
what
the
job
is,
we
might
want
to
reconfigure
this
so
it'll.
A
Add
it
to
like
the
informing
Bart
board
instead
of
all
right,
so
there
are
a
few
things
that
I
want
to
clean
up
in
that
eventually,
but
it's
not
high
terribly
high
priority
and
this
looks
to
be
in
progress
but
not
directly
owned
by
us
we're
just
kind
of
like
advising
on
it.
I
guess
the
branch
fast
forward
tool
that
we
looked
at,
let's
see
release,
notes,
markdown
output,
templates,
Sasha,
I
thought
I
saw
you
on
a
call.
Are
you
here.
A
Cool
cool:
do
you
need
any
review
on
this?
Are
you
good
for
now,
I.
C
C
A
Alright,
there
is
one
that
has
been
open
for
a
bit.
It
looks
like
you
used
to
github
wiki
to
store
images
in,
so
this
is
kind
of
because
the
test
grid
shot
tool
that
we
use
the
underlying.
We
like,
where
we
upload
the
images
it
requires
like
a
license
key
or
our
API
key
to
use
now
and
I
think
the
question
was
like
well
what
if
we
just
uploaded
it
to
like
a
github
wiki,
since
it
really
is
just
a
repo
right.
So
this
is
up
for
review.
A
So,
just
to
just
a
like
really
hammer
home,
I
I
think,
instead
of
walking
this
work,
if
we
won't
have
time
for
all
this
well
we'll
try
for
some
like
part
parting
thoughts.
Maybe
ten
so
really
do
question
everything
that
you
see,
there's
a
good
possibility
that
we
haven't
touched
it
yet
or
it's
in
progress
or
it's
in
a
weird
state
of
progress
where
someone
was
on
a
really
seemed
and
they
worked
on
it
and
then
they
stopped
working
on
it.
And
someone
needs
to
pick
it
back
up
again.
A
So,
like
everything
that
you
see
in
a
repo
like
assume
like
a
lot
of
the
documentation,
is
incredible.
A
lot
of
the
tools
are
pretty
awesome,
but
some
of
is
some
of
it
has
not
been
touched
for
for
quite
some
time
and
I
think.
The
reason
is
that
people
did
not
have
the
appropriate
context
to
touch
those
tools
or
the
access
to
test
changes
against
the
things
that
they
were.
They
were
touching.
A
So
please
come
with
questions
like
assume
assume
that
something
is
up
funny
when
you
look
at
a
tool,
if
it's
not
documented,
it's
probably
because
someone
didn't
get
to
it
or
they
didn't
understand
it.
So
ask
questions
about
that
and
let's
have
an
open
forum
about
this
stuff,
because,
like
Tim
and
I,
are
writing
a
talk
for
for
cube
con
and
it's
gonna,
be
all
about
the
release.
Engineering,
tooling
and
I.
Would
love
to
I
would
love
to
give
shout
outs
to
the
people
working
on
it?
A
This
is
a
lot
of
this.
Is
tech
debt
that
we've
kind
of
built
up
across
the
project
for
you,
no
one
since
epoch,
and
probably
more
recently
across
the
last
three
years
or
so
right,
so
I
think
it's
high
time
that
we
we
pay
it
down
and
and
especially
because
it's
you
know,
these
are
the
tools
that
we
depend
on
to
release
kubernetes.
These
are
some
of
the
most
important
tools
in
the
project
and,
and
they
should
be,
they
should
be
high
quality.