►
From YouTube: Kubernetes SIG Release 20191105
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
All
right,
hello,
hello,
everyone.
This
is
the
November
4th
edition
of
the
sake
release
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
we've
got
a
light
agenda.
Today
looks
like
Tim
I
know.
Tim
said
he
was
going
to
be
on
spotty
connection,
but
looks
like
Tim.
Has
some
action
items
up
discussion
items
up
for
a
LTS
group
and
release
notes,
quality,
so
Tim?
A
B
B
That's
looking
to
be
something
concrete
enough
to
actually
share
out
further,
so
the
the
gist
of
it
is
the
TLDR
is
what
would
it
look
like
if,
instead
of
supporting
a
release
for
nine
months,
we
did
it
for
twelve
and
then
a
slight
twist
on
that
it?
Would
it's
not
actually
9:00
today,
because
we
sort
of
do
nine,
plus
six
or
seven
weeks,
and
that
part's
been
particularly
fuzzy.
B
So
the
part
of
the
proposal
would
be
to
make
that
not
fuzzy
and
call
it
actually
a
14-month
support
window
where
that
trailing
period
is,
is
actually
formally
part
of
it,
and
it's
probably
because
it's
not
really
been
defined
specifically
in
the
discussion
there,
but
the
the
discussion
was
tending
like.
If,
if
we
have
this
fuzzy
point
of
these
trailing
weeks
or
months
where
we
we
still
have
CI
writing
what
we're
really
trying
to
convince
people
to
move
off
of
the
thing
having
less
patches
move
into.
B
It
would
be
part
of
that
motivation,
perhaps
but
sort
of
nailing
down
concretely
that
only
during
that
final
trailing
period,
our
CVEs
merged
into
the
branch,
specifically
so
that's
kind
of
the
TLDR
on
it,
but
there's
a
whole
lot
more
detail
behind
it.
I
don't
know
Josh.
If
you
want
to
add
other
things
there.
C
C
And
the
second
thing
is
the
value
of
it
is
also
undefined.
We
did
an
LTS
survey
of
a
whole
bunch
of
users,
but
we
didn't
specifically
ask
whether
extending
patches
to
12
plus
months
would
help
people,
so
we
don't
actually
know
like.
We
know
it'll
help
some
people,
but
is
some
people
3%
of
our
users
or
is
it
30%
of
our
users?
C
The
you'll
see
some
discussion
from
me
and
there
you
know
where
I'm
pointing
out
a
contradictory
use
case.
That
is,
for
the
use
case
that
our
large
enterprise
customers-
they
actually
don't
care
about
nine
versus
twelve
months,
because
the
support
window
they're
looking
for
is
two
to
five
years,
so
for
them
it
doesn't
actually
make
a
difference.
C
B
Of
the
big
gaps
there,
too,
is
we
don't
understand
our
user
base
today.
Obviously,
those
people
who
are
looking
for
two
to
five
years
of
support
aren't
getting
it
from
us
we've
already
where
they're
ignored
as
far
as
what
the
community
support
is
concerned.
So
of
the
remainder
is
that
the
majority
of
kubernetes
uses
users
or
a
tiny
portion,
so
maybe
maybe
like
just
as
sort
of
this
three
percent
number
say.
C
B
A
A
A
So
I
would
I
would
lean
in
on
the
data
around
how
people
are
upgrading
kubernetes
today
how
they
are
installing
kubernetes
in
the
first
place,
I
know
they're
a
bunch
of
personas
that
we
created
in
that
survey,
so
so
yeah
deep-diving
on
those
personas
like
if
they're,
not
a
so
look
at
the
look
at
the
service
providers
as
opposed
to
the
people
who
are
consuming
something
from
a
managed
service,
because
we
kind
of
already
know
the
answer
to
that
there
and
go.
You
know,
make
assumptions
like
that
right,
yeah.
C
Tell
you
that
my
employer,
based
on
their
experience
with
LTS
releases
for
the
linux
kernel,
doesn't
believe
that
any
kind
of
LPS
released
from
the
kubernetes
project
would
make
a
difference
in
the
amount
of
time
that
we
spend
on
building
open,
jeff'd
the,
but
that's
one
of
several
providers-
and
you
know
what
goob
will
be
different
with
VM-
be
different.
Don't
know
at
this
point
one.
B
C
C
B
B
B
A
E
So
long
as
there's
been
the
availability
of
a
managed
solution,
whether
that
be
in
a
juror
AWS
work
wherever
that
has
been
good
enough
to
kind
of
encapsulate
and
take
care
of
any
worries
that
that
we
have
ever
had
so
I
think
that
I
really
do
think
think
that
the
community
is
doing
the
right
thing.
But
I
would
love
to
look
at
the
data.
You
know
wherever
we
can
and
kind
of
form
that
opinion
on,
like,
like
you
had
said,
is
it
3
percent,
30
percent
or
or
more.
B
B
On
the
one
thing
that
we
we
I
didn't
say
from
from
the
depth
discussion,
it
really
kind
of
started
from
a
point
of
like
we.
We
see
two
modes
in
the
data
where
people
want
longer
support
and
people
are
moving
rapidly
forward
to
the
latest
releases
within
the
longer
support
area.
A
lot
of
people
have
commented,
both
anecdotally
and
discussions
are
face
to
face
at
conferences
as
well
as
in
the
survey.
There
were
a
few
where
they're
just
used
to
doing
an
annual
cycle.
Business
cycles
tend
to
be
annual.
B
So
today,
if
you
do
an
upgrade,
you
might
upgrade
in
April
and
then
October
and
then
in
February,
or
just
like
the
dictator's
to
be
really
disjointed
and
awkward
from
a
planning
perspective
such
as
to
have
a
scenario
where
people
could
stay
with
in
support
and
know
for
our
given
business
cycles.
We
have
a
gap
where
we
can
do
some
major
upgrading
annually
in
this
particular
corner
plan
phase
in
plan
people
see
benefit
in
that
and
that's
a
common.
F
Yes,
sorry,
my
idea
wasn't
working
before
side
of
Thailand
again
so
I.
So
we
look
to
this
group
to
support
kubernetes.
So
your
life
time
of
your
support
cycle
directly
affected
support
cycle
of
our
products
and
we've
had
opportunities
or
situations
where
we
were
strongly
tempted
to
take
a
patch
release
to
an
unsupported
version
of
kubernetes,
and
we
decided
not
to
do
that
to
support
our
customers
because
you
all
tests
lutonic
more
thoroughly
than
we
ever
could
with
that.
We
have
I
just
want
to
throw
that
in
there.
I'll
try
to
eat
myself
now,
I.
F
A
A
So
yeah
from
the
I
mean
from
the
service
provider
perspective,
it's
kind
of
clear
to
see
that
you
know
being
able
to
do
the
stuff
faster
means
that
we
can
one
testings
faster
and
then
also
support
things
for
longer
if
needed.
This
guy
I
mean
this
III
felt
this
a
little
at
core
OS
two,
as
we
were
doing,
the
the
core
OS
Red
Hat
merger,
and
also
having
to
support
tectonic
as
tectonics
version
was
going
out
of
support
in
the
upstream
community
right
so
having
having
a
little
bit
of
that
window.
A
I
think
that
was
right
around
the
time
that
we
announced
like
112,
or
so
we
announced
a
major
CV
and
had
to
do
a
patch
for
something
that
we
were
about
to
call
unsupported,
so
I
think
having
that
breathing
room.
Even
if
it's
you
know,
even
if
it's
something
like
six
months
or
something
is
a
huge
benefit
to
people
who
move
a
little
faster
on
this.
A
Also,
from
the
perspective
of
you
know,
the
persona
who
does
not
does
not
plan
to
upgrade
frequently
because
it
is
rooted
in.
However,
they
do
business
being
able
to
provide
mechanisms
for
upgrading
faster,
might
change
the
way
they
do
business
in
the
first
place.
So
we
should
also
consider
that
that
we
might
be
able
to
shift
a
persona
from
that
we're
kind
of
hesitant,
because
we
don't
know
how
all
these
pieces
work
to.
We
can
do
it
because
we
trust
the
community.
B
As
something
else
that
this
kit
doesn't
directly
touch
on
upgrades,
the
the
working
group
has
spent
a
lot
of
time
discussing
discussing
like
support
lifetimes
and
support,
upgrade
paths
and
those
two
relate,
but
in
some
ways
are
separate
one
of
the
things
that
this
kept
would
cause
for
a
potential
problem.
If
you
upgrade
your
systems
in
place,
you
would
now
need
to
step
them
forward
and
iteratively
visit
every
release
from
the
prior
year.
B
So
you
say:
you're
on
112
you'd
have
to
upgrade
to
113
to
114
to
115
to
116,
and
there
you
have
your
next
year
that
you
could
sit
there,
that
speak
of
how
deprecation
policies
and
version
skews
are
supported.
So
today
upgrade
is
relatively
painful
if
you're
upgrading
clusters
in
place-
and
you
have
them
running
out
a
particular
version
for
a
long
time.
This
calc
would
actually
make
that
worse
now,
there's
things
that
have
been
discussed
around
making
tooling.
That
makes
upgrade
easier,
but
there's
also
a
large
philosophically
movement
around.
A
I
am
sorry
about
the
way
I
phrased.
That
I
should
have
clarified
that
I
meant
upgrade
insofar
as
moving
to
a
new
version
of
kubernetes.
However,
you're
doing
that,
my
preference
is
towards
standing
up
the
the
new
migrating
workloads,
as
you
mentioned,
and
and
tearing
down
the
old,
that's
the
ideal
scenario
and
that's
a
scenario
where
I
don't
think
that
we
should
I,
don't
think
that
we
should
aspire
to
support
too
much
of
the
upgrade
scenario
outside
of
making
sure
that
we're
we're
adhering
to
whatever
API
guarantees.
C
B
A
B
So
this
is
this
kind
of
a
one
I,
don't
know
I'm
curious
to
see
what
people
think
how
much
this
falls
within
our
scope.
I
on
the
the
patch
releases
I've
been
seeing
the
release
notes
go
by
and
sometimes
the
the
quality
has
varied.
But
what
we
had
in
the
most
recent
patch
release
was
one
of
the
patch
releases
had
nothing
in
its
changelog.
B
Now
it
turned
out
that
that
was
a
bug
and
we
fixed
it,
but
as
I
was
looking
through
other
change
logs
trying
to
see
like
have
we
fixed
the
problem
and
that
meant
reading.
What
was
there
in
the
change
logs
and
I
kind
of
noticed,
some
of
the
change
logs
are
not
super
meaningful,
and
that
got
me
looking
at
our
guidance
on
when
and
where
to
put
a
release
note
on
a
PR
and
it
feels
fairly
weak.
B
Now
I
could
see
from
a
cig
release
perspective
saying
that
we're
responsible
for
the
mechanism
we
just
collate
what
the
community
does
and
it's
hard
for
us
to
drive
change
across
two
or
three
thousand
people,
but
if
the
change
logs
are
really
really
long
and
yet
have
very
little
actionable
or
concrete
information
that
a
reader
could
look
at
and
understand
that
diminishes
their
value.
So
I
feel
like
we
should
not
just
be
publishing
the
change
log,
but
trying
to
make
sure
that
the
change
lock
has
high
quality
I.
A
So
my
feeling
there
is
that
there's
a
lot
of
stuff
happening
all
at
the
same
time.
If
we
touch
something
part
of
our
goal
should
be
to
make
it
better,
even
if
that's
even
if
it's
not
directly
correlated
with
our
sake
right,
because
we
own
the
release,
notes
process.
Yes,
we
were
responsible
for
the
tooling
and
and
the
documentation
around
how
that
process
functions.
But
if
we're
touching
a
PR
like
you
are
in
the
the
patch
release
team
I
think
there
is
some
responsibility
there
to
make
sure
that
the
release
notes
make
sense
right.
A
You
know,
from
my
perspective
as
a
reviewer
and
approver,
if
I
see
and
until
you
I
know
you
do
the
same.
If
I
see
a
commit
message,
whether
it's
a
commit
message,
a
PR
description
or
a
title
of
a
PR
or
issue
that
looks
off
or
doesn't
provide
enough
context,
I
will
ask
and
I
will
hold
the
PR
and
I
will
ask
the
person
to
update
the
commit
message
and
as
well
as
whatever
is
in
the
PR
description.
I.
Think
that
one
repo,
for
example,
kubernetes
work
right
where
we
do
a
commit
per
action
right.
A
If
we
add
a
person
to
you
know,
if
we
both
we
never
bulk,
add
people
we
may
bulk
add
within
a
PR,
but
within
that
PR
is
our
individual
commits
for
each
of
the
the
ad
removes
that
we're
doing
right
and
the
reason
for
that
is
because
this
is
all
related
to
or
membership
and
our
team
github
team
membership
and
it's
important
that
we
can.
We
can
pop
something
off
of
off
of
the
commit
history
if
we
need
to
to
understand
exactly
what
was
happening
at
that
time.
A
So
I
think
that
it's
super
super
important
to
try
to
make
sure
if
you
are
a
reviewer
or
approver
and
something
think
of
it.
This
way,
if
you
were
imagine,
you
were
only
able
to
glean
glean
what
was
happening
about
that
PR
from
its
commit
message
right,
if
you
feel
like
you
cannot
do
that
from
the
commit
message
and
the
resulting
description,
then
it
should
be
fixed
right
and
now
imagine
as
a
so.
So
that's
from
the
context
of
an
actual
review
or
approver
of
that
piece
of
code
right.
A
You
may
already
have
context
about
what's
happening.
Imagine
someone
who
is
a
new
contributor.
Imagine
someone
who
is
also
touching
that
repo
who
is
unable
to
easily
glean
glean
that
context.
How
can
we
make
it
easier
for
them
to
do
that
right
and,
and
a
large
part
of
that
is
making
sure
that
your
your
issue
description
to
your
PR
descriptions,
your
commit
messages,
your
release,
notes
are
up-to-date
and
clear
and
so
like,
if
I
say,
I've
updated,
you
know
updated,
config,
right,
updated.
A
Config
is
not
a
great
commit
message
right
if
I
do
sig
release
updated
config
for
build
jobs
for
for
build
and
staging
jobs,
or
something
like
that
right
that
gives
that
gives
the
person
who's
who's
flying
by
the
the
the
git
log,
a
little
bit
more
information
exactly
what's
happening
in
that
PR
without
having
to
dig
into
the
code.
So
we
should
consider
that
with
everything
that
we're
doing,
but
you
know
in
the
larger,
larger
scope
of
everything,
it's
it's
a
community
problem
right.
This
is
something
that
you
know.
A
A
D
B
The
thing
that
I
tend
to
fall
back
to
is
recommending
a
link
that
I
just
threw
in
the
zoom
chat.
It's
Chris
beams.
He
has
a
post
about
how
to
make
a
good
commit
and
I
feel
like
the
the
format
that
he
recommends
involves
a
one-line
summary
and
his
guidance
on
that
one-line
summary
that
the
short
log
is
useful,
I
think
for
our
project.
Specifically,
though
the
the
types
of
things
like
we,
we
say
we
want
user,
visible
changes,
but
what
what
constitutes
user
visible
and
what
what's
the
context?
I
will?
B
What's
what's
the
angle,
what
are
we
trying
to
inform
the
user
about
I've
seen
a
few
sets
of
PRS
where
the
the
reviewer
says?
Oh,
this
should
have
a
change
log
because
or
I
should
have
a
release
note
because
it
fixes
a
bug,
but
if
the
bug
was
never
used
a
visible
I,
don't
know
how
much
it
matters
in
the
end,
so
I
think
part
of
my
end
goal
is
figuring
out.
If
we
can
simplify
the
change
logs,
I
think
right
now,
basically
nobody's
gonna
look
at
them.
They
might
be
sort
of
searchable.
A
You
know,
and
and
in
that
I
think
I
feel
that
we
should
lean
towards
towards
more
release
notes
than
less
only
because
there
is.
This
goes
back
to
the
personas
thing
right.
There
is
a
different
user
for
every
repo
or
a
user
percentage
that
we're
not
considering
for
every
repo
right.
This
is
not
just
kubernetes
kubernetes,
so
it's
good
to
get
into
the
habit
of
like
how
do
we
write
something
that
is
reviewable?
A
You
know
our
auditable
across
history
right,
like
I
care
about
this,
for
enhancements
and
for
Grenada,
scoober
Nettie's
and
for
release
and
for
cig
release
and
for
a
sure,
like
you
know,
the
list
goes
on.
So
it's
it's
one
of
those
things
like
if
I'm
going
to
submit
a
change
to
this
repo,
who
could
it
potentially
affect
who
do
I
have
to
care
about
right.
The
user
is
not
just
a
consumer
of
kubernetes
day-to-day
right,
it
might
be
a
service
provider,
it
might
be,
it
might
be
a
new
contributor.
A
You
know
someone
who's
interested
in
getting
involved
in
in
contributing
to
the
code
right
that
it
has
no
idea
how
to
do
it,
and
sometimes
you
know
getting
started,
might
be
going
back
and
reading
old
issues
going
back
and
reading
old
PRS
right.
So
how
do
we?
How
do
we
provide
a
platform
to
allow
people
to
more
easily?
Do
that
and
part
of
it
is,
is
better
release,
notes.
C
More
right
now
so
I
linked
to
a
two-year
old
issue
discussing
this
topic
in
the
notes
that
I
brought
up
again
last
time,
I
was
released,
lead,
which
is.
This
has
been
a
problem
for
a
while.
Is
that
I
really
feel
like
we
need
some
detailed
written
guidance
and
that
detailed
written
guidance
needs
to
go
through
K
dev
and
the
community
meeting
and
everything
else
so
that
people
are
on
the
same
page,
because,
right
now
we
are
relying
on
people's
feelings
as
to
what
they
personally
consider
unnecessary
release.
C
Note
and
a
good
release
note
and
we're
relying
on
that,
both
on
the
side
of
the
submitter
and
on
the
side
of
the
reviewer,
and
so
frankly,
it's
I.
You
know
it's
unsurprising
that
quality
and
content
varies
widely
right,
because
people,
you
know,
may
be
doing
their
best
job
but
they're
doing
it
according
to
wildly
different
standards.
C
So
you
know
what
I
would
see
for
adding
to.
This
is
really
like,
honestly,
a
page
page
and
a
half
of
them.
For
me,
you
know
hey
if
there's
an
API
change,
it
requires
a
release.
Note
that
describes
the
API
change
unless
the
change
was
in
an
API
that
was
never
in
a
released
version
of
kubernetes,
in
which
case
you
can
skip
it.
C
Those
sorts
of
things
I
think
I,
think
that
needs
to
be
in
there
both
both
when
is
it
release
no
necessary
because
I'll
tell
you
working
on
the
release
team
I've
seen
PRS
go
in
that,
for
example,
deprecated,
an
API
call,
who
de
facto
removed
an
API
call
and
had
no
release
note.
You
know,
and
somebody
actually
put
release
note
none
the
well
their
perspective
was
yes.
This
API
call
was
released,
but
the
reasonable
removing
it
as
no
one
was
using
it
and
I'm
like
well.
How
do
you
know?
No
one
was
using
it.
C
You
know
VM
and
the
you
know
and
on
the
other
hand,
I've
seen
really
detailed
release
notes
for
what
was
a
bug
fix
that
was
on
a
between
release
cycle,
so
the
thing
that
was
being
fixed
was
never
released
so,
like
Tim
said
so,
there's
you
know
so
we're
having
guidance
in
this.
So
it's
unsurprising
that
people
just
do
whatever.
A
C
A
A
A
A
B
C
C
A
A
Alrighty,
alright,
next
on
the
agenda,
is
adding
a
kind
deprecation
label
right.
So
this
ties
into
the
release
notes
stuff
a
little
bit
as
well,
the
pr
for
that
is
linked
and
that
PR
was
inspired
by
a
different
PR
in
kubernetes
kubernetes,
to
update
the
PR
template
to
add
a
code
block
to
capture
to
capture
the
deprecation
note
right,
so
changing
kind
of
changing
what
the
changing.
A
What
the
definition
of
a
deprecated
of
a
release
note
is
for
any
for
any
deprecation
right,
so
I
felt
that
the
Josh's
trash's,
plus
wanting
that
so
I
felt
that
the
we're
getting
to
the
point
where
we're
adding
a
little
bit
too
much
so
the
template.
We
have
to
recognize
that
this
template
is
used
by
new
contributors
right.
Our
passer
buys
where,
if
you
have
a
wall
of
text
it
gets,
it
gets
a
little
harder
to
contribute
or
feel
like.
A
You
want
to
contribute,
because
there's
a
lot
of
information
that
you
might
have
not
have
the
appropriate
context
on
and
yeah
and
that
yeah.
So
in
an
effort
to
to
try
to
minimize
some
of
the
stuff
that
is
in
the
PR
template.
My
thought
was
instead
of
adding
yet
another
field.
We
recently
added
one
for
additional
documentation
round
caps,
that
we
add
a
label
for
kind,
deprecation,
right
and
the
label
for
kind
deprecation.
Would
then
we?
A
Obviously
we
do
some
magic
in
the
background
where,
if
you
were
issue
or
PR
has
a
combination
of
the
kind
deprecation
label,
as
well
as
a
release.
Note
that
release
note
becomes
a
deprecation.
It
right,
very
simple,
right
and
I
think
that's
that's
just
a
few
lines
of
code
to
write
in
really
so
that's
my
thought.
I
put
the
PR
up
so
that
we
could
start
the
discussion
about
it
because
I
think
we've
mentioned
it
in
a
few
release.
A
A
What
we
need
to
do
next,
because
I
think
we're
in
general
agreement
Bob
was
into
it
I
think
Gwen
was
also
plus
one
to
this.
The
next
thing
that
we
have
to
do
is
what
I'd
like
it
to
be:
is
a
global
label
right,
so
for
us
to
make
it
a
global
label.
We
need
to
have
a
global
discussion
about
this
right.
A
So
getting
this
on
the
on
the
sig
contributor
experience
agenda
and
yes,
absolutely
Josh,
so
the
the
perhaps
should
also
warn
if
a
PR
has
a
kind
deprecation
label,
but
no
release,
note
or
release
note
nothing
absolutely
so
this
all
of
this
should
be
fairly
easy
to
enforce.
All
we
have
to
do
is
have
a
larger
discussion
about
it
and
get
instead
of
lazy
consensus
date.
It's
already
been
LG
teamed
and
approved
by
a
bunch
of
people,
so
I
will
move
forward
and
set
a
dates
to
discuss
with
contributor
experience.
B
Or
idea,
maybe
kind
of
related
back
to
Maria
suggestion
on
release,
notes
and
needing
more
from
sig
leadership
and
core
reviewer
approver
type.
Folks,
you
were
talking
about
the
template
being
a
bit
of
a
wall
of
text
and
I.
Agree
like
the
more
we
want
structure,
the
more
throwing
that
in
the
face
of
the
contributor
themselves,
is
daunting
to
them.
B
But
maybe
we
need
like
a
reviewer
checklist
where
these
sets
of
things
are
documented
and
the
reviewer
could,
while
they're
looking
at
the
PR
separately,
have
opened
the
checklist
of
stuff
and
like
oh,
this
is
a
deprecation.
Let
me
add:
the
deprecation
label
like
the
it
doesn't
have
to
be
on
the
individual
contributor
to
add
all
of
the
things.
If
we
have
the
reviewer
approvers
on
board
for
the
consistency.
A
Like
this
I,
like
all
of
it,
I
like
the
fact
that
we,
we
then
put
the
onus
on
the
people
who
are
reviewing
and
approving
again
the
owners
of
the
code
for
being
responsible
for
making
sure
that
incoming
code
is
of
high
quality
or
incoming
documentation
is
of
high
quality
I
as
a
reviewer
approver
myself,
if
I'm
touching
a
PR
that
is
mislabeled
or
miss
sig
door,
miss
I
kinda
door.
What
have
you
I
try
to
correct
those
myself
and
then
also
drop
a
note
in
the
PR
that
says
like
hey?
A
This
actually
touches
this
piece
of
code,
so
it
should
be
blah
right,
so
kind
of
like
hey
we're
fixing
this
for
you,
but
in
future
just
be
aware:
that's
you
should
do
this
instead
right,
so
that
we
try
to
instead
of
making
ourselves
strictly
responsible
for
this,
we're
also
moving
some
of
this
responsibility
out
to
the
contributors
who
are
doing
it
too.
It
should
not
only
be
their
responsibility,
though,
so.
D
A
That's
I
mean
that's
a
tricky
piece,
I
mean
the
same,
is
it
could
be
said
for
the
like
kubernetes
sig
sig
leads
mailing
list
rate,
where
you
know
it's
one
of
those
things
where
we
send
out
an
additional
email
to
make
to
individual
to
individual
addresses,
to
make
sure
that
the
sig
leads
got
the
information.
So
it's,
if
you
are
part
of
a
kubernetes
org,
if
you're
part
of
the
kubernetes
org
or
one
of
the
sister
works,
kerbin,
86,
client
and
a
security.
What
have
you
my
expectation?
A
My
personal
expectation
is
that
you
are
reading
ke
dev
right
and
the
reason
for
that
is.
Our
membership
is
contingent
on
you
joining
ke,
dev
right
so
I'm.
You
know
transitively,
making
the
assumption
that
you
are
already
also
reading
the
stuff
that
is
landing
on
ke
dev.
If
you're,
not
that's
a
different
conversation,
Station
right
it
is,
it
is
in
our
membership
requirements
that
you
join
ke
dev
and
the
reason
for
that
is
because
we
send
stuff
to
ke
dev.
That
is
important
to
read.
H
A
Or
yeah
there
is
a
there
is
a
contributor
cheat
sheet.
I
wonder
if
it's
part
of
that
are
links
out
somewhere.
If
it
does
exist,
it
might
be
there.
If
not,
then
I
do
think
it's
something
reasonable
for
them
to
take
point
on.
Do
we
have
a
okay?
There
is
an
action
item
being
written
by
Tim
right
now.
Oh.
A
A
Okay,
all
right
well
I
have
one-
and
it's
also
related
to
somewhat
related
to
the
to
the
kind
deprecation
stuff
it's
there
was.
There
was
some
talk
and
I
linked
it
in
the
chat
just
now.
There
was
some
talk
about
another
PR
that
adds
a
code
block
to
capture
the
primary
sig
associated
with
the
PR
right.
I
am
NOT
a
strong
minus
one
to
this,
but
I'm
pretty
against
it,
because
I
feel
that
it
starts
to
confuse
people.
A
If
we
won
I
would
like
to
see
less
things
go
into
the
template
in
general,
and
are
we
going
to
make
this
a
requirement
for
people
to
list
primary
sig?
What
if
they
don't
know
what
the
primary
sig
is?
I
know
that
I
know
that
we
were
talking
about.
If
primary
sig
doesn't
exist,
then
it's
just
than
we
do
nothing,
but
essentially
the
idea
was
to
enable
a
primary
sig
field
within
the
PR
template
or
an
additional
label.
I
am
huge
one:
the
additional
label
for
primary
SIG's
so
that
we
can
capture
who
is
who's.
A
I
don't
know
so.
Sasha
was
saying
how
about
allowing
only
one
sig
for
PRS
right
by
default.
If
you
touch
yeah
exactly
Josh,
so
there
are,
we
have
so
many
interconnected
pieces
of
code.
I
think
it's
impossible
to
just
say
only
one
sake
does
only
one
piece
of
stuff
right
and
additionally,
we
have
sub
projects
that
are
listed
as
mostly
listed
as
areas
within
the
code
across
multiple
repos
that
represent.
Maybe
this
is
a
sub
project
or
a
working
group
that
works
across
multiple
SIG's
right.
A
You
know
something
like
something
like
Kate's
in
fro,
for
example
right.
That's
that's
something
that
could
potentially
touch
release.
Engineering
testing,
contributor
experience
like
a
few,
a
few
different
places,
so
I
think
it's
impossible
to
just
to
just
get
this
down
to
only
one
sig
right.
We
also
have
within
the
owners
files
you
can.
A
You
can
create
labels
right
or
you
can
list
labels
so
that
when
a
PR,
when
a
PR
has
created
that
touches
a
piece
of
code
within
the
scope
of
that
owners,
file,
it'll
automatically
get
labeled
as
that
sig
or
that
area
or
that
working
group.
Or
what
have
you
right?
So
I
think
it's
very
hard
with
the
current
system
that
we
have
to
drill
that
down
to
just
one
sig
and
I.
Don't
think
that
we
should
try
to
from
the
I
think
you
know.
A
Maybe
we
should
try
to
understand
what
the
goal
is
here
for
release
notes.
I
know
that
one
of
the
goals
is
to
make
it
easier
to
see
within
the
release,
notes
exactly
who's
responsible
for
something
or
you
know,
ipv6-
for,
for
example,
right,
that's,
primarily
Network,
but
it's
going
to
touch
known
and
it's
going
to
touch
off
and
it's
going
to
touch
a
bunch
of
different
places
right
so
Sasha.
Since
your
you
have
been
doing
release
notes
for
a
few
cycles.
You
want
to
talk
a
little
bit
about
this
yeah.
G
So
the
main
intention
was
to
provide
as
well
but
a
visibility
of
the
matrix
for
release,
notes
and
in
the
connection
between
the
physics
and
the
releases.
So
we
want
to
apply
it
an
automatism:
how
to
yeah
to
eat
the
release,
notes
as
which
Zig
introduced,
which
change-
and
this
is
currently
not
really
possible
and
makes
the
overall
quality
of
the
release
notes
really
not
I.
Think
so.
A
So
from
the
from
the
release
notes
website
today,
it's
I
mean
it
is
I'm.
Looking
at
it
right
now,
it
is
possible
to
just
kind
of
click
on
one
sig
and
see
what
they've
been
up
to.
So
what
additional
benefit
would
we
be
getting
by
introducing
this?
It
was
more
about
emotional
distance.
Okay,
do
we
feel
that
that
benefit
is
enough?
I
think
it
is
worth
introdu
introducing
potential
confusion.
H
Say
I
think
my
only
question
was
do
like
what
sort
of
problem
would
it
solve?
What
sort
of
value
would
it
adds
to
have
the
the
main
sink
of
contact?
If
you
want
them
their
release
note,
so
we
expect
that
people
will
look
at
it
and
then
go
and
ask
for
support
in
the
specific
feature
to
that
specific
sake
or
I.
Guess
what
was
the
the
ultimate
motivation
of
having
be
owning
sake
in
their
release,
notes.
A
G
H
G
A
Yeah
I
think
today,
what
we
do
is
it
essentially
if
it
touches
multiple
SIG's.
It
says
something
like
courtesy
of
signet
work
and
signal
ad
provider
and
sig
blah
blah
blah
blah
blah
blah
blah
right.
So
the
idea
was
was
I,
guess
having
something
that
was
more
clear
about
who
owned
what?
Even
if
multiple
people
were
involved,
but
if
we
cannot
discern
a
clear
motivation
for
doing
this,
we
we
shouldn't
do
it
if
someone
wants
to
come
up
with
very
clear
motivation
and
how
it
won't
be,
how
it
won't
create
pain
for
the
current
workflow.
A
We
are
yeah
if
I
agree
with
the
trash
that
they
deafer
trade
off
is
kind
of
bad
realize
that
when
we
do
something
that
touches
kubernetes
kubernetes,
we
touch
everyone
right.
So
if
we
were
to
you
know,
there
are
diminishing
returns
for
trying
this
in
a
place
like
kubernetes
release
or
sick
release,
because
it's
mostly
release
people
touching
that
work,
and
if
we
go
the
route
that
we
want
to
do
it
for
kubernetes
kubernetes
know
that
we
are
going
to
touch
over
everyone.
B
Do
we
have
any
stats
on
the
new
release
notes
website?
One
of
the
ideas
we
had
was,
if
we
don't
have
it
split
every
which
way
by
every
possible
categorization
in
the
static
markdown.
But
we
refer
off
to
the
website.
Then
people
can
dynamically
search
for
whatever
criteria
they're
interested
in.
In
that
moment,
I'm
wondering
if
people
are
finding
that
useful,
because
the
doctor
gave
us
a
path
to
further
simplify
in
the
markdown
file.
G
G
C
So
if
we
weren't
chopping
up
the
release,
notes
by
saying
what
would
we
be
chopping
them
up
by
otherwise,
you
have
a
list
of
a
thousand
release
notes
sorted
in
alphabetical
order,
which
I
don't
feel
it
improves
the
situation.
I
mean
obviously
people
using
the
interactive
tool.
You
can
categorize
them,
however,
but
for
the
version
that
goes
out
over
feeds.
G
C
Well,
I
mean
one
thing
that
would
be
obvious
because
I
mean
I'll
actually
put
it
right
out
there,
that
dividing
the
release.
Notes
up
by
sig
is
not
a
benefit,
a
strong
benefit
for
non
contributor
users
like
people
who
don't
contribute
to
kubernetes,
don't
understand
our
sig
system
and
they
don't
care
I
mean
they
vaguely
understand
that
things
and
sig
networking
might
from
sig.
C
C
A
Yeah
I
think
it's
a
matrix
of
things
that
people
would
care
about
it
at
any.
One
point
like
what
I,
maybe
like
I
personally
I,
have
very
low
need
to
review
the
release.
Notes
right.
I
do
I,
do
a
sweep
when
the
the
drafts
come
up
but
I
like
I'm,
not
so
much
a
consumer
of
kubernetes.
Then
you
know
one
of
the
gremlins
working
in
the
background
to
make
sure
it
works.
So
so,
like
I,
don't
have
it
like
if
I
care
about
a
you
know
a
deprecation
or
a
new
process.
A
A
A
A
A
Is
tolerable
I'll
mention
this
in
the
release
team
meeting
as
well,
but
we
need
more
reviewers
on
that
PR,
the
kind
application
label
we
mentioned,
quick
one
on
intervene
in
creasing,
the
intervals
that
our
test
build
jobs
run
at.
That
is
a
quick
one
to
approve.
If
anyone
wants
to
look
at
that,
I
did
some
rearranging
of
the
dashboard
configs
to
make
them
less
bad.
A
A
All
we
figured
out
all
to
change
a
version
number
within
the
api's
spec
and
it's
something
that
could
just
be
done
with
a
search
and
replace
or
not
done
at
all,
so
there's
PR
to
remove
that
from
branch
fast
forward
and
with
that
so
again,
if
anyone
wants
to
review
some
of
those
PRS
feel
free
with
that
we're
going
to
jump
over
to
people
who
are
involved,
jump
over
to
the
Grenadiers
release
team
meeting
thanks
a
lot.
Everyone
later.