►
From YouTube: Kubernetes SIG Release - 2019-07-30
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
B
B
B
D
F
C
The
classes
look
cool,
all
right,
I
could
probably
get
started.
I
realized,
recording
already
so
hello
everyone.
This
is
the
cig
release
meeting
for
July
30th.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say:
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
just
in
general,
be
excellent
human
beings.
So
that
said,
we
are
going
to
kick
off.
C
We've
got
a
few
agenda
items
and
we're
also
going
to
start
doing
something
new,
which
is
walking
the
project
boards
that
we
have,
for
the
sake
just
to
knock
out
or
assign
any
new
items.
So
the
first
thing
on
the
agenda
Duvall
has
a
wants
to
talk
a
little
bit
about
the
working
group
LTS
and
where
they're
at
so
do
all.
Are
you
on
the
call?
Yes,
you
are.
G
G
F
D
G
E
D
G
G
That's
okay.
People
will
get
to
see
it
early,
so
yeah.
This
is
the
kept
working
Apple
yes
week
two
meetings
ago
we
decided-
let's
get,
let's
start
the
cap
and
the
document,
because
we
have
spent
a
lot
of
time
discussing
doing
a
survey
discussing
the
survey
understanding
how
the
users
are
using
kubernetes
today
or
trying
to
understand
I,
hope,
I'm
sure
we
will
never
finish
understanding.
G
We
had
couple
of
user
scenarios
where
we
had
one
user
come
in
and
explain
how
they
were
using
kubernetes
and
we
kind
of
two
meetings
ago
decided:
let's
discuss
what
we
think
the
cap
should
be
and
then
start
putting
in
all
our
points
over.
There
wanted
to
start
a
document
but
decided
to
go
in
the
cap
structure
so
that
we
can
make
it
first
of
all
capital
cell
research
structure
at
least
the
best
one
we
have
and
it's
easier
to
I
mean
it's
a
agreed-upon
structure.
G
G
G
Yes,
the
the
motivation
is,
we
have
nine
month
policy,
one
of
the
things
they
agreed
in
the
group
that
you
know
the
customers
have
been
asking
the
release
team
to
increase
the
nine
month.
Support
to
12
months.
Jordan
brought
this
up
a
couple
of
times
in
the
meetings
that
there
is
some
kind
of
understanding
across
board
that
maybe
nine
months
we
can
increase
to
12
months.
G
You
are
at
least
having
a
year
of
support.
We
had
two
proposals:
stable
dev
proposal
from
Tim
Sinclair
and
another
ideas
proposal
from
Blue
Bomber.
Both
this
proposed
stable.
Their
proposal
was
the
ideal
proposal.
According
to
me,
was
you
know
something
which
we
should
probably
envision.
You
can
make
changes
to
it,
but
it
was.
It
was
kind
of
giving
us
a
long
term
support
and
a
fast-track.
G
The
RTS
proposal
was
from
Lobo
mayor
was
more
pragmatic,
saying,
okay,
we
are
here
today.
Let's,
if
you
want
trillion
LTS,
we
can
just
switch
one
of
the
releases
LTS
at
the
gist.
Both
of
them
had
some
implementation
of
challenges,
so
I
felt
like
with
maybe
we
should
create
a
hybrid
version
of
both
of
them
extend
the
release
by
more
than
one
year,
and
if
you.
G
To
the
proposal
yeah,
it
says
nine
months
to
14
months
I.
Today
we
actually
have
nine
months
of
support
for
each
release,
but
we
end
up
giving
at
11
months
because
we
followed
closely
the
release
before
we
only
and
the
releases
are
expired
or
supported
only
during
the
release
team,
when
the
release
team
is
active
and
the
release
team
is
active
for
three
releases
and
at
the
front
of
fourth,
after
after
nine
months
when
the
fourth
release
team
comes
in
in
a
month
or
two
is
when
we
expire
a
release.
G
So
it's
ideally
not
exactly
nine
months.
It's
actually
around
eleven
months,
ten
or
eleven
months,
depending
on
the
release,
we
have
seen
different
releases
have
ten
months
and
11
months.
So
looking
at
the
same
pattern,
if
we
extend
support
of
each
release
from
nine
months
to
twelve
months,
we
might
end
up
doing
it
for
fourteen.
So
let's
just
call
it
out
as
fourteen
months.
So
that's
so.
C
C
But
I
mean
so
for
the
sake
of
policy.
It
is
considered
unsupported,
the
second
that
neck,
that
necks
release
comes
out
all
right.
There
may
be
a
cherry-pick,
and
that's
fine
and
and
of
course
that's
going
to
happen
but
like
it
is,
can
still
considered
an
unsupported
release
when
a
terrific
release
comes
in
what.
B
Would
be
helpful.
Data
to
have
here
is
a
record
of
which
releases
we
have
at
least
CVG
fixes
for
in
reference
to
when
there,
because
I
don't
have
the
docket
for
me,
I
swear.
We
had
a
discussion
with
Liggett
and
other
folks
talking
about
how
like,
under
extenuating
circumstances
like
a
CVG.
That
was
a
super
high
score,
that
the
older
releases
were
also
sort
of
patched
like
one
final
goodbye
patch
release
be
fuller
before
everything
went
out.
D
Don't
recall
and
my
looking
and
not
prior
to
the
one
nine
release
but
I,
don't
know
that
there
had
been
official
CV
ease
before
that
anyway,
but
I
don't
think.
We've
had
a
security
related
issue
be
in
the
set
of
stuff
beyond
the
nine
issues,
but
that
there
was
talk
of.
If
that
were
the
case,
and
the
back
part
was
straight
forward
that,
yes,
of
course,
we
should
do
it
right.
I
This
this
came
up
because
we
were
looking
at
back
porting,
a
really
trivial
fix
to
a
bug
and
when
we
were
debating,
if
we
wanted
to
do
that
outside
of
the
release
window,
there
was
some
discussion
of
well
clearly.
There
should
be
some
kind
of
exception
for
at
least
a
really
bad
vulnerability,
but
we've
never
actually
done
that.
I
G
Know
I
think
we
have.
So
if
you
look
at
the
current
release
and
1.16,
the
1.12
jobs
would
be
expired
in
two
weeks
and
that's
the
overflow
period
is
just
which
I
was
talking
about
it's
being
and
if,
after
that,
after
we
turn
off,
they
were
not
well
jobs
and
no
patches
are
released.
Is
when
I
think
we
start
thinking
about
back
coding
very
severe.
So
so.
G
C
I
F
I
guess
yeah
I,
suppose
I
would
I
would
assume
that
any
sufficiently
large
vendor
should
be
able
to
produce
a
dot
release
of
an
existing
or
a
previous
release.
Branch
I
outside
of
the
context
of
the
official
project.
I
suppose
I
kind
of
would
like
to
see
some
uptick
in
our
ability
to
consistently
staff
the
patch
release
team,
also
to
see
a
collection
of
companies.
F
You
know
doing
this
work
in
the
private
before
trying
to
you
know
slap
a
seal
of
approval
or
something,
as
the
upstream
project
like
I,
feel
like
I
know
that
many
of
these
motivations
seem
to
involve
providing
commercial
support
and
I'm
I'm
less.
That's
a
less
compelling
argument
for
me
personally.
I.
B
Feel
like
to
move
the
conversation
forward.
Can
we
accept
that
there's
some
Delta
after
the
last
release
cycle?
We
don't
know
how
much
we
should
miss
out
historically,
but
this
profession
is
about
adding
one
more
release
cycle
to
the
support
window,
which
is
cool.
So
the
thing
in
the
dock
that
I'm
reacting
to
is
n
minus
two
upgrades
being
a
blocking
prerequisite
for
that
I.
Don't
like
that,
it's
that
doesn't
seem
like
that's
gonna
fly
like
so.
C
I
think
this,
this
leans
more
towards
the
LTS
side
of
it
versus
the
I
think
I
think
it
would
be
low
effort
at
Tim
and
I
were
talking
about
this.
A
little
bit
would
be
low
effort
to
increase
the
amount
of
releases
that
we've
supported
for
without
changing
the
upgrade
strategy.
If
we
go
for
n
minus
2,
this
is
going
to
change
a
whole
bunch
of
stuff.
I
2
is
also
kind
of
more
of
a
cigar,
slash
cluster
lifecycle,
question
right,
I
mean
that's
like
that's
like
release
might
need
to
qualify
it
or
something
but
saying
this
is
supported
or
not.
It's
not
like
Livan.
For
that
that.
B
Was
my
question
like
I,
just
I
haven't
been
involved
in
LTS,
so
I
don't
know.
Perhaps
you
all
have
had
a
lot
of
substance
of
discussions
about
it,
but
it
seems
like
it's
a
pretty
fundamental
thing
that
flies
in
the
face
of
what
the
project
currently
supports
and
I
feel
like
it
would
would
introduce
a
bunch
of
additional
complexity
where
I
personally
would
prefer
to
take
that
effort,
because
it's
talked
about
how
like
we
don't.
B
We
want
people
to
do
fewer
upgrades,
because
the
upgrades
are
painful
and
I
feel
like
the
more
appropriate
way
to
solve.
That
problem
would
be
to
make
the
upgrades
less
painful
so
that
it
is
not
a
problem
to
do
more
of
them
rather
than
to
introduce
a
new
mode
of
upgrade
and
change.
All
of
the
things
to
support
that
assumption,
while
supporting
the
existing
mode
of
right
is
it's
a
lot.
So
the
the
that
prerequisite
I
take
issue
with
the
proposal
seems
seems
cool
yeah,.
C
I
would
I
would
I
would
tend
to
agree
with
Aaron
there.
If
anything,
I
would
say
like
again
that
it
would
be
easier
to
change
the
support
policy
around
how
many
releases,
as
opposed
to
doing
anything,
LTS
EE
for
the.
If
we're
talking
two
months,
I
would
probably
say
15
months
as
opposed
to
nine
all
right
that
gives
you
the
that
gives
you
the
subscription
cycle
of
a
year
plus
a
drift
cycle
of
three
months.
So
and
that's
just
me,
riffing
right
now,
I
should
look
at
this
proposal
more
when
it's
more
fleshed
out.
I
G
But
when
you
lag
behind
by
three
or
four
cycles-
and
if
you
get
you
know,
if
we
increased
it
say
by
three
months
today,
you
get
a
three
month
support
you,
you,
you
are
saved
by
three
months.
But
after
that
again
you
are
at
the
lowest
release
and
you
have
no
way
to
upgrade
the
biggest
challenge
for
doing
upgrades
like
what
and.
C
G
G
I
have
business
needs
that
prevent
me
from
upgrading
right
now,
and
then
you
slag
down
by
for
upgrades
instead
of
three
that
we
do
right
now
and
that
to
catch
up
to
the
technical
debt
you
have
to
make
for
upgrades
upgrades
are
expensive
unpredictable.
Sometimes
when,
especially
when
you're
moving
from
yeah,
especially
many,
are
moving
for
releases
I.
Don't.
C
Is
make
it
fast
yeah?
Yes,
yes,
so
I,
don't
think
that
we
should
I
mean
like
we're
a
project
right,
we're
we're
not
a
product
people
who
the
the
vendors
who
turn
kubernetes
into
a
product
they
may
have
requirements
like
that.
I
think
that
we
should
not
take
on
someone's
inability
to
upgrade
their
own
infrastructure
right.
I
Hear
you
sorry
good
just
briefly,
one
thing
that
I
don't
get
here
is
that
that
that
15
months
I
mean
isn't
that
also
kind
of
a
like
a
vendor
concerned
that,
like
you,
need
to
do
what?
What
exactly
are
we
expecting
to
happen
upstream
in
that
fifteen
months,
because
I'm
pretty
much
just
envisioning
that
we're
going
to
be
running
CI
for
a
couple
additional
releases
for
many
more
months
doing
approximately
nothing
so.
C
Yeah,
so
if
it's
doing,
if
it's
doing
nothing,
I
think
that's
fine.
If
there
nothing
the
backboard,
that's
that's
fine,
but
what
it
gets.
You
is,
if
you
consider
and
I
think
I'd
looked
at
these
recently,
if
you,
if
you
only
consider
if,
like
just
for
the
sake
of
discussion,
if
you
only
consider
the
if
you
consider
a
KS
e
KS
and
GK
right,
I,
think
they're
all
currently
they're
all
currently
on
a
version
of
kubernetes
that
is
about
to
go
out
of
support.
F
Gonna
say
something
are
controversial
here:
I
do
not
believe
that
Amazon,
Google
or
Microsoft
need
the
open
source
kubernetes
projects
help
in
supporting
or
more
quickly
qualifying
versions
of
kubernetes
to
release
in
their
commercial
projects.
That
was
right.
Yeah
I
am
highly
skeptical.
These
are
the.
B
F
F
I
feel
like
the
things
that
will
get
staffed
are
the
things
that
people
will
volunteer
and
show
up
to
staff
like
if,
if
there
was
an
overwhelming
desire
for
longer
support,
I
feel
like
the
people
would
have
materialized,
they
would
have
all
been
beating
down
the
door
to
provide
the
support
and
they
would
have
done
it
themselves
and
so
I
feel
like
absent.
That
I
am
I,
am
I'm,
trying
I,
guess
I'm
wondering
what
is
the?
F
B
C
I
Leave
a
note,
though,
forth
my
cig
testing
and
work
group
kids
in
for
a
cat
that,
like
it's
not
just
about
people,
cost
that
we
should
at
least
consider
there's
also
just
like
the
cost
of
maintaining
infrastructure
for
more
releases
longer.
It
might
be
worthwhile
but
like
that,
should
be
factored
in
exactly.
I
K
F
G
B
Hear
you
on
all
that
I
just
want
to
make
sure
that,
like
we're
not
going
back
to
like,
why
did
we
even
for
WT
LTS
in
the
first
place,
so
I
feel
like
it
was
important
and
necessary
for
that
group
to
have
conversations
about
whether
or
not
what
LTS
even
means
what
healthiest
would
cover
and
what
outcomes
should
come
from.
That
I
feel
like
this
document.
Here
is
maybe
the
start
of
one
concrete
idea,
which
is
to
extend
the
support
window
by
release
cycle
and
I.
B
Think
that
the
folks
here
have
a
lot
of
ideas
about
what
implications
I
would
have
from
support
perspective
across
all
the
various
tendrils
of
the
project,
and
so
I
want
to
make
sure
we're
having
a
conversation
about
like
fleshing
out
those
implications
and
whether
we
want
to
carry
this
forward
or,
if
you're
you're,
trying
to
suggest
like
this,
that
the
discussion
around
LTS,
like
should
be
concluded
with
it,
seems
that
the
absence
of
people
to
make
it
happen
indicates
that
nobody
actually
wants
it
to
happen.
I
mean.
C
I
think
that
that's
a
worthy
conclusion
to
but
but
like
he
said,
let's
not
blow
scope
on
this.
We
there
is
a
cap,
there
is
a
cap
or
there
will
be
a
cap.
We've
we've,
given
some
feedback.
I
think
that
you
know
some
some
of
it.
Some
of
it
needs
to
be
fleshed
out
before
we
can.
We
can
really
talk
about
it
again.
C
C
L
C
Can
we
can
talk
about
that,
but
there
will
be
a
doodle.
That
was
the
first
thought
that
it
would
just
be
easier
to
keep
the
same
day
and
shift
the
time
up.
But
all
so
I
need
to
look
at
my
schedule
because
we
have
like
internal
meetings
about
upstream
stuff
to
you
and
I
may
have
to
make
sure
that
they
don't
conflict.
So
all
right,
doodle
doodle
for
the
end
of
the
day
and
and
we
can
I'll
send
it
out
so
release
team
release,
engineering
and
cig
release
to
discuss
word
all
right.
F
Nor
this
one,
this
didn't
used
to
be
a
friendly
time,
should
remember
when
this
meeting
used
to
be
yet
the
European
friendly
time,
I.
C
All
right,
so
everything
and
nothing
is
new
everything
everything
repeats
itself,
we're
going
back
so
yeah
a
doodle,
a
doodle
via
your
inbox
as
soon
I
want
to
try
to
close
that
out
quickly,
so
that
we
can
start
having
the
release
engineering
meetings.
That
will
be
also
the
venue
for
the
the
release
managers
group.
So
the
patch
release
team,
the
branch
manager
is
the
release
manager
associates
to
meet
and
chat
about
things
for
the
cycle.
So
all
right.
Next
one
Aaron.
B
B
I
would
like
to
see
kind
used
as
a
release
blocking
job
the
process
that
I
see
documented
that
I
myself
wrote
a
while
ago,
so
that
I'm
supposed
to
put
it
on
some
singer
lease
dashboards,
so
that
you
can
see
that
it's
not
flaking
I'd,
rather
maybe
a
men
that
say
look
here's
an
existing
test
grid
where
I
can
show
you
that
it's
not
flaking
and
then
get
it
in
there
walkie
totally.
Your
call
if
I
need
to
like
run
this
by
at
the
earliest
team
and
see
I
signal
as
well.
B
My
thought
was
to
do
this.
The
real
motivating
factor
here
is
kind
is
to
date
to
the
only
kubernetes
provisioning
thingy.
That
I
am
aware
of
that
supports
ipv6,
which
is
pretty
cool,
but
I
also
think
it's
a
good
idea
to
have
pv4
as
well,
so
that
one
fails.
We
know
that
it
was
a
an
actual
failure
for
of
communities
real
quickly
and
then
a
big
sources
for
it
right
right
and
then
additionally,
we're
working
to
improve
the
number
or
increase
the
number
of
end-to-end
tests.
B
The
kind
can
run
beyond
just
conformance
so
I
had
a
suggestion
of
like
let's
just
follow
what
the
other
jobs
do,
which
is
tests
just
kind
of
get
added
in
overtime,
and
if
the
job
starts
to
go
red,
you
say
get
those
tests
out
of
there.
The
other
option
is
that
I
need
to
do
like
I'll
set
up
a
canary
job
over
here
when
we're
running
all
the
tests
and
stuff,
and
then
I
show
you
the
canary
job,
and
then
you
agree.
B
We
already
have,
like
kind,
is
already
used
right
now
in
the
release
informing
dashboards
the
kinder
to
do
some
level
of
upgrade
they're,
not
really
a
sufficiently
federal
level
of
upgrade
to
give
us
confidence
that
it
leads
LTS
his
expectations
right,
but
so
I
think
hide
by
default.
There's
probably
also
big
questions
about
kind
being
used
in
pre
submits
we'll
get
there.
I
just
wanted
to
float
it
as
an
idea
here.
If
y'all
are
cool
with
this.
G
C
B
We're
still
well
behind
in
like
measuring
a
lot
of
this
stuff,
so
good
chunk
of
it
is
like
you,
gotta
take
our
word
for
it.
I
do
have
help
on,
and
issues
for
people
who
want
to
like
influence
the
dashboards
and
measure
the
metrics
prove
that
the
job
runs
fast
enough.
Frequently
enough
passes
enough,
doesn't
flake
all
the
time,
but
in
absence
of
this
I'm
not
getting
ready
to
do
a
issue
type
of
thing.
Okay,.
B
B
B
C
F
F
C
Okay,
all
right,
so
it
sounds
good
for
kind.
That's
awesome!
That's
really
cool
to
see
Aaron.
So
thank
you
for
presenting
that
we're
going
to
start
so
I
think
this
is
the
first
meeting
we're
doing
it,
but
we're
going
to
start
sweeping
through
like
agenda
standing
agenda
items
for
the
sub
projects
and
what
their
statuses
are.
Something
immediately
that
comes
to
mind
is
we've
got,
we've
got
a
hypercube
here
and
we've
got
publishing
BOTS
and
I
kind
of
feel
like
they
should
fold
in
as
sub
projects
or
just
areas
of
code
under
release
engineering.
F
C
Visibility,
really
we
don't
I,
don't
know
how
much
we
touch
hypercube
today,
like
at
least
anyone
on
this
meeting
touches
hypercube
well.
F
F
C
So
I'm
like
I'm,
not
saying
that
like
it's
untouched
right
but
I,
think
it
would
be
touched
more
if
it
is
under
the
auspices
of
a
sub
project
that
is
actually
starting
to
do
stuff.
That
was
that's
my
motivation
for
it
and
and
for
publishing,
but
I
think
that
I
mean
I.
Think
publishing
BOTS
is
fine
to
say
by
itself
if
it
needs
to,
but
it
could
fold
under
release
engineering
too,
and
we
could
push
more
people
into
that.
I
think
right
now
it's
just
Nikita
Stefan
and
DIMMs
working
on
it
or.
F
I
B
I
guess
I'm
six
of
one
half
dozen
of
another,
with
my
sub
project
hat
on
I
kind
of
like
having
sort
of
discrete
quarters
of
different
code
bases,
because
even
I
kind
of
hope,
you're,
not
the
go-to
guy
for
container
image
promoter
and
release,
notes
and
the
release,
engineering
infrastructure
and
the
documentation
for
release
engineering
right.
Great
so
I
mean
this.
Doesn't
that
Nikita
and
and
Steven
or
Stephan
are
like
the
go-to
people
for
publishing
pot
great.
So.
C
C
So
we
also
recently
added
a
release:
engineering,
reviewers
and
approvers
to
kubernetes
kubernetes,
so
part
of
the
motivation
for
this
is
being
able
to
have
those
reviewers
and
approvers
actually
review
and
approve
the
hypercube
stuff
right
or
start
to
review
and
approve
more
of
the
things
that
are
under
the
build
directory.
So
it's
you
know
right.
F
And
I
guess
thinking
about
it
more
as
we
talked
and
looking
at
the
issue
when
Steven
wanted
the
project
sponsored
by
cig
release
in
the
first
place,
I,
don't
think
it
makes
sense
to
be
a
standalone
sub
project,
but
I
think
the
summer
we're
talking
about
changing
it.
Just
the
roll
call
I
do
think
that
it.
If
the
argument
is
that
it's
part
of
the
release
process,
it
probably
should
be
part
of
the
loose
engineering
sub
project
rather
than
its
kind
of
stand-alone
thing.
F
My
idea
was
always
that
it's
actually
part
of
the
code
organization,
since
it
makes
a
small
collection
of
go
packages
available
in
isolation
which
is
not,
in
my
mind,
the
same
or
directly
related
to
the
process
of
releasing
kubernetes
itself.
But
you
know
I'm,
not
a
dictator,
obviously,
so,
given
that
it's
sponsored
here,
I
think
I'm
fine
with
any
of
the
changes
you
proposed.
Even
so.
C
I
F
Which
I
guess
is
my
argument
that
they
were
at
least
the
publishing
bot
was
not.
But
given
that
the
authors
of
the
publishing
blob
believe
that
it's
part
of
the
release
process
that
its
continued
function
operation,
it
seems
to
fit
with
the
things
that
are
in
like
K
release,
which,
in
my
mind,
means
that
as
part
of
the
release
engineering
sub
project.
And
it's
not
my
arguments,
their
argument,
which
is
like
fine
I,
think.
I
C
B
Existential
like
middle
space,
that
some
projects
have
always
existed
in
since
I
tried
to
help
Brian
grant
create
them
as
a
thing
there,
that's
a
non-hierarchical
listing
of
owner's
files
that
you
have
there
and
release
engineering.
So
who
is
the
decider
when
it
comes
down
to
deciding
something
for
the
release
engineering
project?
How
do
I
know
the
one
or
two
people
who
rule
over
all
of
those
hierarchically
yeah
yeah.
B
Know
again,
yeah,
then
it
kind
of
needs
to
be
like
Brian
always
said,
there
should
be
an
additional
field
in
there
called
owners
right,
and
then
it's
like
that
person
and
that
that
owners
field
needs
to
be
copied
everywhere.
So
then
we're
like
well,
okay,
what
if
we
just
have
like
the
same
people,
show
up
in
the
approvers
field
and
all
of
those
things
so
then
like
we
could
do
like
the
intersection
of
all
those
earners
files
and
see
who
knows
improver
and
all
those
files,
and
that's.
B
Got
caught
up
there
that
shows
the
whatever
it's
working
on
that.
If
somebody
wants
to
help
on
it,
many
sub
projects
do
not
actually
fit
this
model
at
all,
or
they
this
room
yeah.
So
alright,
whatever
it's
it's
your
show,
you
run
it.
However,
you
want
to
me.
It
feels
an
awful
lot
like
I'm
having
a
difficult
time,
differentiating
between
release
engineering
and
cig
release
as
a
whole.
When
it
comes
to
the
use
of
these
different
code,
bases
and
stuff
like
I,
would
I
think
publishing
bought
those
seemed
legit.
B
I
think
you
should
I
would
call
hypercube
the
abandoned
thing
than
it
is
and
figure
out
I
mean.
Maybe
that's
a
good
LTS
question
right
like
who
actually
uses
hypercube?
Why?
Because
it
clearly
falls
under
cig
releases
scope
as
an
artifact
that
he
is
cut
as
part
of
the
kubernetes
release
questions.
Do
you
want
to
continue
doing
that.
C
K
I
C
B
B
I
would
want
to
see
those
owners
files
here,
like
I,
eventually
want
to
live
in
a
world
where
the
owners
aliases
disappear,
or
just
github
teams
and
then
like
these,
just
lists
sort
of
a
github
team
called
release
engineering
who
you
expect
to
see
in
all
the
places
and
so
yeah
release
engineering,
owning
files
in
a
directory
called
build
and
kubernetes
seems
to
make
sense.
That's
less
surprising
to
see
here
so
any
places
eat
like
created
those
aliases
to
use
them.
Yeah.
B
Then
sub
projects
also
do
have
the
ability
to
had
github
associated
github
teams,
which
would
be
another
way
for
you
to
like
start
start
giving
us
that
hint,
the
that's
sort
of
the
set
of
people
that
you
expect
to
be
in
all
those
places.
So.
C
B
And
say:
there's
a
way
you
can
specify
it
in
a
machine-readable
format
and
it's
example
so
that
something
that
consumes.
That
knows
that
when
we
talk
about
the
release,
engineering
sub
project,
you
should
be
talking
to
these
github
teams.
Is
that
new?
No,
it's
the
same
thing
that
lets
sub
projects
specified.
Maybe
another
thing
you
could
use
that
this
sub
project
has
this
slack
channel
or
this
mailing
list,
or
these
get
teams,
which
is
what
like-kind
uses
to
point
to
a
kind
like
informants
abroad.
C
C
C
It's
a
real,
quick,
all
right.
Let's
see,
hypercube
anybody
hypercube
think
we
we
beat
that
one
to
death,
just
merit
licensing,
so
licensing
I
mentioned
in
the
community
meeting
that
that
I
am
handing
off
I'm
divesting
myself
from
anything
licensing
related
I'll
be
around
to
help
if
I
need
to
you,
but
Nikita
is
taking
point
on
that.
C
Dims
and
Steve
Winslow
from
the
Linux
Foundation
are
also
part
of
that
sub
project.
Again
I
will
help
as
required,
but
I've.
A
son
assigned
myself
from
any
tasks
related
to
licensing.
So
I
can
try
to
focus
on
the
release.
Engineering
stuff,
where
that's
at
I
don't
know,
but
Nikita
can
give
the
next
update
a.
C
C
After
immediately
after
that,
we'll
be
cutting
branches
for
1/16,
we'll
be
cutting
a
branch
and
the
associated
things
for
those
branches
for
1/16.
So
it's
something
that
I'd
like
to
figure
out
in
the
next
week.
In
change,
the
sao
jorge
has
been
working
on
some
of
that
writing
up
some
of
that
stuff.
I
know,
Aaron
has
a
doc
that
was
like
kubernetes
surgeons
or
something
that
you
link
to
at
some
point
in
tests
infra,
and
there
is
something
that's
mentioned
in
CI
signal
that
I
think
Aaron.
C
B
C
And
tie
all
of
those
threads
together.
Yes
right
so
we
have
some
in
the
I
think
we
have
some
in
the
CI
CI
signal
handbook.
There
were
some
in
the
testing
for
handbook
which
got
transferred
to
the
branch
manager
handbook
and
out
of
the
release
team
handbook
section
and
then
there's
some
stuff
in
tests.
Infra
right.
B
B
Referring
to
okay,
because
I
wanted
to
try
and
give
you
a
canonical
place
to
understand
where
these
things
are
I'm.
Also
fine,
if
you
put
this
in
someplace,
where,
like
you,
you
want
released
engineering
to
take
over
this
stuff
that
creates
these
channels
and
then
put
the
docs
next
to
whatever.
That
is.
C
I
will
probably
link
out
to
yours,
because
I
think
that
it's
generally
useful
information
I,
don't
necessarily
want
to
send
someone
to
the
sig
release
repo
when
they're
already
in
testan,
for
looking
for
information
on
this
right.
So
test
in
four
is
probably
the
right
place
for
it
to
be
with
the
hand
books
linking
out
to
that.
B
C
B
Bigger
issue
with
respect
to
upgrades,
or
at
least
for
those
channels
is
just
is
that,
like
the
word
beta
refers
to,
it
was
intended
to
refer
to
the
release
branch
that
had
been
cut
but
had
not
yet
been
actually
pushed
out
the
door
as
a
dot
zero.
So
right
now
the
word
beta
refers
to
kubernetes
115,
and
it
instead
should
refer
to
nothing
yeah
and
instead
stable
one
should
prefer
to
kubernetes
15
because
stable
one,
it's
the
most
recently
released
stable
version
of
kubernetes.
B
C
My
question
is:
when
should
we
do
that
because
I
think,
wherever
it's
listed,
it
says
to
shift
them
during
the
beta
phase
and
we
haven't
gotten
there
yet
right.
So
if
that
needs
to
be
happening
so
like
one
of
my
bigger
questions
was
like.
If
that
needs
to
be
happening
sooner,
we
need
to
document
it.
I.
B
Would
say:
that's
that,
so
they
should
be
on
it
as
part
of
the
release
going
out
the
door.
The
release
has
been
cut
so
beta.
It
doesn't
make
any
sense
anymore
and
now
the
most
recently
released
stable
release.
This
is
the
next
thing
right
so
like
once,
1/16
goes
out
the
door,
one
of
the
final
closing
out
tasks
as
you're
like
you
know,
because
there's
some
cleanup,
you
have
to
do,
get
ready
for
the
retro
talk
about
it.
C
I
was
going,
I
was
gonna,
say
that
you
know,
even
even
bata
doesn't
make
sense
breeds
like
so
I
can
see
so
yeah.
So
part
of
the
reason
I
think
part
of
the
reason
that
they
kept.
That
around
was
so
that
you
could
test
versions
between
you
could
test
versions
that
were
merging
between
master
and
and
that
beta.
It.
B
C
B
C
All
right
cool,
so
we
are
I'm
fairly
certain
we're
not
gonna
get
time
to
walk
the
board.
We
could
start,
but
I
did
some
of
it.
I
kind
of
anticipated.
This
and
I
did
some
of
it
yesterday.
So.
C
But
if
you
were
part
of
these,
if
you're
part
of
these
sub
projects,
please
take
a
look
at
these
boards.
Please
work
on
getting
your
tasks,
updated,
I,
think
one
of
the
I
think
one
of
the
harder
things
that
we
have
to
do
is,
after
after
we
rotate
a
after,
we
rotate
a
release
team
out,
they're
still
outstanding
tasks,
occasionally
that
are
still
owned
by
the
former
release
team.
Depending
on
your
interest,
you
may
stay
around
you.
C
All
right
so
in
the
chat
and
I
will
put
it
on
the
talk
to
the
expectation
moving
forward
is
that
we
I
would
like
everyone
who
is
running
a
sub
project
meeting
to
try
and
do
a
grooming
during
their
meeting
right.
So
release
team
should
be
doing
a
grooming
release
engineering
licensing
once
they
have
a
meeting
and
sig
release.
We
will
try
to
do
the
the
top
level
board
grooming
during
our
meetings,
so
we'll
try
a
little
better
I
think
we
had
a
good
discussion
today.
C
I
think
we
did
rat
hole
a
little
bit
so
we'll
try
to
be
better
at
being
more
decisive
and
sticking
to
the
agenda
items.
But
all
that
said
we
we
should
also
start
doing
this
at
the
beginning
of
the
meetings.
Is
there
anyone
new
on
the
call
that
wants
to
say
hi
wants
to
introduce
themselves
talk
about?
Why
they're
here.
C
J
C
All
right,
okay,
anything
people
want
to
talk
about
before
we
go.
We've
got
five
minutes.