►
From YouTube: Kubernetes SIG Release - 2019-05-07
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
A
C
A
All
right,
let's
get
rolling
for
those
who
are
on
the
call,
feel
free
to
pop
your
names
into
the
Google
Doc
I.
Just
put
that
in
the
chat,
hello,
hello,
everyone
welcome
to
the
May
7th
edition
of
cig
release.
This
is
a
meeting
that
is
recorded
and
posted
on
YouTube.
So
please
be
mindful
of
what
you
say:
please
a
be
sure
to
adhere
to
the
German
Andes
code
of
conduct,
so
we
don't
have
we've
got
kind
of
a
short
agenda
today.
A
The
first
thing
I
wanted
to
talk
about
was
project
boards,
so
I
have
combed
through
some
of
the
sig
release
backlog
and
done
a
soft
prioritization
of
some
of
the
open
tasks
that
we
have
right
now.
I
will
say
that
it
is
quite
a
bit.
We
do
have
quite
a
bit
on
the
backlog,
so
any
sub
project
owner
release,
team
member
release,
engineering
licensing
sub
project
I
want
to
request
that
you
work
on
making
sure
that
your
backlog
is
up
to
date
and
start
to
actively
groom
the
tasks
that
are
in
your
project
board.
A
For
each
of
your
meetings.
Right
so
you'll
see
that
there
are
four
project
boards
there
there's
a
top-level
sig
release,
project
board,
release
team
project
board,
a
release,
engineering,
one
and
a
licensing
one,
so
licensing
wise.
We're
also
going
to
start
our
licensing
sub
project
meetings
this
week,
I
believe
Friday.
A
It
looks
like
the
best
day
for
the
doodle
initially
I
want
to
make
sure
that
it's
a
meeting
that
myself
Nikita,
dims
and
Steve
Winslow
can
attend
and
then
moving
forward,
I
think
after
cube
con,
we
can
shift
the
schedule
to
make
it
more
convenient
for
for
everyone.
So
if
you
have
interest
in
how
we
handle
licensing
scanning
all
that
good
stuff
on
the
project
and
then
remediate
remediate,
those
things
feel
free
to
join
those
meetings,
I'll
be
sending
them
a
meeting,
invite
out
to
the
mailing
list
a
little
later
in
the
day.
B
A
A
There
have
been
a
variety
of
discussions
around
how
we
do
issue
triage
and
that
kind
of
leads
into
like
why
we
start
needing
like
why
we
need
project
boards,
so
Niko
has
been
working
as
a
bug,
triage,
lead
and
shadows
for
previous
release
cycles
and
he's
kind
of
collated,
a
lot
of
the
notes
that
he's
found
based
on
working
through
that
process
and
working
through
updates
to
the
handbooks.
So
please
take
a
look
at
the
some
of
the
ideas
that
he
has.
I.
A
Think
that
one
of
the
immediate
things
that
we
can
action
on
is
the
adding
the
needs,
sig
triage
automation
to
kubernetes
kubernetes
issues,
so
that
would
basically
add
a
new
label
to
the
currently
open
issues
and
new
issues
that
would
be
need
cig,
triage
right.
So
essentially
the
idea,
if
you
click
the
second,
the
second
link.
In
that
note
it
kind
of
goes
through
the
workflow.
A
So
essentially
a
a
PR.
Would
get
opened
tagged
as
needs
sig
and
needs
sig
triage
needs.
Sega
already
happens
today.
Needs
sig
triage
would
give
a
little
signal
to
vi
who
are
trying
to
work
through
their
backlog
of
what
needs
to
be
what
needs
to
be
triage
next
and
then
we're
going
to
be
looking
at
we
as
in
I
think
we
as
a
community
but
more
specifically,
I,
guess
the
we
is
a
p.m.
and
contributor
experience,
you're
going
to
be
looking
at
adding
our
are
essentially
rhe
categorizing
the
the
triage
labels.
A
B
That
I'd
worry
about
and
the
I
think
this
is
on
the
contra
Beck's
mailing
list.
There
is
the
discussion
there
that
led
to
this
issue
and
the
the
proposed
workflow,
if
feels
gapi
is
one
sig
looks
at
something
and
triage.
Is
it
and
maybe
hands
it
off
to
another
sig?
And
this
came
up
today,
the
release
team
was
talking
about
how
they're,
trying
to
pull
together
release
notes
a
little
more
clearly
and
one
of
the
things
that
they'd
struggled
with
is
when
things
have
multiple
SIG's
listed
as
the
owning
right
like
who's,
the
real.
B
So,
yes,
your
sig
is
labeled
because
it's
relevant
but
you're
passing
it
off
to
somebody,
and
my
worry
was
that
that
ends
up
having
like
a
need:
sig
star,
triage
family
of
labels
or
something,
and
even
just
the
suggestion
of
adding
primary
sig
already.
It
feels
there's
a
slippery
slope
here
and
I'm,
not
sure
that
it
solves
the
situation,
adding
more
labels.
Yeah.
A
I,
don't
think
primary
sig
or
multiple
SIG's
is
the
right
direction.
I
think
that
it's
I
think
that
you
know
if
we
have
the
opportunity
to
triage
something
like
this.
This
is
I
think
this
is
an
inherent
of
a
problem
that,
like
we're
not
doing
we're
not
doing
enough
triage
right,
so
I
think
that
anyone
who
does
grab
it
I
think
it's
first
dibs
if
they
decide
that
it
doesn't
belong
to
their
sig
or
they
decide
that
the
owning
sig
should
be
something
else.
A
Then
then
we
can
look
at
relabeling
or
something
like
that,
but
I
think
just
putting
this
label
in
place
will
allow
SIG's
to
get
some
sort
of
signal.
Out
of
you
know,
out
of
the
backlog
right,
this
is
you
know
this
is
also
you
know
the
this
is
also
assuming
that
someone
who
comes
along
and
does
that
initial
either
the
creation
of
the
the
issue
or
the
initial
like
soft
prioritization
of
the
thing
right
can
determine
what
it
is
right.
So
if.
B
A
A
B
A
Where
it
stands
so,
I
think
that
you
know
part
of
it
is
like
definitely
separating
between
the
issues
and
the
PRS
themselves.
Right
because,
like
with
PRS,
we
have
the
opportunity
to
auto
label
the
PRS,
based
on
the
code
that
they're
touching
right,
whereas
for
the
issues
were
we're
almost
like,
depending
on
either
the
issue
filer
or
someone
who
does
that
initial
prioritization
initial
triage
to
determine?
Let's
say
it
belongs
to
you.
That's.
B
Fair
I
guess,
on
the
PR
side,
SIG's
are
gonna,
be
labeled
based
on
owners
files
and
we're
I'm
trying
to
understand
who
has
and
who
hasn't
looked
the
situation.
Brow
is
kind
of
giving
me
some
hints
on
that
in
the
comments,
and
then
it
also,
if
it's
an
issue,
it
doesn't
matter
so
much.
Maybe
that
is
like
it
bounces
around
until
somebody
until
if
it
should
converge
at
ten
point
at.
D
We
have
a
separate
repo,
though
it's
none
of
the
main
okay,
because
we
have
a
Senate
repo.
It's
it's
visible
for
us
to
easily
do
that,
then
everything
that
gets
PR
in
because
the
they
will
supplied
through
the
owners
files,
I'm
gonna,
find
that
way.
So
from
an
issue
perspective,
it's
a
non-issue
because
we
have
a
separate
repo
and
every
six
months
or
so
we
go
through
we
combed
through
KK,
for
anybody
who
filed
Canadian
things.
We
closed
them
all
out.
Earth
force
them
to
be
refiled
or
cross-reference,
but
we
did
actually.
A
Get
straight
for
the
Kyuubi
idea:
Mary,
but
repo
right
or
cluster
API
or
somesuch
yeah.
That's
that's
a
good
point.
So
I
think
I
had
mentioned
it
on
the
on
the
PM
meeting
earlier
today,
but
not
here
and
where
were
Addis,
we've
got.
We've
got
a
lot
of
issues
to
burn
through
and
a
lot
in,
safaris
like
there
were
about
60.
A
That
I
was
aware
of
between
between
the
release
and
the
cig
release,
repos
and
that
I
know
are
in
some
state
of
activity
and
then
60
to
70
more
within
within
kubernetes
kubernetes
that
a
lot
a
lot
of
which
I
have
not
seen
before
right.
So
this
is
like
a
real
real
problem,
so
I
want
I
really
do
want.
A
All
right,
well,
I'm,
not
sure
who
all
is
going
to
Barcelona,
but
be
aware
that
we
have
two
sessions
in
Barcelona
well,
technically,
three
sessions
and
we
have
the
release
team
meeting
during
the
contributor
summit.
That's
the
morning
session
and
then
the
the
intro,
the
cig
release,
intro,
which
will
be
I,
believe
Tim
and
Clare
doing
a
rundown
of
the
release
team
and
then
a
deep
dive
session,
which
will
be
myself
and
Tim
doing
a
rundown
of
police
engineering
and
the
evolution
of
release
engineering
for
sake
release.
So.
A
D
B
In
more
concrete
terms,
I've
got
it
to
do
to
create
a
backlog
for
the
release,
engineering,
sub
project,
specific
actions
and
things
in
conjunction
with
the
worst
working
group
on
infra.
At
this
point,
then,
first
of
has
been
slow
enough.
That
I
want
to
just
kind
of
decouple
from
that
for
the
time
being,
just
if
it's
a
pipeline
of
individual
tools
that
do
their
parts
eventually,
the
pipeline
will
land
on
the
formal
infrastructure,
but
we
can
start
proving
out
the
individual
parts
as
unique
components
in
the
meantime,
without
that,
so.
A
Tim
there
is
already
a
project
board
for
release
engineering
I
think
we
should
at
some
point
sit
down
and
one
get
a
an
official
meeting
scheduled
are
tagged
on
to
tag
onto
the
k10
for
team
meetings
and
see
if
we
can
push
it
push
it
that
way,
but
yeah
we
should.
We
should
sit
down
at
least
together
and
and
do
a
prioritization
of
some
of
those
tasks.
B
What
are
the
things?
That's
been
a
bit
murky
since
you're,
here,
Tim
and
and
some
of
the
others
on
the
call
initially,
as
this
was
being
discussed
months
ago,
I
feel
like
we
kind
of
split
in
what
felt
maybe
at
the
time
is
natural,
but
I'm
not
sure
it
is
natural
versus
unnatural,
a
distinction
between
publishing
falling
to
the
Cystic
release
and
release
engineering
and
packaging
falling
to
cluster
lifecycle.
D
B
D
We're
already
mean
Travis
has
already
started
to
work
on
the
knees
here,
so
I
ready
to
talk
with
him.
There
are
other
people
that
were
working
on
it
from
SUSE
and
Travis
is
currently
tasked
with
working
on
some
of
this
stuff.
So
the
initial
idea
is
to
port
over
a
good
chunk
of
what
is
currently
in
the
released
repository
for
the
canonical
pieces,
but
then
we're
going
to
modify
some
of
the
Basel
isms
that
Curley
exists
to
get
them
out
of
the
way
and
put
it
in
the
wreath
and
built
directory.
D
The
way
it's
currently
done
in
KK
is
a
little
over
Baz
alized
for
everyone's
liking.
It
does
this
massive
generation
stuff
and
that's
too
much
so,
which
is
simplifying
it
and
there's
three
parts
to
this
whole
process.
That's
the
first
part!
Well,
no
one
second,
actually
wrote
it
down
earlier
today.
What
the
second
part
was.
My
brain
is
oatmeal
right
now,
I.
C
Have
kind
of
a
question
around
this,
especially
Tim,
since
you
said
you
don't
care
if
SEL
or
did
say,
cluster
lifecycle
owns
it.
So
I
want
to
make
sure
that
I'm
active
in
the
right
area-
and
you
know
after
we
gather
requirements
all
that
kind
of
stuff.
Where
should
I
be
vocal
and
making
sure
people
see
what
we're
proposing
and
how
to
do
it
so
that
the
right
eyes
land
on
it
and
who
has
ownership
of
it.
D
Will
probably
be
in
the
owners
files
for
sure
I.
Think
it'll
be
like
just
like
everything
else.
In
KK
motors
files
are
the
curation
people
who
work
on
the
stuff
and
people
who've
actively
been
engaged
in
it.
So
I
think
if
the
owners
file
is
populated
with
the
cross-functional
group
of
people
in
sick,
less
relaxed,
I
call
another
release.
Team
I
think
that's
perfect,
that's
what
it
should
be.
A
B
A
A
Yeah
I
was
figuring.
We
can
do
an
in-person
sync
or
something,
but
let's
plan
to
start
do
those
meetings
the
week
after
cube
con.
It's
not
the
week
after
that.
So
everyone's
kind
of
like
settled
back
down
I,
know
I,
know,
Tim
and
I
are
definitely
like
under
the
gun
to
put
together,
slides
and
all
that
good
stuff,
so
and
I.
Think
at
this
point
we
can.
A
We
can
consolidate
some
of
the
caps
that
are
floating
around
between
SEO
and
and
and
release
and
I.
Think
there's
a
plan
for
like
an
omni
cap
to
describe
all
the
stuff,
because
right
now
it's
broken
down
into
individual
pieces
which
I
think
it
does
need
to
be.
But
there
needs
to
be
another
cap
describing
the
overall
vision.
A
B
Other
thing
that
I
think
is
missing.
Tim
from
your
three
phases,
the
those
three
steps
are
focused
very
much
on
mechanism
and,
while
the
mechanism
here
is
quite
poor,
has
a
lot
of
room
for
improvement,
the
mechanism
choices
do
need
to
support
specific
types
of
policy,
and
we
haven't
had
a
lot
of
discussion
on
the
policy
side
of
things
as
well.
B
B
D
Standard
policy
for
packaging,
with
pen
diversion
associated
with
the
release.
They
sometimes
have
denigrate
capabilities,
but
the
best
practice
is
always
to
pin,
because
that's
the
one
that's
been
vetted
and
that's
the
only
thing
we
actually
do
with
kicking
so
I,
don't
think
we
can
actually
have
anything
other
than
that.
The
only
reason
why
we
do
anything
different
is
because
of
our
your
unit,
repo
inside
of
our
release
mechanism,.
B
And
if
we're
lucky,
I
am
the
symptoms
of
the
problems
we've
had
on
the
client
side
consuming
the
packages
have
been
very
surprising
to
me.
I
do
think
it's
likely
that
those
are
primarily
caused
by
the
weird
layout
of
the
contents
within
our
server-side
repositories,
but
I'm,
not
convinced
by
that
so
I
I
think
we
need
to
do
some
experimentation
to
validate
that.
It's.
D
Questions
for
us,
which
I
don't
know
the
answer
to,
would
it
be,
instead
of
us
actually
hosting
these
things
on
our
own
infrared,
there's
plenty
of
hosting
services
to
do
multi
package
things
like
CN
CF
is
loaded
with
cash
like,
and
we
we
have
this
weird
tendency
to
like
build
our
own
infra
for
infrasonic.
D
B
Yeah,
so
I've
presume
that
part
of
solving
this
on
our
side
is
for
us
to
declare
what
our
structure
is
going
to
be.
I
think
across
providers
and
repos
that
are
out
there,
there's
a
lot
of
different
examples
of
how
people
choose
to
run
these
themselves
for
their
reasons,
what
we
choose
to
do
should
be
done
for
reasons,
there's
there's
multiple
things
that
we
could
choose
to
do
and
what
we're
doing
right
now
is
a
mishmash
of
them
and
does
not
make
sense.
B
A
That
you
know
I
think
that
Tim's
point
of
Tim
Sinclair,
specifically
this
point
of
having
having
a
service
that
provides
this
for
us,
would
be
kind
of
Awesome.
If,
especially
if
it
imposes
our
enforces
structure
right
structure
that
we
don't
have
right
now,
it's
definitely
like
one
of
the
options.
I
think
that
you
know
something
else
to
consider
is
is
staffing
in
general
right.
You
know
the
the
idea
of
the
idea
of
branch
management.
Right
now
you
know
exists
scoped
within
you
know,
scoped
within
quarterly
cycles,
right
for
every
release.
A
Right
and
then
you
know
afterwards
the
the
idea
of
patch
release
right.
It
used
to
just
be
one
person
right
and
we're
working
on
this
idea
of
having
a
team
right,
but
it's
still,
you
know
I.
Think
staffing
is
still
a
concern
right,
so
for
it,
if
we
have,
the
expectation
of
you
know
right
now,
I
think
it's
three
to
four
to
five
people.
Maybe
they
can
actually
execute
on
on
cutting
a
kubernetes
release
right
or
have
the
access
to
do
that
right
now
we
need
to
build
something.
That's
more
scalable,
first
and
foremost,.
B
A
B
One
of
the
core
tenets
I
think
for
this
new
system,
as
we
stand
it
up
that
each
of
these
individual
components
that
build
some
things,
it
needs
to
be
defining
what
it
is
supposed
to
be
publishing
to
a
place
and
what
the
state
of
that
should
be.
So,
even
if
we
use
a
hosting
provider,
that's
imposing
some
structure
on
us.
We
need
to
have
a
priori
decided
what
is
supposed
to
be
where
and
have
tests
that
are
monitoring
for
that,
so
that
when
we
accidentally
don't
publish
just
the
cubelet
binary.
A
So
I
am
all
back
to
that
staffing
thing.
I
think
that
you
know
in
terms
of
in
terms
of
sub-project
owners
who
are
currently
in
release
engineering.
We
have
maybe
five
to
six,
maybe
they're,
not
all
of
the
appropriate
people.
Do
we
want
to
further
segment
that
group
of
people
to
break
between
who's
doing
patch?
She
is
feeling
what
should
should
it
still
be
a
big
big
blob
of
the
same
people
and-
and
we
figure
out
who
else
is
interested
and
potentially
working
on
this
effort?
A
B
A
I
think
we're
long
overdue.
At
this
point,
I
was,
as
I
was
combing
through
our
backlog.
I
think
I
caught
a
an
issue
from
Joe
from
maybe
like
late
2006
or
early
2007.
That's
like
move
all
of
the
the
build
infrastructure
out
of
Google.
Stop
building
Google
could
say
like
all
these
issues,
that
I
mean
you
were
circling
back
on
two
years
later.
So
like
it's,
it's
overdue,
it's
overdue.
When.
B
A
All
right,
well,
I,
don't
have
anything
else
personally
does.
Is
anybody
else
interested
in
talking
about
any
topics
before
we
close
this
out,
give
you
a
bunch
of
time
back.
A
Alright,
so
I
will
say
it
once
more.
We
really
do
need
continued
help
and
effort
around
knocking
down
a
lot
of
the
stuff
on
these
project
boards.
So
if
there
are
things
marked
as
Help
Wanted
are
there
things
that
you're
currently
assigned
to
you're
no
longer
interested
in
working,
feel
free
to
give
them
up
feel
free
to
tag
them
it's
needing
help
and
as
usual,
if
there
are
things
in
the
in
the
milestone
that
need
working
on,
feel
free
to
jump
in.
Thank
you,
everyone
who
showed
up
today.