►
From YouTube: Kubernetes SIG Release Meeting 20180605
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
Welcome
everybody:
it
is
Tuesday
June,
5th
2018.
This
is
the
kubernetes
release
special
interest
group
I
am
your
co-lead
Jason,
singer
kumar's,
and
if
you
want
to
follow
along
after
the
fact,
the
agenda
is
available
through
a
long
URL.
That
is
not
could
be
any
more
to
recite.
So
yeah
hop
on
the
cig,
release
slack
channel
and
will
will
drop
you
a
link
to
the
agenda
there
without
further
ado
we're
going
to
go
ahead
and
get
into
the
agenda,
and
today
we've
got
a
relatively
full
agenda
and
also
I
want
to
welcome
some
new
people.
A
A
Well:
okay,
there
are
new
people,
apparently
they're,
not
excited,
but
that's
okay.
I
mean
this
is
the
most
exciting
sake.
I
have
to
tell
you
so
other
things
are
really
boring,
so
waste
your
time.
Ours
is
the
best
thing
anyway
yeah
so
going
through
the
agenda.
The
first
thing
we
need
to
talk
about
is
the
fact
that
we
don't
have
a
a
charter,
and
so
I
would
love
to
have
volunteers.
A
It
looks
like
steven
has
already
stepped
up
as
a
volunteer
to
help
draft
the
Charter,
but
I
would
love
to
have
some
other
folks
involved
with
that
as
well.
So
it's
not
just
writing
a
document.
This
is
actually
creating
a
foundation
for
the
policies
for
this
SIG
moving
forward.
So
it
has
a
lot
of
implications
and
a
lot
of
impact
across
projects.
So
this
is
a
very
serious
matter
and
I
would
love
to
have
people
step
up
either
to
help
draft
or
to
work
with
Steven.
To
do
that,
so
anybody
feeling
so
inclined.
A
A
So
this
is
a
really
interesting
use
case
for
this
a
project
model,
because
technically
the
release
team
doesn't
specifically
own
code,
although
one
could
argue
that
they
should
in
terms
of
released
related
code
and
I
would
love
to
once.
We
have
a
draft
in
place
to
have
a
good
discussion
about
that,
because
it
would
be
interesting
to
see
what
would
it
take
to
move
other
the
release
code
and
the
things
like
an
ago,
but
not
under
istic
release.
A
A
Sorry
guys,
the
most
most
unorganized
sig
meeting
ever
another
thing
that
we
need
to
talk
about
once
the
the
release
chairs
in
places
that
we
have
a
fair
amount
of
overlap
with
sig
p.m.
and
specifically
sig
p.m.
if
you
don't
know
this
already
staffs.
The
featured
lead
role
in
the
release
process,
and
so
one
of
the
things
that
we're
gonna
try
and
do
for
1.12
at
the
end
of
1:12
during
code
freeze,
is
to
try
and
help
SIG's
do
planning
for
the
for
the
next
release
cycle
and
so
sick
p.m.
is
gonna.
A
A
If
we
are
involved
with
that
planning
process
that
allows
us
to
actually
pre
scope,
whether
we
need
to
get
docks
in
the
project
for
the
release
if
there
are
specific,
merge
concerns
or
things
that
need
to
be
handled
in
the
release
process,
so
the
better
the
better
alignment
we
have
with
sate
p.m.
and
the
the
planning
process,
the
better
it's
going
to
go
for
the
project
as
a
whole
and
the
better
the
release
process
will
go.
So
I
definitely
want
to
make
sure
that
we
talk
about
that.
A
C
A
A
A
C
So
I
was
curious
to
understand
just
from
a
broader
security
design
perspective
if
we
had
a
overarching
threat
model
for
the
release
process
or
if
whatever
threat
modeling
had
happened
already
for
the
project
from
a
functional
perspective
like
when
you're
you're
running
a
kubernetes
cluster,
how
much
of
that
backed
up
to
the
release
process
and
require
trusted
artifacts
from
the
release,
so
I
chatted
with
the
security
folks
a
bit
and
they
indicated
that
there
wasn't
an
existing
threat
model
that
captured
this.
They
would
be
interested
in
seeing
one.
C
They
hoped
that
we
would
volunteer
to
create
that
and
I'm
interested
in
helping
contribute
to
that
and
then
one
other
question
there.
Sometimes
these
things
are
sort
of
sensitive
in
their
draft
phasing
and
they
felt
that
this
would
not
be
the
case
here.
So
we
can
discuss
and
draft
in
public
and
collaborate
towards
a
threat
model
and
then
figure
out
how,
within
that
context,
how
signed
artifacts
support
that
to
create
a
trusted
supply
chain?
C
A
D
Just
that
I
know
that
there
are
some
teams
at
Google
are
very
interested
in
this
general
area.
They're
trying
to
get
better
provenance
over
the
entire
build,
and
you
know,
kind
of
more
security
over
how
its
performed,
rather
than
just
like
on
the
branch
managers
workstation,
and
that
I
think
signing
would
definitely
be
related
to
those
efforts,
as
well
as
any
threat.
Modeling
yeah.
E
Actually
be
a
perfect
case
for
where
involving
people
from
the
update
framework
or
notary,
which
is
used
for
signing
artifacts,
do
we
actually
use
here
for
signing
anything
that
goes
out
into
a
production
like
environment
would
be
perfect,
and
then
that
way,
you
can
do
some
pretty
strong
key
management
for
and
and
sort
of
more
democratize.
The
release
build
and
push
up
to
a
place
process
which
is
I,
think
you're
talking
about.
C
Well,
perhaps
yeah
I
think
I
I
have
maybe
two
conflicting
strong
opinions
on
how
this
might
be
done,
and
it
it
kind
of
depends
on
how
users
would
intend
to
consume.
This
I
think
right
now.
Someone
who's
particularly
concerned
about
this
is
probably
going
to
build
their
production
binaries
themselves
as
opposed
to
download
them
from
the
project.
C
But
there
I
think
we
need
to
understand
the
actual
use
cases
a
bit
more
and
and
see
who's
looking
to
consume
them,
and
then
what
the
the
verification
path
would
look
like
for
them
and
how
automated
that
would
become
that,
whether
it
ties
into
the
update
framework
or
what
the
mechanisms
look
like,
but
I
think
right
now
we're
at
a
point
where
we
got
to
understand
really
the
the
top
level
requirements.
First,.
D
C
Yes,
okay,
so
I
was
curious
to
chat
after
cube
Khan
in
the
the
release
discussion.
They're
talking
about
the
portions
of
the
build
process
that
are
connected
to
Google
employees
and
how
that's
being
broken
out
I'd
be
interested
to
find
out
more
on
sort
of
the
status
and
timeline
of
that,
because
it
would
obviously
tie
into
what
whatever
we
try
to
accomplish
with
provenance
improvements.
Okay,.
A
F
Thanks
days
for
bumping
up
the
zombie
agenda-
yes,
oh
yes,
so
finally,
I
think
this.
The
well
awaited
action
on
the
scalability
scenario,
with
the
project
I
think
so
so.
I've
added
a
bunch
of
a
couple
of
scalability
free
supplements
and
like
a
kind
of
stabilized
date
over
the
past
few
weeks,
I
added
at
more
than
a
month
ago.
So
now
they're
actually
running
against
every
single
PR.
This
means
that
every
single
PR
in
the
comidas
project,
right
now
in
the
commenter's
repository,
is
being
scaled
tested.
F
F
Giving
stories
of
scalability
regressions
from
the
past
and
like
I,
have
data
to
basically
assert
that
we
can
we'll
be
able
to
catch
about
60%
of
regressions
that
we
saw
in
the
past
with
just
these
two
piece
of
myths
that
has
a
cube,
mod
500
and
the
100
no
GC
test.
So
so,
yes,
we
wanted
to
make
sure
that
this
decision
is
transparent
to
the
release
team
as
well
and
I,
think
Jess
and
Josh.
F
She
was
well
I
think
you
guys
probably
know
how
how
much
of
a
pain
in
the
a
scalability
gets
close
to
the
release.
So
this
is
our
first
step
towards
actually
avoiding
that.
So,
if
you're
able
to
block
like
60%
of
regressions
from
getting
into
the
code
base
like
even
before
March,
this
is
kind
of
a
good
win
for
us.
F
Yes,
and
regarding
the
increased
time
due
to
adding
these
pre
submit
right
now,
it
doesn't
seem
too
big
of
a
deal
because
we
are
in
the
code
freeze
period
like,
and
we
actually
don't
have
the
queue
too
long.
So
this
is
not
like
going
to
cut
our
throughput
much
but
I'm
going
to
work
on
some
ways
to
fasten
up
the
qumar
500
as
well,
so
that
it
isn't
the
bottleneck
of.
F
F
Yes,
this
the
same
exact
question
came
up
in
cig
testing
and,
like
folks,
are
basically
asking
like
if
there
are
some
trivial
changes
or
like
some
sort
of
changes
that
we
don't
actually
have
to
run
the
tests
against,
and
this
was
actually
my
suggestion
that,
like
to
start
with
the
most
trivial
ones,
are
like
documentation,
changes
or
like
typo
fixes
and
things
like
these.
So,
yes,
we
can
probably
do
that.
F
So,
yes
for
trivial
cases,
we
can
probably
do
that
I.
Of
course,
we
also
need
to
think
about
if
it's
worth
doing
that,
like
this
basically
add
some
extra
complex
city
in
that
lake,
we
are
going
to
basically
have
pre
submits
selectively
on
some
peers.
But
yes,
I
mean
it.
Does
the
sound
like
a
reasonable
idea.
We
probably
want
to
do
something
with
this
at
some
point,
but
for
slightly
non-trivial
changes.
A
It's
like
an
excess
change
can
easily
break
everything
right,
I
mean
it's
just,
and
it
has
happened
more
than
once
like
at
least
in
the
recent
past,
but
it's
only
changed
to
a
markdown
file
is
not
capable
of
such
a
thing,
so
it's
sort
of
like
we
knew
we
didn't
at
least
do
some
rough
rough
hewing
of
it
once
it's
in
place
and
and
look
at
how
we
might
do
that,
because
I
do
I
mean
I
have
a
lot
of
concerns
about
just
the
time
over.
A
You
know
time
over
the
the
current,
the
presubmit
time
and
the
cost
associated
with
spending
in
clusters.
For,
for
you
know,
no
reason-
and
you
know
so-
I
just
want
to
be
mindful
of
how
we're
using
resources
to
to
solve
a
problem.
That
is
a
really
big
problem
and
thank
you
by
the
way,
so
much
for
doing
that.
F
Yeah
we,
we
definitely
can
work
on
that,
but
but
actually
it
turns
out
that
the
rate
limiting
factor
from
what
I
understand
is
not
actually
the
resubmit
running
against,
like
the
PR,
but
the
peace
of
mind
actually
running
against
the
tide
batch.
Because
that's
where
that's,
what
is
actually
the
main
limitation,
because
this
longer
test
is
going
to
make
the
batches
going
a
bit
slower
so
that
can
affect
the
throughput
and
four
batches
I
would
say
as
I'd
like
it.
F
Maybe
does
not
make
give
us
too
much
of
a
benefit
doing
this,
because
I
would
assume
that
out
of
a
batch
like
on
most
occasions
out
of
a
batch
that
at
least
be
one
non-trivial
PR.
So
yes,
but
with
respect
to
cost
yeah,
we
might
probably
want
to
save
some,
though
these
costs
are.
These
tests
are
not
actually
super
expensive,
actually
did
a
very
quick
calculation
and
it
turns
out
battery
is
like
spending
something
like
a
couple
of
dollars
for
like
I
know.
F
G
Just
one
more
point,
the
bigger
issue
that
we
wanted
to
raise
right
here
was
the
timing
of
making
this
blocking
Sean
was
proposing
to
make
it
blocking
in
the
next
week
or
so,
which
would
be
into
code
freeze,
which
means,
if
there's
any
critical,
PRS,
that
we
need
to
get
in
it's
going
to
take
slightly
longer
to
get
them
in
just
wanted
to
get
us
I
know
from
the
release
team.
For
that.
G
F
Just
like
there
is
a
purpose
of
adding
these
new
tests
is
that
if
some
fix
is
actually
introducing
the
regression
we
should
know
so
we
want
to
stop
them
and
so
like
adding
to
what
I
said
first
I
mean
personally.
My
opinion
is
that
this
extra
20
minutes
of
time
that
we
add
in
this
scalability
presubmit
is
really
negligible.
With
respect
to
the
time
you
spend
for
reviews
and
like
addressing
those
reviews
in
general
life
time,
the
life
of
PR
is
like
much
larger
than
this
extra
20
minutes.
The
PR
is
the
word
also.
D
H
The
yeah
now
I
just
being
concerned
because
we're
having
a
bunch
of
tests
right
now
being
flaky
that
really
shouldn't
be
flaky.
So
the
I,
adding
adding
more
tests
anymore
blocking
test
is
a
little
bit
worrisome
just
because
of
concerns
about
having
stuff
refusing
to
merge.
But
yes,
rather
than
rather
than
what
specifically
in
the
tests.
I
F
Once
can
ever
do
this,
I
can
say
that
the
flakiness
is
like
really
super
low
and
the
scalability
tests
are
one
of
the
most
taken
care
of
tests
make.
It
is
the
small
scale
ones
we
are
kind
of
ensuring,
like
more
than
99%,
helps
like
worth
the
long-term
long
time,
especially
these
jobs
that
I
added
for
pretty
summons.
H
D
Just
a
small
just
concurring
there
that,
as
far
as
tested
tested,
I,
see
breaking
from
a
test
and
precise
scalability
is
very
consistent
in
quickly
addressing
issues
which
is
a
big
plus.
As
far
as
to
make
these
blogging
we've
been
a
little
bit
concerned
about
the
like
how
long
it
takes
and
things,
but
at
the
moment
it
should
be
fine
and
we
have
plans
to
improve
it
in
the
future.
H
F
D
H
I
F
A
Great,
thank
you
again
for
doing
that
was
so
so
great
to
see
the
the
feedback
come
back
and
actually
get
turn
into
something
that
gets
done.
So,
thank
you
sure,
cool,
okay.
Moving
along
in
the
discussion,
so
release
cadence
discussion.
This
is
a
hot
potato
and
it's
something
that
comes
up
from
time
to
time
and
I
just
want
to
have
it
on
our
radar
to
talk
about
right
now
we
do
four
releases
a
year.
There
are
many
problems
with
this.
A
One
of
the
problems
that
we
run
into
is
that
the
fourth
release
of
the
year,
which
is
over
the
holidays,
is
notoriously
hard
to
staff
and
also
avoid
having
critical
milestone.
Dates
fall
on
holiday
days.
So
so,
basically,
we
really
get
three
full
releases
more
or
less
and
than
a
fourth
kind
of
loosey-goosey
release.
A
I
would
love
for
us
to
talk
about
how
we
negotiate
with
the
community
and
with
ourselves
and
all
the
processes
we
have
in
place
about
how
how
either
we
keep
the
release
terrain
that
we
have,
which
is
the
the
quarter
really
strain,
or
we
change
it
to
three
or
we
change
it
to
more
frequently
releases,
and
that
is
a
discussion
that
I
would
love
to
to
start.
I
don't
know
if
right
now
is
the
right
time
to
do
that
or
not
that
how
what
is
the?
H
Think
we
should,
but
I
think
it
needs
to
involve
a
fair
amount
of
maintainer
higly,
the
ones
who
would
like
a
different
cadence,
because
I'd
like
to
hear
more
about
what
problem
they
expected
to
solve
exactly
because
certainly
the
ones
who
talked
to
me
one
at
a
slower
cadence,
because
what
they
were
imagining
is
that
we
would
have
as
many
features
you
know
for
months
release
as
we
currently
have
in
a
three
month,
release
which
would
make
the
workload
a
bit
lighter.
The
thing
is
that
I'm
not
sure
that
it
would
necessarily
work
that
way.
H
There's
a
minor
issue
that,
in
terms
of
arranging
the
release
calendar
that
doing
the
quarterly
releases
is
difficult
for
both
the
midsummer
and
the
midwinter
releases
in
terms
of
making
a
release
schedule
that
does
not
involve
doing
important
things
where
lots
of
people
are
gone
and
a
four
month
release
would
make
it
that
slightly
easier
to
schedule.
But
that's
a
pretty
minor
reason
to
change
anything
on.
A
So
something
I
had
considered
as
a
possibility
is
a
so
three
full
releases
and
then
for
the
last
quarter.
We
do
to
release
segments,
so
one
is
just
a
like
a
bug
fix
print
type
release
that
doesn't
have
any
features,
it's
just
like
hackathon
against
bugs
and
Docs,
and
all
that,
so
that
would
be
for.
Basically,
it
was
a
January
figure
and
it's
just
stupid
calendar.
What.
A
You
know
just
people
can
work
on
whatever
they
want
and
it's
not
necessarily
a
specific
release
segment
per
se.
But
there's
you
know
slack
to
do
whatever
in
that
timeframe.
So
basically
it's
just
kind
of
open
season
on
bugs
or
if
people
want
to
try
a
hackathon
project
or
whatever
it
is,
but
essentially
the
the
project
as
a
release
team
would
go
dormant
from
November
20.
Whatever
is
22nd
to
to
December
31st
thoughts
on
that
so.
B
I
think
we
need
to
better
define
some
of
the
stuff.
That's
actually
in
the
next
topic,
before
being
able
to
do
something
like
that.
I'm
not
saying
I,
disagree,
I
think
it
actually
is
a
pretty
good
plan,
but
yeah,
but
I
think
there
are
some
of
the
things
that
we
need
to
tighten
up
on
the
release
team
overall.
Before
for
being
able
to
do
that,.
B
Help
me
understand
well
from
a
from
a
planning
process.
Overall,
if
we're
going
to
start
bringing
actual
sick
planning
into
the
mix
we
can't
like.
How
are
we
gonna
convey
that
to
SIG's?
B
A
A
Okay,
so
I've
put
in
the
Jenna
in
here
for
what
release
policies
are
missing,
I
think
there's
a
lot.
These
are
things
that
we
have
to
contend
with.
It
seems
like
every
release
cycle
and
there's
some
things
that
we
haven't
had
to
contend
with
yet,
but
we
need
to
know
what
we'll
do
if
they
do
so,
let's,
let's
go
ahead
and
dive
in
so
this
came
up
recently
documentation
as
a
blocker.
There's,
a
very
spirited
debate
about
this
and
Jordan
Liggett
was
kind
of
on
the
side
of
well.
A
A
C
So
a
bit
of
an
argument
for
trying
to
be
more
pragmatic,
I,
don't
necessarily
agree
with
the
basic
premise
that
was
given,
though,
that
developers
don't
or
can't
or
won't
prioritize
writing
documentation.
So
code
will
always
come
first
with
a
lag
of
documentation.
If
you
do
buy
into
that,
then
it
becomes
a
reason
why
making
it
a
blocker
is
hard.
C
J
Would
say,
though,
that
anyone
who
works
for
a
company
building
product
on
top
of
open
door,
super
nerds
at
least
would
larger
than
a
size.
Four
we'll
say:
20
I
have
not
met
a
I'm,
not
saying
a
single
feature
produced
at
any
of
these
companies
were
a
reasonable
draft
of
documentation
would
not
have
been
ready.
At
the
same
time,
we're
really
proceeding
that
Olivia's
code.
J
C
K
Another
there's
a
time
where
a
lot
of
alpha
features
and
even
native
features
are
under
documented
and
are
kind
of
excused
for
being
under
documented,
because
their
outlet
made
it
features
winter.
Arguably
time
that
we
need
to
be
making
accessible
to
people
so
that
they
try
them
out
and
give
us
feedback
on
them.
E
Just
as
a
I'm,
also
on
the
release
team
with
Misty
I
share
her
sentiment
and
saying
that
documentation
is
important.
I
wouldn't
go
so
far
as
to
say
that
every
I
and
T
would
need
to
be
crossed.
I
think,
like
everything
that
made
it
as
a
feature
in
kubernetes
features,
absolutely
should
have
documentation
surrounding
it
and
without
question.
Before
the
release
goes
out.
What
the
dark
side
liner
should
be
blocked
other
pr's
ago
in
the
master,
while
I
think
it's
extremely
important.
E
So
that's
still
in
progress,
I,
don't
know
what
will
arrive
at
that,
but
I
absolutely
think
that
every
single
feature
that
actually
is
logged
in
github
as
a
kubernetes
feature
should
have
some
documentation
surrounding
it
and
should
block
the
progress
of
it
because
just
like
a
UK
live
at
the
same
product
teams
that
actually
have
to
build
stuff.
On
top
of
open
source
code,
when
he's
the
new
documentation,
we're
absolutely
in
that
boat
and
I'm,
just
an
operator
for
our
company,
like
we
absolutely
need
documentation
on
some
of
this
stuff.
A
A
Actually
happened
yet
yeah
I
would
love
to
see
the
the
birth
of
the
user
facing
docks
required
label.
That
would
be.
That
would
be
the
thing
and
that
actually
would
be
nice
to
have
that
applied
to
by
somebody.
Who's
could
be
the
PR
author
or
it
could
be
somebody
who's
on
the
release
team
or
somebody
that's
managing
features.
What.
E
H
A
G
A
Just
to
summarize
we're
at,
in
my
opinion,
based
on
this
conversation,
we
need
to
figure
out
whose
is
controversial,
to
and
figure
that
out.
I
want
to
hear
some
real
objections
to
this,
but
otherwise
we
should
assume
that
the
documentation
should
be
established
as
a
as
a
blocker
for
things
that
make
sense
and
that
make
sense
part
we
can
determine
over
time
and
we
can
figure
out
how
to
enforce
that.
But
bottom
line,
Sonne.
A
A
So
I
would
love
for
us
to
maybe
have
a
discussion
at
some
point.
It
doesn't
have
to
be
now
but
like
let's,
let's
come
up
with
what
a
actual
revert
policy
looks
like
because
right
now,
it's
just
we're
we're
like
a
shark
with
no
teeth.
When
it
comes
to
this,
we
can
say
we're.
Gonna
revert
your
stuff,
but
the
minute
somebody
lays
a
commit
on
top
of
something
that
we
want
to
revert.
Then
things
get
really
tricky
so
thoughts.
A
A
A
C
H
H
Writing
the
reverse
this
out
code,
in
any
case,
by
the
way
that
shows
you
what
the
actual
threat
model
for
reverse
this
is,
which
is
the
reason
why
we
would
do
that
is
somebody
commits
something
and
tests
are
chronically
failing
and
we
figure
out
that
it
that
commit
is
why
tests
are
chronically
failing
and
for
whatever
reason,
we
don't
think
it's
fixable
before
release
yeah
and-
and
that
is
the
thing
that
we
would
like
to
be
able
to
do
in
a
much
cleaner
way.
Not
you
know
not
stuff.
Like
hey
this.
H
H
A
C
So
I
just
I'm,
trying
to
understand
how
like,
in
my
mind
that
scenario
plays
out
like
we
have
gotten
to
a
point
where
we
have
an
adversarial
relationship
with
a
given
sig
in
our
interactions
with
them,
have
failed
and
that
we
have
chosen
to
proactively
revert
their
code
against
their
desire
to
not
revert
it.
So.
A
That
is
a
scenario.
The
more
likely
scenario
is
that
somebody
wrote
some
code.
It
gets
merged,
they
go
on
paternity
leave,
or
are
they
they
decide
that
they
want
to
go
to
the
Bahamas
with
no
the
internet
for
six
months
or
something
and
nobody
in
the
sig
is
qualified
or
or
knows
enough
about
the
thing
that
got
merged
to
be
able
to
cogently
work
on
it?
C
So
that
that
I
feel,
like
is
a
in
my
experience,
that's
a
slightly
different
level
of
risk
management.
Need
that
so
I
would
call
that
unmaintained
or
unmaintainable
code,
which
is
a
different
path
that
you
arrive
at
typically
than
like
a
critical
release
blocking
situation
now
it
certainly,
the
timing
could
show
up
just
horribly,
like
as
a
ready
condition
like
the
release
is
happening
and
the
person
has
gone
on
vacation,
so
I
I
get
where
you're
coming
from
well.
A
A
That's
right
so
so
there
are
there
instances
where,
where
this
is
a
real
thing,
but
I
think
that
you're
right,
you
raise
a
very
interesting
point,
which
is
unmaintainable
versus
policy
violating
code.
So
policy
violating
code
would
be
code
that
doesn't
stand
up
to
documentation
requirements
or
is
may
be
implementing
a
something
that
that
the
release
team
just
feels
like
wow.
You
guys
totally
snuck
in
a
feature
that
shouldn't
have
been
in
or
stuff
like
that.
H
Z
and
that's
when
we're
actually
I
have
literally
had
D
I
have
already
had
to
use
the
threat
of
reverting
stuff
in
111,
even
though
it's
a
hollow
threat,
because
people
were
telling
me
that
that
oh
I'll
do
the
docs
later
after
release
and
like
no.
No,
that's
not
what
you're
going
to
do.
It's,
not!
Okay!
It's
not!
Okay!
With
me!
It's
not
okay
with
an
out
steam
yeah
now
or
let's
move
the
feature
to
112.
So.
A
We
definitely
need
to
have
a
more
focused
discussion
on
this.
I
think
that
this
is
something
that
needs
more
and
plus
a
real
real
policy
document
out
there
on
our
on
our
site,
okay,
moving
along
revisiting
the
requirements
for
release
Lee.
Currently,
the
requirements
are
a
whole
bunch
of
things,
I'll
paste
in
chat,
so
you
can
take
a
look
at
these
I
think
that
we
need
to
validate
whether
this
is
these
are
hard
and
fast
or
these
recommendations
why?
Why
are
there
any
requirements
at
all?
A
H
H
A
H
If
somebody
was
volunteering
to
be
released,
lead
will
thing
they
wouldn't
the
way
we
do
things
these
days.
They
wouldn't
make
it
through
two
terms
in
the
release
team,
without
already
having
become
a
member
of
the
org
cuz.
Now
the
first
thing
we
do
when
people
don't
care
for
the
release
team,
they
say:
hey.
Are
you
already
an
org
member?
If
not,
let's
make
you
an
org
member,
okay.
A
B
H
C
C
This
PR
is
associated
with
that,
so
I
I
think
people
will
just
kind
of
work
their
way
around
it
and
from
that
that
doesn't
help
the
situation
of
the
release
team
trying
to
do
active
risk
management
like
trying
to
understand.
Is
this
a
low,
moderate
or
high
risk
PR,
regardless
of
what
its
basis
is
bug-fix
feature
whatever
so,
with
the
volume
of
stuff
going
by
I?
Think
each
of
these
having
somebody
who's
focused
on
it
and
even
like
I'm.
C
This
this
release
has
been
fantastic
in
my
opinion,
because
we
have
ice
SC.
I
signal
lead
those
all.
Basically,
all
of
those
test
fails
basically
mapped
to
issues
right
or
bugs,
but
it
carves
off
a
big
chunk
of
them
so
that
the
the
bug
triage
can
focus
on
a
subset
of
things.
So,
each
of
these
being
a
slightly
smaller
domain
with
a
focused
person,
I
feel
like
you,
ends
up
being
much
more
effective
and
then.
H
One
of
the
other
things
looking
at
long
term
is:
if
we
had
better
automation,
then
some
of
these
roles
would
become
less
time-consuming,
like
the
reason
that
that
bug,
triage
and
PR
tree
is
are
so
time-consuming.
Right
now
is
that
an
awful
lot
of
the
work
you're
doing
is
honestly
copying
and
pasting
things
just
to
keep
track
of
them,
and
and
that's
something
that
computers
should
do
for
us,
but
making
those
automated
has
been.
A
H
B
I
think
I
still
think
it's
I
still
think
there
should
be
a
nomination
process,
but
if
we're
saying
that
release
team
itself
is
going
to
become
a
sub-project
of
sake,
I
think
this
was
a
different
meeting
that
right,
if,
if
yeah
so,
if
release
team
is
going
to
be
a
sub-project
of
sake,
release
and
it's
not
actually
a
decision
for
sig
release
itself.
But
it's
a
decision
for
the
release
team
with
insert
release
right.
B
A
H
Speaking
of
which,
since
we
don't
have
that
process
in
place
now,
can
we
use
a
simple
nomination
and
vote
of
those
present
for
112?
We.
B
A
H
A
Also,
a
big
plus
one,
on
Tim
and
and
also
this
is
part
of
the
thing
about
the
requirements
and
the
lead
is
ten
technically
is
not
shadowed
lead,
but
he's
been
involved
deeply
in
the
release
process
so
and
wide
support
so
yeah
by
the
way
I
want
to
I
want
to
pre
I
want
to
pre,
ask
or
I
want
to
see.
If
there's
a
possibility,
I
ish
would
consider
being
the
release
shadow
for
112
that
really
sleep
shadow.
G
A
G
A
Because
that's
one
of
the
things,
if
we,
if
we
do
shadows
right,
then
we
should
at
least
have
the
current
or
you
know
the
next
release
cycle
should
have
some
idea
ordering
and
then
shadow
for
the
next
should
be
in
place.
So
we
have
more
basically
six
months
window
planning.
So
if
you're
the
release
lead
a
release
out
so
let's
say
for
113,
then
that
gives
you
enough
time
to
orient
your
work
and
get
approvals
and
all
that
good
stuff
ahead
of
time,
which
I
think
is
important,
because
it's
a
very
time
consuming
finger.
A
A
B
Think
we
can
punt
it
because
it's
I
think
it's
a
bigger
discussion
when
I
would
like
to
say
at
least
as
the
so
there
there's
a
mention
of
like
okay.
How
do
we
select
the
release
lead,
but
also,
how
do
we
select
the
other
roles
within
the
release,
team
and
I?
Think
you
should
have
the
option
if
you're
already
on
the
previous
release
team,
to
remain
in
a
role
or
be
ousted
or
something
like
that
or
move
to
a
different
role
before
the
rest
of
the
nominations.
Going:
okay,.
A
All
right,
this
has
been
an
absolutely
fantastic
discussion.
Everybody
thank
you
so
much
for
your
time,
I'm
going
to
go
ahead
and
wrap
it.
If
you
have
any
things
that
you
want
to
talk
about
it
after
the
fact
please
hit
either
the
mailing
group
or
the
slack
channel
and
we'll
go
from
there,
so
see
you
in
couple
weeks.