►
From YouTube: Kubernetes SIG Release Meeting 2019-01-15
A
So
we
are
a
minute
or
so
past.
I
know
that
steven
augustus
needs
to
leave
early,
so
I'm
gonna
go
ahead
and
get
started.
This
is
the
january
fifteenth
twenty
nineteen
sig
release
meeting
this
meeting
is
being
recorded
and
we'll
post
it
to
youtube.
Just
after
the
meeting
we
asked
that
everybody
please
adhere
to
the
project
code
of
conduct
and
be
good
people.
A
C
C
I
get
all
choked
up
talking
about
this.
Over
the
past
three
weeks,
James
and
I
had
been
tracking
down
a
flake
that
was
pretty
persistent.
I
was
seen
across
multiple
release,
branches
and
Dems
recalled
it
to
a
regression
that
came
in
as
part
of
some
fix
up
of
panic
handling,
and
maybe
the
I
server
that
panic
handling
fix,
got
picked
all
the
way
back
to
release
110,
and
so
this
regression
is
present
in
the
110
111,
112
and
113
branches,
and
so
the
fix
was
well
understood.
C
It
was
tiny,
it
was
able
to
be
proven
out.
It
is
picked
back
all
the
way
to
111
and
the
question
is
what
to
do
with
110,
because
the
the
regression
was
introduced
into
the
last
patch
release,
the
last
planned
patch
release
of
110,
and
so
shortly
the
CI
for
110
would
be
dismantled,
and
once
that
happened,
there's
kind
of
no
going
back
getting
the
processes
spun
back
up
to
validate
110
releases
would
be
prohibitive,
but
we
have
the
option
to
use
the
CI
that
is
still
in
place.
C
All
the
CI
is
still
in
place
and
is
green
and
make
a
single
commit
release
to
fix
this
regression.
The
open
question
project
release
is
our:
do
we
want
to
make
an
exception
to
our
three
release?
Support
policy,
given
the
consideration
that
we
have
CI
still
in
place
that
hasn't
been
dismantled,
yet
this
is
fixing
a
regression
that
was
introduced
to
110,
it's
not
taking
a
new
feature
or
a
new
bug
fix
and
back
porting
it.
B
So
I'm
in
favor
of
picking
it
back,
it
sounds
like
it's
small
and
contained,
and
you
know
what
fixes
I
think
we
should
do
all
we
still
have
the
ability
to
do
it.
I
think
most
of
the
people
who
were
on
the
thread
are
in
favor
of
it
as
well,
but
I'll
not
speak
for
anyone
else
in
what
everybody
else
shut
out.
I
feel.
A
C
I
think
the
the
concern
was,
we
have
already
been
I'm
kicking
proposed
changes
to
110
out
like
between
just
December
and
now
saying.
No.
That
was
the
last
release.
To
be
fair.
All
of
the
changes
I'm
aware
of
that
we're
being
proposed
for
110
did
not
fit
these
criteria.
They
were
new
things,
new
bug,
fixes
and
things,
but
that
was
the
confirm.
Yes,.
B
D
E
D
C
B
Of
it
in
this
case,
so
just
just
a
Ben's
point,
I
know:
Jordan,
you've
been
you've,
been
rankling
like
a
Herculean
effort
around
making
sure
that
people
know
what
we
shouldn't
shouldn't
be
doing
and
with
regards
to
support
versions
and
different
things
like
that,
can
we
have
someone,
that's
tasked
with
making
sure
that
it's
very
explicit
in
our
documentation
that
we
won't
be
doing
this
moving
forward,
and
this
is
a
exception
case.
I.
C
D
Good
I
also
want
to
suggest
real
quick
that
we
might
maybe
include
the
timeline
for
which
we
are
spinning
down
all
this
stuff
as
part
of
how
we
would
be
deciding
this
going
forward
like.
Maybe
if
a
patch
is
critical
enough
and
it's
before
we've
shut
down
everything,
then
we're
going
to
accept
it
or.
D
A
F
C
D
G
C
F
H
H
C
Other
point
I
wanted
to
call
out
and
I'm,
not
sure
where
the
best
place
to
put
this
is,
but,
as
we
are
preparing
to
cut
the
final
patch
release
in
a
branch,
you
probably
want
to
look
very
carefully
at
the
changes
that
come
in.
I
can
say
this,
because
I
was
the
one
that
actually
picked
this
back.
So
it's
on
me
this.
This
was
my
bug
that
I
wrote,
but
knowing
that
we
don't
have
another
patch
release
coming
where
we
can
fix
a
regression
or
we
should
not
expect
you
to
have
one.
C
B
It
needs
to
be
in
an
even
more
visible
place.
That
is
not
the
handbook.
Specifically.
The
handbook
can
link
out
to
this
place,
but
the
place
needs
to
be
discoverable
for
people
who
are
not
patch
managers
who
are
not
branch
managers
so
that
everyone
can
be
aware
of
it,
so
whether
that
is
I,
guess
the
root
of
sake,
release
or
the
root
of
the
release,
team,
repo
or
something
or
maybe
community,
but
but
it
can't
be
buried
in
an
book.
G
I,
actually
I
I
am
very
conflicted.
I
actually
would
love
to
see
us
do
this
fix,
but
I
also
feel
that
we
do
have
a
policy
and
we
are
pushing
the
boundaries
in
a
way
that
maybe
negates
some
of
the
virtue
of
the
policy
like
we
have
a
policy
and
whether
or
not
I
agree
with
that
I
feel
like
we
should
stick
to
it
as
much
as
I
would
like
to
see
us
extend
that
policy
or
soften
that
policy.
I
feel
like
it's
gonna
be
hard.
It
sets
a
precedent.
G
B
B
H
So
that's
at
least
two
weeks
since
the
release,
and
then,
if
you
throw
on
another
two
weeks
for
I,
don't
know
just
being
nice
or
whatever
I
do
have
concerns
about
the
precedent
that
it
sets
I,
I'm,
okay,
being
pragmatic
and
suggesting
that
it's
this
really
squishy
sliding
window
that
actually
turns
into
will
cut
will
cut
four
versions
back,
but
only
within
the
first
six
weeks
of
the
release
life
cycle
of
the
current
needed
in
development
Christian.
But
that
seems
a
lot
comfort
to
summarize
I
feel,
like
Jordan
has
spent
so
much
time.
C
D
C
C
On
a
previous
patch
release
in
that
release
branch
they
upgraded
and
they
encountered
this
bug
and
the
size
of
the
fix
and
risk
of
the
fix
is
negligible.
Those
three
to
me
seen
if
all
three
of
those
things
are
true
I
would
be
inclined
to
accept
a
fix
and
the
one
where
it
is
a
the
CIA
is
still
in
place
like
the
we
don't
want
to
maintain
these
indefinitely,
and
so.
C
C
B
I
think
so
I
think
that
we
can
also
use
the
having
the
CI
branches
available
as
a
forcing
function.
If
we
restrict,
if
we're
stricter
about
the
tear
down
of
the
CI
branches,
and
when
that
happens
and
the
schedule
is
visible
to
the
public,
then
we
can.
We
can
back
out
and
say,
hey
like
well,
we
don't
even
have
the
CI
to
do
this
right
now.
So
sorry,
yeah.
I
To
a
CI
and
the
introduction
in
a
patch
so
saying
it
doesn't
exist
on
the
release,
Rico
introduced
us
in
a
patch,
so
those
two
specific
requirements
completely
trusted
or
on
a
future
discussion
of
a
security
vulnerability
that
wasn't
introduced.
You
know
in
a
patch,
I
guess
and
I
would
argue
that
we
had
CI
and
that
the
ability
to
patch
a
security
issue
that
happened
to
be
introduced
in
a
patch.
Then
we
should
do
that
and
they
would
follow
this
precedent
as
well.
A
I
think
that
the
the
only
way
this
becomes
precedent
is,
if
we
don't
clarify
an
established
policy
there.
So
I
was
just
going
through
the
pet
release
manager
as
I'd
done,
the
the
113
to
release
and
and
did
a
big
update
to
it.
But
one
of
the
things
that
surprised
me
is
we
actually
give
guidance
to
the
patch
release
manager
that
they
can
accept,
features
that
there's
historical
precedent
for
it,
if
it's
just
for,
say
a
cloud
provider.
A
H
G
B
Think
I
think
that's
fine,
so
yeah
so
I
think
we're
all
kind
of
saying
the
same
stuff
we
need
to
right
now
the
documentation
is
not
sufficient.
We
do
don't
have
sufficient
criteria
to
specifically
say
whether
or
not
something
gets
in
or
gets
out.
We
need
to
document
it
I
think
we
have
enough
information
to
document
it
at
this
point
and
someone
who
wants
to
put
up
with
the
art
until
we
do
that,
but
I
think
we
should.
We
should
move
on
where.
A
B
You
mind
if
I
cut
in
real
quick,
sorry,
so
just
release
team
related
things
or
things
that
I've
had
on
my
plate.
The
shadows
questionnaire
is
out.
It's
live.
It's
going
to
be
up
until
I
want
to
say
the
end
of
Thursday
Eastern
Time,
so
that
we
have
enough
time
to
get
the
full
survey
results
over
to
the
current
release.
114
release
team
we're
getting
lots
of
lots
of
lots
of
responses,
so
I
want
to
get
an
early
version
of
that
out
to
the
release
team
as
well.
B
I'm
gonna
be
working
on
that
tonight
since
tweeting,
it
I
think
we
are,
responses
have
almost
doubled
and
that's
probably
still
going
so
it
so
I
think
cutting
it
off
soon
is
probably
a
good
idea.
There
have
been
discussions
across
multiple
SIG's
at
this
point:
sega
architecture,
stadium,
cig
apps
and
a
few
others
around
caps
are
going
to
be
mandatory
for
this
release.
Cycle
aaron
is
as
he
as
he
quoted
a
bull
in
a
china
shop
about
getting
this
done.
B
I
am
totally
on
board,
so
we're
gonna
be
working
on
making
sure
that
the
documentation
is
up
to
snuff,
to
allow
people
to
do
that
and
caps
that
are
in
caps
that
are
in
implementable
states
are
the
ones
that
will
be
accepted
outside
of
that
I
think
I'm,
yeah,
okay,
alright,
subprojects,
that's
a
quick
update
on
my
side!
Oh.
H
So.
The
idea
is
based
on
like
what
exists
today,
what's
called
out
in
the
sake
release
community
repo.
Today
in
60
mo
there
are
four
sub
projects.
There's
hypercube
because
reasons,
there's
release
team,
because
that's
the
bulk
I
guess
of
what
we
do.
There's
the
publishing
bot,
because
I
asked
that
the
publishing
bot
not
belong
to
sig
testing
and
release
volunteered
to
accept
it,
and
the
sub-project
owners
agreed
that
sig
release
was
the
best
home
and
then
sig
release
the
repo,
which
is
like
all
of
your
documents
and
administrivia.
H
H
That
was
one
of
the
sub
projects
that
was
proposed
by
by
us
back
in
October,
because
the
release
team
is
super
busy
and
dedicated
to
shepherding
and
stewarding
all
of
the
bits
into
the
right
place,
but
there's
definitely
a
lot
of
machinery
around
actually
cutting
a
release,
and
there
is
an
interest
I
think
in
trying
to
identify
all
of
the
areas
that
can
be
D
Google.
If
I'd
such
that
one
day,
maybe
a
non
Googler
can
be
involved
in
every
single
part
of
the
process.
H
I
also
raise
this
project
up
because
there
is
interest
from
members
of
the
community
to
step
up
and
contribute
to
automatically
cutting
Debian
and
RPM
packages
for
each
release
that
we
published.
This
came
up
during
the
LTS
working
group
discussion
at
the
coop
con
summit,
where
I
got
to
jump
up
and
down
and
say:
yay
we
publish
alphas
and
betas
every
two
weeks,
but
for
people
who
stand
up
kubernetes,
but
the
cuvette
DM
tool.
No,
we
don't
because
they
don't
consume
raw
bits.
They
consume
a
package.
H
So
there's
like
the
group
of
people
who
are
motivated
to
solve
that
problem
and
like
make
kubernetes
kubernetes
the
canonical
location
of
the
artifacts
that
describe
how
to
build
these
packages.
That
to
me
feels
like
a
sub
project
called
the
release
engineering
sub
project
that
falls
under
sic
release.
H
So
if
I
take
a
look
at
the
current
set
for
learners
files
that
describe
the
release
team
sub
project,
I
feel
like
splitting
that
up
into
such
that
the
owners
files
in
the
release
repo
corresponds
to
the
release:
engineering
team,
and/or,
the
release,
engineering
sub
project
and
the
owners
files
in
the
release
team.
Subdirectory
of
the
sake,
release
repo
corresponds
to
the
release
team
sub
project
yeah.
B
So
yeah
I
totally
agree
with
everything.
Erin
said:
I
think
that
the
release
engineering
sub
project
is
long
overdue.
I
think
we've
mentioned
it
quite
a
few
times
on
the
sick
release
meetings
and
what
we're?
What
we
need
is
the
so
I
believe
Tim
and
Alexandre
are
already
kind
of
working
on
the
I.
Think
I've
seen
a
PR
today
around
the
the
bits
and
pieces
are
at
a
four
branch,
management
and
patch
release
management
for
the
release.
Team
I
see
the
the
release.
Engineering
sub
project
is
having
multiple
roles.
B
Some
people
who
sit
is
branch
managers
or
patch
release
managers
who
can
exist
and
and
kind
of
touch
bits
for
all
of
the
releases.
So
it's
not
just
on
a
singular,
singular
person
to
to
be
responsible
for
those
kinds
of
things.
That's
kind
of
the
reason
that
the
patch
release
management
team
as
a
team
I
started
standing
up
so
that
that
team,
but
the
patch
release
management
team
in
the
branch
managers
would
sit
kind
of
in
between
release
engineering
and
and
the
release
team
right.
B
They'd
have
a
role
on
the
release
team,
but
also
be
part
of
the
release.
Engineering
sub
project,
so
there's
lots
of
interest
for
this
I
think
that
we
need
documentation.
That's
the
next
step.
I
know
that
Tim
is
already
working
on
that
stuff.
I
would
I
know
that
there's
a
bunch
of
interest
on
polling
at
least
Red
Hatters
and
pulling
vmware
people
and
people
who
have
deemed
me.
So
I
want
to
get
this
started.
I
want
this
to
be
up
for
February.
If
that
sounds
cool.
B
D
Well,
I
would
actually
probably
suggest
that
those
teams
are
going
to
be
staffed
by
fairly
different
people
on
like,
for
example,
pulling
in
the
past
for
release,
leads
I.
Think
most
of
the
release
leads
are
not
going
to
be
like
active
leak,
hacking
on,
say
and
I
go
versus,
maybe
hoping
to
just
kind
of
push
the
releases
out
the
door
and
so
forth.
Oh
for.
B
H
Although
the
point
I'm
trying
to
drive
towards
is
like
getting
some
single
points
of
contact
or
single
owners
to
start
shepherding
these,
these
efforts
forward,
rather
than
Stephen
having
to
talk
about
each
and
every
one
of
these
things
so
copiously,
but
quite
well.
So
that's
why
soomi's
attending
he.
H
Sorry
if
I'm
pronouncing
your
name
wrong
man,
but
he's
cut
the
Debian's
for
a
number
of
the
releases
of
kubernetes
as
a
Googler
and
would
be
interested
in
identifying
one
of
the
things
that
we
can.
You
know
do
to
hand
this
over
to
the
community.
What's
what's
the
work
that
needs
to
be
done
and
then
can
we
drive
that
work
to
done
and
so
I'm
looking
for
people
to
kind
of
do
that
and
call
that
the
release
engineering
effort.
J
I'm
very
much
interested
in
getting
that
process
out
of
Google's
hand
and
given
into
community,
because
I
think
that's
one
step
where
the
past
releases
managers
had
to
reach
out
to
Googler
to
ask
for
generating
the
Debian's
and
rpms
and
since
I've
done
this.
The
last
few
times,
I
I
feel
the
pain
of
the
first
release
manager.
So
it
would
be
good
to
have
that
with
the
community
as
opposed
to
Google.
B
So
can
I
so
for
everyone,
that's
on
the
call
and
everyone
who
might
be
viewing
the
call
later.
Can
we
take
it
as
an
action
item
for
all
of
us
to
kind
of
reach
in
internally
and
and
talk
to
some
of
the
people
who
have
experience,
doing
release
engineering
work
and
see
if
they
would
be
interested
in
this
kind
of
effort?
B
H
Totally
fine,
what
I
would
like
to
do
to
get
the
ball
rolling,
though,
is
to
like
call
these
things,
distinct,
sub
projects
and
call
out
to
the
in
the
donors
files
as
I
have
proposed
in
the
document
here,
so
I'll
open
up
a
pull
request.
This
is
just
my
sanity
check
that
those
things
that
I
proposed
are
saying,
because
to
follow
on
from
that,
there
were
two
other
sub
projects.
I
think
that
Steven
brought
up
when
I
mentioned
this
licensing
is
definitely
one
of
them.
B
H
B
So
I
guess
so:
I
added
I
added
leads
here:
I'm
highlighting
a
no
machine
right
now.
Okay,
so
what
you
can
do?
What
I'm?
Imagining
for
each
of
the
sub
projects
is
that
we
just
have
a
sub
directory
within
SiC
release
unless
they
have
their
own
repo,
okay,
I
think
so.
The
way
that
release
team
already
has
their
own
subdirectory.
We
would
continue
moving
forward
like
that.
What's
release
engineering
and
licensing
and,
like
I,
think
PST
has
their
their
own
repo
I
know:
they're,
not
a
sub-project
I,
don't
know
what
they
are.
H
H
B
A
A
Think
it's
TBD
I
would
say,
leave
that
stuff
for
now
it's
something
that
I
want
to
push
on,
but
also
when
it
was
coming
up.
Eight
months
or
so
ago,
PST
was
sort
of
four
people's
names,
as
opposed
to
what's
become
a
little
bit
more
formalized
and
operational
and
growing
as
a
broader
team.
So
I
don't
know
if
at
what
point,
maybe
that
comes
under
their
purview
but
still
from
the
tooling
and
release
perspective.
We're
always
gonna
have
something
that
I
think
is
desired
on
our
part.
But
it's
just
it's.
B
So
I
I
don't
think
that
it
maybe
specifically
and
asked
here,
but
the
the
PST
I
don't
know
like
what
the
governance
structure
is.
It
essentially
exists
outside
of
the
kubernetes
governance
model
right
so
like
they
have
their
documentation
and
sake,
release,
but
I
don't
know
who
is
supposed
to
own
them
or
if
they
have
ownership.
H
C
H
D
G
Samesies
I
think
one
of
the
issues
I've
had
with
understanding
them
is
that
they
are.
They
are
a
incident
response
team
and
therefore
are
privileged
in
some
ways,
and
it's
not
open
is
a
the
one
thing
if
it
is
not
open,
but
they
there
are
other
things
that
come
into
the
security
umbrella
which
are
you
know,
like
are
certain
things,
a
good
idea
from
security
point
of
view,
and
there
is,
as
far
as
I
know,
no
great
forum
for
that
single
with
has
graciously
accepted
some
of
that
mantle.
G
H
So
that's
that
I
think
to
Justin's
point
like
there.
So
there's
a
working
group,
that's
going
to
do
a
security
audit
and
there's
the
you
know
the
incident
response
team,
that
is
the
product
security
team,
but
like
where
is
the
group
of
people
who
care
about
all
things
security
related?
Is
that
sub
project
of
sake
release?
Should
that
be
its
own
sake?
Should
that
be
another
working
group
I,
don't
know
and
I'm
okay
tabling
back
but
I
I
agree.
It's
a
it's
an
unknown.
Okay,.
B
Let's
look:
let's
roll,
let's,
let's
roll
on
that,
so
I
I
have
to
pop
off
in
a
bit
I'm.
Sorry
about
that.
But
my
thoughts,
at
least
for
the
sub
projects
are
for
the
things
of
organization
that
kind
of
fit
under
sig
release.
So
we've
got,
we've
got
LCS,
it's
a
working
group.
We
are
going
to
spin
up
release
engineering
in
the
super
near
term
and
I
believe
and
I
think
that
each
of
the
projects
that
hand
are
the
sub
projects.
B
Currently
that
handle
bits
like
hypercube
publishing
got
all
that
stuff
should
roll
under
release
engineering
just
to
make
that
super,
simple
and
and
then
licensing
licensing
in
the
release
team
right.
So
release
team
is
kind
of
well
formed
at
the
school
and
we
have
owners
and
we
have
documentation
and
all
that
good
stuff
licensing
is
one
of
the
outliers
which
I
will
I'll.
Take
that
on
sorry,
I
have
to
blast
of
y'all
later.
D
A
That's
for
a
long
time,
that's
been
part
of
the
conversation
I
believe
if
we
put
some
like
it,
there's
a
chicken-and-egg
here
right.
If
you
have
very
little
documented.
Nobody
knows
what
they're
volunteering
for.
But
if
you
put
too
much
time
into
the
document
too
much
it's
premature,
optimization
and
maybe
if
the
volunteers
don't
show
up
either
so
I
I
think
we've
got
to
do
something
versus
nothing
and
then
see
where
some
of
these
go
and
is
supposed
to
formalizing.
A
Steve
Greenberg
who's
on
the
call
for
the
first
time
today,
I
think
today
also
somebody
who
popped
up
at
cube
con
in
Seattle
and
similarly
interested
in
and
doing
some
support
there.
Okay,
I
am
move
on.
The
next
thing
on
the
agenda
is
just
an
FYI.
We
are
on
the
Thursday
community
meeting
calendar
for
a
cig,
update
on
January
31st,
that's
two
weeks
out,
but
if
there
are
things
that
folks
feel
should
be
brought
up
there,
let
myself
Steven
and
Caleb
know
we'll
make
sure
they
get
covered.
A
Some
of
the
stuff
that
we've
just
talked
about
I
think
will
be
good
too
up
there.
The
sub-projects
I
wanna
shift.
What's
on
here,
just
slightly.
What
do
we
have
we're?
Oh,
do
I
want
to
almost
hit
we're
nearing
the
end
of
our
time
slot
and
we've
pushed
part
three
of
the
release
retrospective
and
pushed
it
and
pushed
it,
and
there's
like
three
or
four
bullets.
There
do
folks
want
to
discuss
them
formally
right
now
and
call
it
done
or
what,
if
people
think
I.
K
K
Hello,
everybody,
my
name
is
Linus
Sarver
I'm,
releasing
Google,
so
basically
I
added
to
the
agenda,
a
link
to
the
cap
that
discusses
the
image
promotion
process
that
will
hopefully
kind
of
like
take
over
the
current
process,
which
is
to
my
understanding
some
special
Googlers
pushed
up
to
Kate's
dodgy
CIO,
so
it's
kind
of
like
hidden
behind
this
Google
wall,
and
my
hope
is
that
that
wall
gets.
You
know
abandoned
so
that
we
have
some
sort
of
open
process
around
how
images
get
become.
You
know
like
knighted
or
promote
it
to
be
official
images.
K
So,
like
that,
should
all
happen.
You
know
in
the
open
right
like
there's.
No
reason
why
we
have
this
thing
that
happens
behind
Google's.
You
know
hushed
doors
at
Google,
so
the
kept
has
the
overall
idea
I
just
submitted
and
got
approved
this
tool
called
the
container
image
promoter,
which
is
a
small
piece
of
that
overall
plan.
K
K
If
there's
like
any
strong
opinions
about
you
know,
is
this
a
bad
idea
or
something
or
is
there
like
strong
pushback
from
anybody
because,
like
I
would
like
to
know
because
I've
only
heard
like
people,
at
least
at
Google,
saying
yeah,
that's
a
great
idea
like
I
just
wants
to
like
double-check,
you
know
and
see
what
other
people
think
outside
of
Google.
So
yeah,
that's
my
spiel.
H
One
question
that
came
up
in
the
context
of
the
Cates
in
for
a
working
group
was
whether
or
not
we
were
trying
to
advocate
for
everybody
to
use
like
a
blessed
GCR
repo
or
whether
we
were
thinking
of
a
model
where
people
could
push
their
container
images
wherever
is
convenient
for
them.
And
then
we
use
our
tool
to
pull
down
from
that
or
whether
we're
talking
about
something
like
for
all
of
the
six
sponsored
projects.
Would
we
would
be
taking
on
the
notice
of
creating
a
GCR
repo
for
them
or
something
to
that
effect?
H
K
D
Yeah
I
would
still
suggest
that,
like
we
want
to
sync
things
a
little
bit
differently,
like
you
probably
want,
like
official
court
images
to
be
hosted
a
little
bit
differently
from
like
SIG's,
totally
random
project,
for
other
reasons
or
like
even
like
mirroring
or
things
like
I'd,
probably
want
a
registry.
That's
kubernetes,
not
a
million
other
things.
I
mean
there's
I
think
this
is
a
totally
separate
discussion
for
whether
or
not
we're
okay
with
witnesses,
tool
and
model,
though,
and
I
will
add
that
we're
using
it
today
and
I.
D
D
A
H
I'm
fine
proceeding
with
this
with
calling
that
other
stuff
out
of
scope
and
we
can
figure
out
how
to
revisit
that
later.
It
was
just
yeah,
cuz
I've
seen
a
number
of
asks
from
like
clustering,
API
provider
projects
or
cloud
provider
projects
they're
like
we
have
images
that
we
want
to
build
and
push
someplace.
Do
you
have
that
thing
and
it's
unclear?
No,
we
kind
of
don't
so
just
trying
to
figure
out
what
we
can
leverage
to
help
with
that
and
I
think
it's
too
early
to
use
this
for
that,
but.
D
Thank
you,
that's
all
I
have
I
would
say
I
seriously,
think
that
we
should.
This
is
a
really
really
really
good
process
that
we
should
use
for
all
those
other
things,
but
we
should
figure
that
out
after
we
get
it
out
and
running
for
the
core
images,
and
we
had
that
today
and
that's
really
nice,
but
it's
not
nice,
because
it's
super
internal
and
it
has
to
be
approved,
super
internally
and
it's
not
transparent
and
that
this
is
what's.
This
is
what's
controlling.
K
E
E
G
H
One
thing
I
want
to
add
on
that
is
the
argument
I
was
making
is
like
Zig
release
has
a
number
of
dashboards
under
its
group.
Many
of
them
are
of
the
form
say,
grilli's
branch
adjectives,
those
are
all
dashboards.
The
team
is
interested
in,
but
I
just
talked
about
a
whole
bunch
of
other
sub
projects.
We
might
want
to
do
like
all
of
the
tools
in
kubernetes
release,
IG
I,
wonder
if
those
have
any
unit
tests
you
can
unit
test
bash
anyway,
like
maybe
those
need
their
own
dashboard,
and
so
there
is
a
sig
release.
H
Misc
dashboard
with
a
couple
things
show
up
now
and
I
was
just
suggesting
like
maybe
we
keep
that
around
for
for
those
until
they
mirror
their
own
dashboard.
One
other
release
blocking
criteria
is
that
all
jobs
should
have
owners
and
those
owners
should
get
alerted
when
those
jobs
fail
continuously,
and
we
want
to
signify
this
by
having
email
addresses
used
in
the
test
grade
config,
so
that
people
will
actually
get
email,
preferably
those
email
addresses
will
belong
to
Google
Groups,
so
that
are
publicly
visible
and
auditable,
and
more
than
a
single
person
gets
spammed.
H
As
I've
started
digging
into
this,
one
of
my
concerns
is
that
a
lot
of
jobs
fit
one
of
two
patterns.
One
is,
they
are
build
jobs
and
it's
kind
of
unclear
to
me
it's
unfortunately,
it
seems
like
the
people
who
have
the
most
expertise
on
those
build.
Jobs
live
in
sync
testing,
not
sync
release,
even
though
to
me
the
building,
if
it's
kind
of
belongs
to
Sigma
release.
H
H
It
seems
kind
of
arbitrary
to
assign
any
one
sink
to
own
that,
but
I
still
kind
of
do
want
to
assign
one
sink
to
be
the
point
of
contact
to
then
like
go
figure
out,
which
you
know,
which
sig
owns
the
test,
that
they
should
go
bug.
So
my
proposal
would
be
if
those
jobs
move
on
the
sink
release,
dashboards,
that
it's
sink
releases.
H
Responsibility
to
go
bug
people
to
keep
those
jobs
green
for
those
jobs
that
don't
clearly
belong
to
like
a
single
feature,
that's
owned
by
a
single
sig
or
something
I'm
kind
of
proposing
the
umbrella
of
build
related
jobs
go
off
to
sink
testing.
Unless
y'all
tell
me
you
should
they
could
notice
a
release
and
have
to
build
people
why
that
and
I'm
suggesting
the
umbrella
test
jobs
like
integration,
testing
e
to
e
testing,
that's
just
really
vague
and
not
feature
specific,
should
also
go
to
sig
release
and
be
delegated
off
accordingly.
D
A
H
That
sounds
an
awful
lot
like
CI
signals
responsibility,
and
so
we
we
put
Maria's
email
address
and
all
the
tests
gear
and
things
no
I
think
that's
that's,
maybe
not
ideal,
but
it
could
be
like
Maria
and
the
CI
signal
shadows
get
subscribed
to
a
Google
Group.
That
represents
the
CI
signal
role
for
this
release,
and
that's
who
gets
notified
sounds
like
like
I'm
having
a
brainstorm
this
on
a
PRT,
but
I
just
wanted
to
ask
people's
opinion
in
this
high
bandwidth
media
to.
E
A
The
idea
of
group,
as
opposed
to
on
the
shoulders
of
person,
but
it
also
still
has
to
be
actively
owned.
It
can't
be
like
hey
somebody
in
the
group
is
gonna:
do
it
having
a
lead,
is
role
time-boxed
or
somebody?
Maybe,
for
that
period,
is
setting
up
the
filter
so
that
they
get
a
little
more
high
priority
interrupt
on
the
things,
as
opposed
to
the
tragedy
of
the
Commons
I
think
that
direction
is
is
useful.
A
E
E
Is
that
as
far
as
I
know,
there's
no
centralized
way
to
audit
this,
and
so,
as
a
result,
I
find
things.
Certainly
when
I
would
see
a
signal
and
I
was
pestering
people
via
a
lot
of
the
aliases
for
failures.
I
would
find
out
that
all
of
the
people
in
a
particular
group
had
left
the
kubernetes
project.
H
Yeah
I'm
treating
github
groups
as
devil
as
github
notifications-
don't
work
for
me,
so
why
should
I
expect
them
to
work
for
anybody
else?
You
know
so
I'm
hoping
that
email
works
better
and
it's
I'm
purely
leaning
on
the
fact
that,
like
tests,
good
supports
learning
to
email,
so
I
can
have
the
bot
I
can
have
automation
start
that
conversation
see
where
that
goes.
H
E
H
Was
just
gonna
say
one
of
the
other
advantages
of
using
a
public
google
group,
as
you
can
like,
we
could
start
to
act
on
here's
one.
The
notification
went
out
and
one
was
it
responded
to
not
that
I'm
proposing
any
handedness
about
that
mouth,
but
I
am
trying
to
think
about
like
metrics
that
we
can
use
for
all
of
our
release.
Blocking
criteria,
including
responsive
to
test
failures,
yeah.
D
I
spoke
about
this
a
lot
at
cute
with
some
people,
including
Aaron,
and
it's
still
kind
of
if
he
liked
how
we
can
act
on
that.
But
if
we
use
something
like
a
group,
you
can
go
and
look
and
say:
okay,
they
got
a
notification
this
day
and
here's
three
weeks
later
and
no
one
has
touched
it.
We
need
to
update
this
group
or
the
sick,
isn't
owning
their
stuff
or
something
how
we
handle
that
maybe
isn't
solved
yet.
H
All
that
said,
Josh
really
happy
that
you're
taking
this
on
it's
something
I
care
deeply
about
and
as
I
get
more
bandwidth,
you'll
see
more
of
my
involvement.
There
I
apologize
if
I
get
overly
pushy.
That's
just
my
bull
in
the
china
shop
that
is
test
grid
and
Maria
I
feel
I
kind
of
look
more.
Take
you,
as
the
lead
I
will
defer
to
your
opinion
on
things
that
make
your
life
easier
as
the
CI
signal
for
this
release.
Luz.
E
L
Sounds
good,
quick
thought
on
what
you
just
talked
about
a
couple
of
things
that
spot
that
popped
to
mind
on
first
a
hard.
No
on
putting
my
email
address
as
a
contact
I
mean
we
can
always
I
guess
like
go
for
an
implementation
and
see
how
that
works
out
and
and
it's
right
from
there,
it
doesn't
have
to
be
like
whatever
we
end
up
going
for
now.
L
H
Consider
retro,
a
very,
very
important,
were
part
of
the
release
process.
I
found
us
with
about
30
minutes
to
spare
at
the
end
of
the
last
release
team
meeting,
so
I'm
happy
to
provide
some
room
for
that
that
at
the
next
release
team
meeting,
my
continual
ask
here
is
the
value
of
the
retro
is
what
we
decide.
We
will
do
differently
as
a
result
and
I'm
a
little
worried
that
I'm
the
only
person
who's
gone
through
and
created
action
items.
My
name
is
on
all
of
them.
H
My
name
is
not
the
only
name
on
some
of
these,
so
I
really
appreciate
those
people
who
are
helping
out
with
some
of
the
other
things,
but
truly
the
most
productive
part
of
the
retros.
What
did
we
learn
and
well?
How
can
we
do
better
as
a
result?
So
if
there
are
things
there
that
you
feel
strongly
about?
Let's
prioritize
talking
about
that
at
the
next
release
team
meeting
and
there's
nothing
stopping
you
from
digging
through
the
stock
and
opening
up
issues
to
be
done.
Yes,.