►
From YouTube: Kubernetes SIG Release Meeting 20190129
A
A
B
A
Jotting
names
down
and
organizing
savvy
I
apologize,
I
thought
you
are
a
different
s,
initial
and
sorry
about
that.
So
this
is
the
sig
release.
Meeting
for
January
29th,
it
is
already
meeting,
is
recorded,
as
with
all
of
our
community
meetings.
We
ask
that
you
adhere
to
the
code
of
conducts
and
be
good
people
to
each
other
for
the
duration
of
the
meeting.
If
not
always,
we
have
a
relatively
sparse
agenda
this
week.
A
So
if
there
are
things
that
you
want
to
talk
about,
feel
free
to
drop
them
in
the
agenda,
otherwise
I'll
kind
of
go
through
the
couple
of
things
that
have
been
jotted
in
there.
So
far,
I
don't
believe
caleb
is
around
today
and
steven
augustus
is
traveling
today.
So
we
we
have
a
smaller
group
in
terms
of
coordinating
what
could
be
on
the
agenda,
but
obviously
it's
a
conversation
open
to
all.
So
the
the
first
thing
I
wanted
to
call
out
is
our
sub
project.
So
last
week
Steven
merged
PR.
A
So
basically,
Ana's
Horrell
had
been
looking
at
things
from
the
the
branch
manager
perspective.
How
we
could
improve
things
and
in
parallel
to
that
said,
cluster
lifecycle,
because,
especially
like
the
cube
ATM
tool,
it
consumes
these
dubs
and
rpms.
They
were
looking
at
some
improvements
and
there
may
be
sort
of
parallel
tracks
there.
So
Hannes
was
proposing
I
kept.
A
That
I
think
is
a
useful
thing
to
have
to
articulate
like
what
we
do
and
why,
in
the
big
picture,
where
said
cluster
lifecycle
is
doing
some,
maybe
more
tactical
actions
that
improve
the
situation
for
them,
and
we
need
to
balance
that
so
closer
life
cycles,
looking
at
things
on
the
build
side,
but
then
there's
the
whole
publication
and
hosting
side
and
then
also
we're
on
the
hook
for
signing
of
those
packages
as
well.
So
there's
a
lot
of
things
that
fall
under
our
domain
aren't
formally
specified
just
yet
and
I.
A
C
No
I,
as
far
as
I
know,
there
was
nothing
happening
this
week.
I
didn't
have
as
much
time
I
hoped
to
work
on
that,
so
my
takeaway
is
for
now
sick
luster
life
cycle
is
checking
on
the
building.
Part
and
I
will
try
to
check
on
the
like
publishing
and
releasing
part
with
the
people
inside
Google
who
are
currently
doing
that.
C
Another
thing
I
want
to
do
is
incorporate
all
the
comments
that
we've
got
already
on
the
first
cap,
which
is
basically
only
handling
the
building
side
of
things
and
then
see
how
we
can
if
we
want
to
create
a
second
cap
for
the
publishing
I
know,
there
is
already
one
I
think
right
now
there
are
like
three
caps
floating
around
and
I
want
to
I.
Don't
know,
merge
them
to
some
extent,
maybe
into
one
cap
or
just
cross-linking
them,
but
yeah
I,
hope
to
to
start
working
on
that.
The
next
days
I
feel.
A
Like
one
of
the
things
accumulate
meeting
last
week,
resistance,
multiple
people
felt
it
would
be
better
if
the
things
were
just
left
separate
but
I
feel
like
it
would
be
better
to
have
a
single
point
of
information
on
the
overall
flow,
even
if
the
sub
parts
of
it
end
up
owned
or
driven
by
different
people
that
the
split,
especially
with
the
three
different
things
in
flight
and
tons
of
issues,
and
then
also
the
workgroup
gates,
and
for
a
like
that,
there's
just
it's
it's
too
fuzzy.
It
feels
like
I
like.
A
C
Right
now,
I
think
we
might
keep
it
separate
and
hash
them
out
individually
and
merge
them
eventually
or
like
having
a
I,
don't
know
an
umbrella
cap
or
something
but
I
guess
that's
details
and
we
will
see
how
it
goes
when
we
start
hashing
out
the
individual
caps
as
they
stand
right
now.
That
would
be
my
my
approach
that.
A
A
A
We
also
need
to
understand
how
much
sort
of
organizational
ability
within
the
sig
and
the
set
of
volunteers
and
folks
we
have
present
to
actually
take
on
tasks
and
do
things
so
that
we
get
things
done
so,
if
weather
release
engineering
or
the
the
bigger
list
of
things
that
we
think
we're
responsible
for.
Is
this
a
if
you're
on
the
call
and
you
those
things
call
out
to
you:
I'd,
encourage
you
to
get
involved
both
in
the
definition
phase
and
then,
as
we
transition
those
things
into
actual
specific
issues
and
are
implementing
things.
B
A
Okay,
I'm
gonna,
move
on
to
the
next
one
then
I
feel
like
this
is
semi-related
on
google
Summer
of
Code
folks
have
sent
out
a
call
and
they're
looking
for
four
topics.
I
feel
like
in
a
way
there's
this
general
space
of
release.
Engineering
there's
bound
to
be
some
some
tools,
the
development
of
which
would
be
constrained
enough
for
an
intern
to
possibly
contribute
to,
as
opposed
to
some
massive
kept,
but
within
there
might
be
some
point
tools
that
people
could
work
on.
A
D
Well,
so
I
have
some
money
for
outreach,
II,
the
and
so
I
was
looking
at
having
an
outreach
e
putting
up.
You
know
an
ad
for
not
reaching
intern
for
either
spring
or
summer
that
probably
to
work
on
some
of
these
tests.
Infra
visibility,
issues
that
we
know
that
are
out
there
areas
where
we
would
like
to
have
an
interface
or
a
tool
to
make
some
things
more
visible
like
right
now
you
know
the
you
know
whether
it's
flakiness
or
better.
D
You
know
less
confusing
visibility
for
analyzing
test
failures,
or
you
know
something
else,
but
I'm
also
looking
for
other
ideas
in
that
area,
I
think,
certainly
if
we
can
do
some
things
that
are
related
to
visualization,
that
would
help
us
have
a
better
pool
of
candidates
because
stuff
related
to,
for
example,
packaging
and
builds,
etc.
I've
found
it's
harder
to
find
students
and
other
folks
as
candidates,
just
because
there's
just
not
as
much
of
a
pool
of
people
who
learn
that
kind
of
thing.
D
If
you
follow
me,
it's
more
mm-hmm,
it's
more
of
an
on-the-job
experience
thing.
To
put
it
another
way,
like
I,
don't
I,
don't
know
any
college
class
that
teaches
software
packaging.
A
This
is
very
true
and
I
guess
they're
in
my
mind,
part
of
it
comes
down
to
having
a
well
enough
SPECT,
deliverable
and
the
extent
to
which
of
the
mentor
for
the
project
would
be
able
to
commit
time,
be
hands
on
that
sort
of
stuff
to
kind
of
lead
and
guide
the
project
versus
them,
getting
something
more
general
and
just
diving
in
and
being
able
to
deliver.
I
guess,
yeah.
D
B
E
D
Well,
do
you
want
to
work
together
in
this
enchant?
Yes,
I
mean
this
will
cover
both
GSoC
and
outreach
e,
depending
on
who
we
get.
We
can
honestly
have
for
some
kinds
of
projects
we
can
have
the
same
project
on
both
I
mean
the
basic
ideas
that
are
not
reaching
interns
should
do
two
to
three
times
as
much
as
a
GSoC
intern.
The
GC
projects
would
be
like,
let's
take
a
larger
idea
and
break
it
down
into
some.
Individual
components
are
also
proposed.
Those
for
GSoC
yeah.
E
I've
been
here
I
would
I
did
Summer
of
Code
was
the
first
time.
I
touched
the
cover,
dance
project
and
I
really
liked
it.
Wasn't
there
so
I've
been
talking
to
release
and
testing
and
life
cycle
and
things
trying
to
find
something
that
fits
that
scope
proposed,
but
I
haven't
said.
Oh,
let
me
think
it.
B
Was
one
project
there
I
talked
about
a
little
bit,
but
you
know
I
guess
I've
mentioned
it,
so
it
would
be
nice
to
get
someone
to
actually
automate
those
grow,
novo
signal
reports
and
maybe
add
some
visualization
there
to
see
how
we're
burning
down
on
those
over
the
days.
Maybe
do
some
experimentation,
there's
maybe
testing
as
to
if
the
format
changes
whether
the
rate
of
you
know.
D
B
Drops
off
work
we're
not,
but
you
know
a
some
some
code
that
we
could.
You
know
run
to
play
around
with
these
questions,
but
is
the
most
effective
way
of
this
information
and
what
we
do
have
both
the
the
air
table
stuff
that
Jack
worked
on
and
the
go-signal
reports
that
Dan
and
I
worked
on
for
one
six.
What.
B
A
That
is
another
aspect
of
this.
A
lot
of
the
things
that
we're
talking
about
improving
and
I
know
Aaron's,
not
on
the
call
today,
but
looking
at
114
and,
like
he's
he's
really
trying
to
drive
people
to
think
about
what
can
we
do
this
cycle
and
summer
is
a
ways
away,
so
we
we
do
need
to
be
mindful
of
that
sort
of
event
horizon
that
we
don't
have
a
bunch
of
awesome
ideas
that
we
all
get
implemented
in
the
meantime,
yeah.
D
Yeah,
one
of
the
challenges
for
Summer
of
Code
is
going
to
be
that
the
Summer
of
Code
projects
are
supposed
to
be
more
sort
of
specifically
defined
and
concretely
defined,
and
so
it
means
that
you
have
to
have
something
that
you
actually
want.
That's
the
appropriate
amount
of
work
and
that
you
know
nobody
else
is
going
to
work
on
between
the
time
that
you
write
it
up
in
early
March
or
where,
whenever
and
the
time
that
the
project
actually
starts
in
June.
D
B
A
So
one
thing
you
mentioned
that
reminds
me
of
one
of
the
things
that
I
was
curious
about
and
I'm
wondering,
if
maybe
my
karpea
has
slots
on
the
the
aspect
of
the
release
notes
around
dependencies,
and
that
listing
is
something
that
feels
like
it
could
be
a
project
size
cleanup
to
make
something
more
machine,
readable
and
managed
in
a
way,
that's
consumable
by
a
tool.
Yeah.
E
I
think
for
sure,
that
and
I
would
also
love
to
see
some
of
the
existing
tooling
that
we
have
released.
That's
written,
perhaps
broken
up.
It's
like
go
library,
code
and
tested
and
integrated
into
like
seem
more
kind
of
build
infrastructure.
That's
more
consistent
with
like
like
how
testing
for
works
and
stuff
like
that.
So
I
think
there's
a
few
little
like
UL
scoped
projects
with
some
of
the
branch
manager,
tooling
and
Lily
Smith's
to
him
and
I
would
be
for
sure,
happy
to
purchase
it
and
brainstorming.
Some
of
those.
A
B
C
E
Yeah
I
mean
I
just
know
that
I
remember
like
two
releases
ago.
There
were
some
bugs
with
like
the
release,
notes,
shell
spirit
and
or
the
rel
notes.
Rather
shell
script,
and
it
was
just
really
challenging
to
like-
not
only
extend
it
but
to
like
write
a
test
to
assert
that
a
certain
like
subsection
of
the
functionality
of
the
tool
was
like
doing
what
we
expected
it
to
be
doing
stuff.
So
it
was
just
one
to
being
really
challenging
and
doing
like
a
good
luck.
E
Finding
the
you
know
the
key
30
lines
of
code,
rewriting
it
as
a
testable
like
pure
function
and
go
writing
the
test,
made
everything
a
lot
easier.
So
well,
you
know
just
hitting
a
pure
rewrite.
I,
don't
know
if
his
super
necessary
or
super
awesome
use
of
time,
but
I
do
feel
strongly
that
a
whole
not
in
the
bash.
It
does
not
like
lay
the
foundation
for
long-term,
productive
software
engineering
objectives.
B
B
D
E
But,
even
just
from,
like
a
maintenance
perspective,
the
code
that
is
in
kubernetes
slash
release
as
well
as
some
of
the
things
that
are
in
like
the
builded
hack
directory
in
kubernetes,
can
be
very
challenging
to
even
determine
what
it
doesn't.
How,
because
of
things
like
implicitly,
depending
on
environment
variables
across
scripts,
which
are
not
documented,
and
that
sort
of
thing
can
be
made
a
lot
better
with
the
who
needs
to
clean
up
or
a
rewrite
pass.
E
B
B
Kubernetes
I
feel
like
there's
more
work,
to
define
what
the
actual
problem
statement
that
this
group
is
supposed
to
be
working
on
before
we
get
to
working
on
or
modifying
the
tools
because
they
act
like
it's,
be
technical
challenges,
scraped
PR
like
or
release
notes
from
one
to
ten
thousand
or
requests
that
itself
says
practice
on
a
wealth,
scope
problem
if
you
invest
or
to
maintain
code
to
work
on.
If
the
actual
problem
is
like,
you
know,
for
these
thirty
enhancements
or
20
or
ten.
B
E
But
I
mean
I
guess
one
of
the
problems
that
we
have
now
is
that,
despite
endeavoring
to
focus
on
the
problems
is
like.
We
do
have
this
mountain
of
Bosch
that
we
have
to
reason
about
maintaining
on
a
release,
to
release
phases
and
stuff
like
that.
So,
while
even
the
problems
that
the
current
tooling
we
have
may
may
not
be
so
well
defined,
we
do
still
have
the
problem
of
maintaining
me,
perhaps
not
so
well
defined
solutions
as
well
from.
A
A
maintenance
perspective,
one
of
the
things
that
I
think
I,
hear
two
things
being
described
there,
one
just
like
fragility
maintenance,
but
also
like
long-term
sustainability
of
the
project.
Do
we
have
enough
people
able
to
contribute,
but
I
feel
like
one
particular
benefit,
one
of
the
things
that
I
really
like
about
go
personally.
Is
that
there's
a
built
in
assumption
that
you're
gonna
write
unit
tests
and
for
all
the
bash
scripts
we
have
their
their
testability
and
understanding
whether
they
work
as
intended.
It
is
a
big
gap.
A
B
D
D
B
B
B
E
Circle
there's
something
else
to
be
said
for
whether
or
not
you
think
a
tool
is
good
or
not,
and
and
I've
looked
at
this
for
some
projects
that
I
created
in
this
ecosystem
that
moving
things
to
go
means
that
more
of
the
existing
contributors
to
other
parts
of
the
ecosystem
are
going
to
be
familiar
with.
It.
A
D
A
E
E
E
D
So
we
don't
actually
have
to
come
up
necessarily
even
with
three
ideas
ourselves.
We
just
need
to
come
up
with
one
or
two
of
them.
The
thing
is
what
the
students
actually
do
can
be
something
different.
It's
just
that
Google
won't
accept
us
if
we
don't
have-
and
you
know
as
a
project
if
we
don't
have
at
least
three
solid
potential
project
examples,
because
there
our
attitude
is,
if
you
can't
come
up
with
at
least
three
examples,
then
you're
not
going
to
be
ready
to
mentor
anyone.
A
D
A
A
A
A
Otherwise,
if
somebody
wants
to
like
sort
of
co-present
or
like
get
a
softer
introduction
to
presenting
happy
to
do
that
with
anybody,
who's
interested
and
then
deep
dive
topic,
should
we
do
a
deep
dive
for
Cuba
Connie,
you
I
would
tend
to
say
yes
just
because,
like
I
mean
Joshua's
I'm
saying
maybe
not
do
a
deep
dive
in
Shanghai.
If,
if
Cuba
Connie,
you
in
North
America
are
sort
of
booked
in
six
months,
ish
apart,
that
have
a
critical
mass
of
attendance,
we
feel
like.
D
A
A
D
A
A
A
D
Well,
I'll
be
there,
so
I
could
definitely
do
the
intro.
Yes,
if
there's
name
buddy
else,
I
mean
I'm
already
doing
several
other
things
for
Shanghai.
So
if
there's
somebody
else
who's
going
to
Shanghai
and
doesn't
have
time
on
stage,
it
would
be
better
for
them
to
run
the
intro.
But
if
we
don't
have
anybody
else,
it's
easy
enough
for
me
to
do.
A
Yeah
so
again,
opportunity
for
somebody
newer
to
to
get
some
some
presence
and
visibility
out
there
and
something
good
for
your
your
resume,
I
guess
or.
A
A
A
C
E
E
That's
a
bit
of
a
mess
because
it's
from
here
on
it,
but
that
only
dropped
the
issue
there
we
go.
That
should
be
the
tip
I
was
thinking
of
it
was
initially
targeted
at
another
sink
as
sort
of
just
a
proxy
and
more
so
being
hugged
by
that
workgroup.
But
there's
some
discussion
about,
probably
you
know
Singh's
own
things,
and
this
seems
like
the
signal
it.
A
A
Yeah
I
feel
like
this
is
I
was
surprised
that
it
was
initially
proposed
as
contributor
experience.
Oh
and
I
see
I'm
Steven
I
I've
seen
this
one
going
by
my
email
that
haven't
kept
up
with
all
of
the
notifications
on
it
but
yeah,
but
it
feels
like
we
are
the
natural
place
for
that
and
it
dovetails
with
the
stuff
that
Ana's
was
trying
to
to
get
a
better
handle
on
I
brought.
A
Oh,
and
we
did
so
Lina
saw
our
on
the
line
our
on
the
on
the
call
on
he
had
presented
at
the
community
meeting
week
before
last.
I
feel
like
something
something
along
those
lines
about
a
container
image
for
motor
tool
and
he's
noting
that
he's
submitted
a
CFP
for
to
talk
about
that
in
Barcelona,
so
yeah
that
that
would
also
be
something
interesting
if,
for
some
reason
it
didn't
get
selected,
it
might
be
something
that
dovetails
were
kind
of
talking
about
this
release.
Engineering,
space
and
changes
that
are
coming
for
improvements.
A
So
I
guess
the
the
one
thing
we
just
need
to
decide
so
that
we
submit
something
by
the
end
of
next
week.
So
I
will
I
will
follow
up.
I
can
definitely
submit
an
intro
one,
and
if
somebody
wants
to
co-present
on
that,
let
me
know
we
can
hash
out
an
idea
on
the
deep
dive
on
slack
and
get
something
submitted
and
then
I'm
Josh.
A
Do
you
want
to
I'm
not
sure
that
the
see
if
the
the
stuff
for
workgroups
and
SIG's
has
opened
yet
for
Shanghai,
but
can
I
just
trust
like
note
that
you're
you're
going
to
submit
for
enter
there?
Okay,
all
right?
Well,
if
there's
nothing
else,
anybody
wants
to
chat
about.
We
can
call
it
a
day.
Call
it
a
meeting
anyway
for
the
day.