►
From YouTube: Kubernetes Release Engineering 20200512
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
Okay,
I'm
starting
the
recording
I'm,
not
gonna,
do
video
because
I'm
slightly
bandwidth,
constrained
and
I
don't
want
to
have
that
conflicting
with
audio,
but
this
is
the
May
12th
cig
release
sub-project
release
engineering
meeting.
This
is
a
kubernetes
community
meeting.
As
always,
we
adhere
to
our
code
of
conduct
and
this
video
recording
will
be
posted
to
youtube
after
the
meeting
so
welcome
everybody.
A
We
have
a
couple
of
things
in
the
agenda.
The
the
biggest
one
that
I
was
hoping
we'd
be
talking
about
today
depends
on
Stephen
and
since
he
hasn't
joined,
maybe
we
can
talk
about
some
some
of
we
move
on
to
the
second
thing.
Nonetheless,
the
other
one
Marquis.
Do
you
want
to
talk
about
status
with
triage
things?
A
B
Good
morning,
everybody
with
triage
party,
they
just
released
the
version
1.0,
so
I
have
tested
that
as
you'll
recall,
when
we
did
the
demo
two
weeks
ago,
the
it
was
really
good,
but
there
was
some
problems
and
some
functionality
was
needed,
so
it
could
work
with
the
KK
repo
that
functionality
has
now
been
put
there.
I've
tested
it
against
the
KK
repo
does
a
lot
better.
B
So
with
that
I
have
set
up
a
meeting
for
this
coming
Friday
myself,
Marco
Veronica.
We
are
going
to
get
together
to
start
to
plan
out
the
tasks
for
getting
this
sort
of
off
the
ground
and
owners
and
see
how
quickly
we
can
get
this
and
put
into
play.
So
look
forward
to
giving
the
next
our
next
meeting,
giving
an
update
with
the
outcome
of
the
this
Friday's
meeting.
That
is
all
I
have
for
that.
A
B
A
The
morale
any
of
us
can
figure
out
pathways
to
reducing
about
the
clogs
and
the
time
to
addressing
issues.
The
sooner
we
we
spot
the
issues
figure
out
how
to
fix
them
before
lots
of
extra
code
has
been
changed.
Additionally,
it's
just
it's
always
easier
to
find
an
issue
and
you
can
be
bisecting
across
a
smaller
amount
of
code,
whether
it's
actual
get
bisector
just
visual
bisection,
just
trying
to
figure
out
what
the
heck
happened.
C
C
A
I
think
well,
maybe
not
quite
that
far
back
but
well
I
don't
know,
but
the
bash
bug
we
dealt
with
in
December
might
have
been
sort
of
2009
vintage.
B
A
D
No
yeah
absolutely
correct
yeah
we
switched
to
bi-weekly,
so
we're
gonna
have
the
next
meeting
on
the
18th.
We're
gonna
skip
the
25th
and
we're
gonna.
Do
it
on
June
1st,
just
to
kind
of
give
everybody
mental
break
everything's
still
proceeding
forward,
but
just
kind
of
still
abiding
by
that
extent
schedule.
But
yeah.
No
news
is
good
news,
at
least
at
least
this
week,
everybody
still
on
track
and
we
or
some
foreign
on
all
fronts
with
the
119
release.
A
A
D
A
He
and
I
talked
a
bit
yesterday
and
maybe
I
guess:
there's
information
there
and
the
links,
but
to
kind
of
give
a
sort
of
intro
level
to
some
of
the
folks
here.
I
feel
like
the
one
of
the
very
first
interactions
I
had
in
cig
release
was
a
bug
saying
that
we
had
si
V's
in
our
Debian
container
image,
and
this.
C
A
A
total
ecosystem
problem
containers
are
built
from
layered
images
and
it's
quite
common
to
have
something.
That's
kind
of
an
operating
system
base
image
at
the
bottom
of
whatever
your
application
is,
there's
all
sorts
of
libraries
and
utilities
and
standard
runtime
sorts
of
things
that
you
might
fall
back
onto
that
are
just
Linux
isms.
So
you
start
out
with
a
handy
base.
A
Maybe
it's
just
a
debian
or
a
bun
to
slim
or
full
hard
to
say
and
anywhere
on
that
spectrum
and
there's
there's
a
ton
of
different
ones,
also,
some
time
back,
maybe
a
year
and
a
half
ago,
I
had
done
a
grep
of
the
source
for
docker
files
and
the
base
tags
within
them,
and
I
came
up
with
like
40
different
ones,
everything
from
Ubuntu
and
Debian
to
fedora
and
Alpine
and
and
other
things
as
well.
And
then
these
were
tricky
because
they're
sort
of
nested.
A
If
you
look
at
some
app
that's
going
based,
it
may
be
based
on
going
image
and
then
that
image
itself
is
based
on
another
one
and
you
get
these
series
of
things.
So
if
you
want
to
get
your
image,
that's
based
on
a
couple
of
other
images,
updated
and
not
have
so
you
v's
in
it,
you
may
have
to
go
through
and
build
a
whole
series
of
other
images
so
that
you
can
effectively
do
like
this
rebasing
action
in
a
way.
A
It's
a
lot
like
you
get
rebase
the
the
net
effect,
except
it's
a
whole
bunch
of
building
of
container
images
and
then
testing
them
and
pushing
them
to
a
repository
from
which
something
else
can
consume
them,
which
requires
its
own
PR
to
change
and
pull
against
the
new
tag,
and
you
have
this
this
whole
ripple
of
many
many
actions
and
right
now
most
of
that
is
manual.
And
for
that
reason,
and
then
just
like
security
being
kind
of
a
constant
treadmill
on
on
any
given
day.
A
If
you
had
to
create
a
simple
test
function
for
is
there
a
new
CVE
in
linux?
You
could
just
return
true,
like
that's
kind
of
the
state
of
things,
we're
always
finding
new
things,
which
means
were
always
releasing
fixes
and
across
something
like
in
a
bun
to
full
image,
there's,
probably
literally
something
every
day.
So
anybody
who
comes
along
and
does
a
security
scan
if
we
haven't
updated
recently,
is
gonna,
find
a
couple
dozen
CBE's
and
say
hey.
A
What
are
you
all
doing
and
in
response
to
that
typically
said,
oh
yeah,
we
ought
to
update
that
and
and
updates
happened,
but
that
was
a
manual
and
a
reactive
process.
So
what
we
want
to
get
to
is
first
bases
that
are
more
tailored
to
the
usage
and
that's
where
a
distro
list
comes
in
instead
of
using
a
full
linux
base,
it
there's
not
a
distro
there
in
the
base,
image
and
you're
you're,
trying
to
only
copy
and
explicitly
the
particular
things
that
your
application
depends
on.
A
So
that
gives
you
a
cleaner
base,
a
smaller
attack
surface,
but
we
also
have
other
things
that
do
necessarily
depend
on
a
little
bit
bigger
system
there
and
the
debian
base
has
been
a
commonly
used
one.
So
for
these
cases
we
need
to
work
on
better
triggers
and
better
automation,
so
that
these
things
can
automatically
flow
and
as
an
example,
if
you,
if
you
think
about
how
prowl
works
right
now,
there's
powers
under
version
control.
A
A
new
version
comes
out
and
it
gets
its
build
pipeline
exercised
and
eventually
that
pops
into
the
actual
test,
M
fro
system
that
we're
running.
So
we
could
potentially
do
something
like
that
where
we
have
a
full
automation,
auto
bumping
things,
it
may
be
something
where
we
have
regular
builds
and
CI
happening,
but
more
careful
inspection
because
proud,
like
the
the
test,
folks
understand
what
they've
changed
in
prowl
and
they're
actively
supporting
it
as
kind
of
one
in
the
same.
A
But
the
set
of
us
who'd
be
possible
for
these
images
and
promoting
them
into
production
usage.
We're
not
subject
matter
experts
on
everything
that
is
Debian
or
everything
that
is
a
bun
or
everything
that
is
Linux
across
any
and
all
operating
system
images
from
any
of
the
districts
that
might
happen
to
be
a
new
somewhere
in
our
yuko
system.
A
So
we
do
need
to
be
a
little
more
tentative,
probably
and
figure
out
what
the
test
plan
is
and
how
we
we
automate,
builds,
but
also
automate
quality
assurance
and
then
figure
out
what
the
right
level
of
risk
mitigation
is.
Before
we
promote
things,
there
might
be
scenarios
where
we
simply
Auto
promote.
There
might
be
others
where
we
want
a
human
to
kind
of
look
at,
and
then
we
also
have
some
questions
around.
A
How
do
we
version
this
at
the
at
the
level
of
our
image
tags?
We
would
like
them
to
have
silver
but
Linux
as
a
whole,
like
the
entire
universe
of
open
source
packages
that
compromise
Linux's
in
general.
Those
aren't
together
under
semantic
versioning.
How
do
we
know
when
something
major
has
change?
That's
gonna
break
something
and
probably
I'm
inclined
to
think.
We
can't
like
that.
That's
where
the
kind
of
test
plan
and
and
figuring
out
how
we
pragmatically
start
to
use
something.
A
There's
gonna
always
be
some
level
of
test
and
prod,
but
that
we
don't
just
automatically
push
things
and
months
later
realize.
Oh,
this
weird
issue
is
coming
from
that
push
way
back
then,
because
packaged
food
doesn't
strictly
control
its
versioning
and
we
pulled
in
something
that's
had
a
major
change
and
is
not
compatible
with
what
our
prior
assumptions
were.
So
this
is
a
pretty
interesting
space.
I
think
there's
some
technically
hard
problems
around
building
test
and
release
here
that
we
need
to
figure
out
how
to
improve
the
automation
around
and
some
interesting
work
has
happened.
D
C
A
A
That's
gonna
need
some
some
attention
to
make
sure
it
doesn't
just
kind
of
melt
down,
so
I
would
say,
like
we
have
too
few
cubes
in
the
kitchen,
but
we
need
to
get
a
little
bit
more
documentation
down
and
a
little
more
a
little
more
practice
so
that
we
can
sustain
getting
more
cubes
in
the
kitchen.
Does
that
make
sense.
C
I
just
know
that
I
deal
with
this
in
a
pretty
regular
basis
where
images
have
CBE's,
where
you
know
the
core
functionality
of
the
container
is
not
impact,
but
you
know
given
security,
etc,
etc.
You
have
to
patch
this,
and
so
it's
kind
of
a
pain
that
I've
been
living
in
so
just
looking
to
see
if
I
could
help
out
at
all.
A
Yeah,
definitely,
and
that
that's
like
one
of
the
things
that
I've
been
looking
for,
is
more
people
who
have
experienced
some
of
this
get
ups
or
DevOps
level
pain,
that's
specific
to
containers
and
base
image.
Tvs
has
kind
of
been
an
emerging
space
the
last
while
people
are
starting
to
get
it
more.
So
any
of
you
all,
who've
lived
it
I
guess
I
would
say
at
this
point,
reach
out
to
Steven
and
say,
like
hey,
I've
lived
this
a
bunch.
I've
got
a
fair
amount
of
experience.
B
E
Yeah
I
mean
also
last
week.
Marquis
was
in
charge
of
cutting
the
release
and
we
were
getting
educated
on
all
that
by
the
way
thanks
a
lot
Carlos
because
he
has
been
a
star
helping
us
get
through
everything,
figuring
out
everything
that
we
need
to
know
so
yeah.
Even
if
we
don't
have
a
lot
of
updates
visible
updates
like
we
have
been
super
busy
in
the
backstage,
and
hopefully
as
Marquis
said
after
our
meeting
this
Friday,
we
will
be
able
to
be.
We
will
be
able
to
share
more
thing.
E
A
Okay,
well,
let's
go
ahead
and
call
it.
We
will
have
our
regular
cig
meeting
next
week,
I'm
curious
to
hear
some
of
the
updates
on
some
of
this
stuff
and
then
obviously
the
release
engineering
will
next
will
be
next
in
two
weeks,
so
I'll
get
this
uploaded
to
YouTube.
Thanks
for
dropping
your
names
in
the
notes
for
those
who
did
anybody?
Who
didn't
do
that?