►
From YouTube: Kubernetes Weekly SIG Release Meeting for 20200323
Description
Kubernetes Weekly SIG Release Meeting for 20200323
A
We
are
recording,
it
is
Monday,
March
23rd.
This
is
the
sick
release
by
a
weekly
meeting.
This
is
a
kubernetes
community
meeting.
We
adhere
to
a
code
of
conduct.
I.
Ask
everybody:
please
do
that
the
meetings
being
recorded,
we'll
upload
it
to
YouTube
after
the
meeting
for
the
world
to
see
in
the
usual
place
in
Google
Docs
we've
got
our
agenda
and
minutes.
If
anybody
would
like
to
take
notes,
please
go
ahead
and
do
that
anybody
else
drop
your
name
in
the
attendance
list
there.
A
B
C
A
Welcome
and
I'm
not
sure
Dan
on
the
call,
if
that's
one
of
the
the
Dan's
we
we
know
or
a
new
different
Dan.
Yes,
it's
one
of
the
Dan's.
You
know,
there's
a
face:
okay,
yeah,
then
probably
everybody
else
see
I
mean
anybody
else
is
welcome
to,
but
I
think
everybody
else
names
I'm,
seeing
looking
relatively
familiar
so
welcome
everybody.
A
Next
up,
let's
go
ahead
and
hand
over
to
Taylor,
so
one
of
the
one
of
the
things
that
sig
release
is
responsible
for
is
the
overall
release
process
and
every
quarter
that
relates
to
getting
a
new
release
team
ramped
up
this
quarter.
We
perhaps
have
a
little
bit
different
world
that
we're
living
in.
So
we've
got
some
some
new
and
different
things,
perhaps
to
decide
so
Taylor.
Do
you
want
to
introduce
yourself
and
tell
us
anything
about
what
19?
What
you're
thinking.
B
So
far,
absolutely
so
howdy
howdy
everyone
for
those
of
you
that
haven't
seen
me
around
on
zoom.
My
name
is
Taylor
Dolezal
and
worked
at
a
very
easy
to
name,
big
media
company
and
it's
very
interesting
times
indeed
kind
of
seeing
everything
that's
closed
down
and
then
seeing
the
influx
of
people
working
from
home
again
happy
to
have
you
all
here,
I'm
very
excited
to
help
out
with
release
119
and
then
I
know
that
over
the
weekend
that
was
some
of
the
discussion
was
kind
of
around
what
we
want
to
do
with
119.
B
A
So
we've
had
a
few
conversations
just
but
sort
of
on
slack
informally
over
the
last
couple
of
weeks.
Where
folks
have
been
thinking,
you
know,
there's
a
lot
going
on
and
all
of
our
lives
are
our
work
is
disrupted.
Our
lives
are
disrupted
right
now.
This
is
likely
to
impact
community
activity.
I
think
you
do
already
see
it
signs
in
some
places
of
velocity,
slowing
down
in
terms
of
submissions
and
reviews,
and
things
like
that
and
that's
something
that
we
need
to
think
about.
A
A
So
we
already
have
a
precedent
for
you're
saying
a
release
is
maybe
going
to
be
a
little
bit
compressed
on
time
or
compressed
on
content
and
reminding
folks
to
think
about
that
from
the
beginning,
instead
of
aspiring
to
do
a
whole
whole,
but
in
that
quarter,
so
this
quarter
may
be
one
where
we
want
to
send
that
message
to
folks
just
to
be
pragmatic
and
and
think
about
what
they
can
realistically
accomplish
versus
other
demands
on
their
time
and
to
to
encourage
people
to
stay
healthy
and
not
mentally
over
commit
right.
Now.
On.
A
So
yeah
there's
a
lot
there's
a
lot
of
variables
that
were
we're
not
accustomed
to
dealing
with
day
to
day
right
now,
that
are
that
I
think
we
just
got
a
and
I
see.
This
already
is
a
characteristic
as
a
community
is
open
source
folks
where
we
are
pragmatic.
So
we
just
maybe
need
to
think
about
being
a
little
more
explicit
on
that
over
the
coming
weeks.
A
B
So
I
think
that
we
are
so
we're
opening
that
up
in
terms
of
volunteers
for
leads
for
this
next
cycle
and
those
selections
overall.
I
know
that
github
issues
open
I
think
we
have
two
issues
tracking
one.
Thank
you.
If
I'm
not
mistaken,
it
might
be
more
than
I
missed,
but
so
far
so
good
right
now
and
then
keep
my
eye
on
all
all
the
notifications.
Yet
to
come.
A
A
All
right
release
engineering.
We
have
a
separate
meeting
bi-weekly
for
release
engineering,
but
things
are
continuing
to
move
along
on
that
front.
Is
there
anything
for
the
broader
attendance
today
that
anybody
wants
to
mission
mention
about
code
changes
and
flight
planned?
As
we
start,
the
new
cycle.
E
Yeah
hey,
so
we
discussed
more
or
less
the
idea
of
actually
currently
for
the
release
branch
management
side
of
things.
We
currently
cut
the
release
branch
very
early
in
the
cycle,
and
then
we
fast-forward
or
much
the
latest
master
changes
into
that
branch
and
the
idea
was
for
the
next
release
to
turn
it
around
and
cut
the
release
branch
very,
very
late,
maybe
just
right
before
the
first
release
candidate
and
then
adapt
our
tooling
to
actually
be
able
to
have
the
most
smooth
release
branch
management
process
behind
it.
So
what
can
you
think.
A
I
guess
just
so
four
four
others
on
the
call.
My
thinking
on
this
is
that,
right
now
we
we
peel
off
a
branch
that
will
eventually
get
patches
cherry
picked
to
it
for
support.
We
do
that,
notably
early
in
the
release
cycle,
which
means
things
that
are
on
the
master
branch
in
terms
of
get
need
brought
over
to
the
release
branch.
The
branches
are
basically
one
to
one
the
same
in
a
converging
sort
of
way,
we're
doing
literal,
git
branch
fast-forwards
and
the
release
branch
is
just
tracking
master.
A
At
the
point
that
we
have
code,
freeze,
less
and
less,
it
should
be
coming
into
master.
We're
still
pulling
a
hundred
percent
of
it
over
to
that
release
branch,
but
once
we
have
code,
thaw
master
goes
ahead
and
diverges
to
the
next
release
and
only
cherry
picks
come
back
so
really
any
time
before
code
thaw
the
branch
can
be
created
and
the
same
workflow
would
happen,
but
the
timing
of
it
means
that
there's
less
less
of
those
fast
forwards
that
need
to
happen.
A
The
rationale
for
having
had
those
fast
forwards,
I
believe
historically,
has
been
to
get
more
test
coverage
in
the
face
of
a
lot
of
flaky
tests.
Having
the
same
test
run
on
the
master
branch
and
again
on
the
release.
Branch
means
that
we
get
two
sources
of
signal
and
we
can
see
if
it's
passing,
think
of
it
as
like
a
statistical
sampling
of
a
pass
in
the
face
of
it.
D
If
an
owner
decided
they
wanted
to
merge
something
anyway
and
so
having
branched
off
before
code.
Freeze
was
a
way
to
ensure
that
we
didn't
accidentally
have
a
change.
That
was
basically
a
new
feature
hitting
the
release
branch
in
the
middle
of
code.
Freeze,
so
I,
don't
know
if
the
state
of
prowl
is
today
that
we
really
can
prevent,
because,
like
I
mean,
like
I,
remember
the
most
dramatic
one.
It
wasn't
even
like
somebody
deliberately
not
following
the
rules.
It
was
literally
an
accident
yeah.
A
We
don't
I,
don't
think,
have
the
best
of
automation.
That
and,
and
logically,
you
can
imagine
that
it
will
always
be
lossy
I,
believe
there
I'm
trying
to
think
it
was
maybe
almost
two
years
ago.
I
remember
something
I
don't
know
if
it
was
quite
the
accident
state.
No,
it
wasn't
the
accident
state
there
was
there
something
or
is
deliberate
one
sig
went
ahead
and
when
because
they
were
owners
of
the
particular
area,
they
went
ahead
and
reviewed,
approved,
lgt
and
something
merged
they
had
made
the
argument
for.
D
A
Idea
of
extra
eyes
on
the
code
would
require
that
for
every
patch,
that's
coming
from
master
to
the
branch
or
a
head
of
doing
the
fast-forward
action.
That's
somebody
who's
sufficiently
qualified
to
review
the
breath
of
everything.
Keh
keh
looks
again
of
the
things
that
have
already
been
approved
by
the
subject.
Matter
expert
reaffirms
that
they
look
reasonable
and
brings
them
over.
That's
a
pretty
fancy
level
of
skill
to
have
anywhere
in
this
project,
much
less
on
the
release
team.
A
Just
the
that
doing
it
for
some
period
ahead
of
the
release
is
useful
because
you
sort
of
have
some
muscle
memory
on
these
things
that
are
semi
manual
processes.
If
the
first
time
we
go
to
use
the
cherry-pick
process
or
do
a
fast-forward
is
the
day
before
we're
making
a
release,
and
we
discover
there's
something
broken
somewhere
in
there
and
nobody's
run
that
script
in
three
months.
D
G
D
A
As
much
as
we
have
things
set
up
now
in
a
an
automated
fashion
to
get
CI
running
on
the
new
branch,
we
do
have
hiccups
in
that
area
as
well.
I
am
just
looking
at
the
the
calendar
for
when
what
happened
in
the
118
release,
I
feel
like
starting
the
branch
somewhere
around
code.
Freeze
probably
is
reasonably
pragmatic
in
between
Kota
I.
Definitely
would
personally
worry
is
too
late.
A
F
Another
another
veto
that
I
might
have
possibly
missed
out
in
the
conversation
with
a
besides
precise
practice,
to
make
sure
that
things
are
gonna,
things
happen
of
runs
a
besides
practicing.
The
use
of
tools
are
are
used
for
fast
forwarding
and
keeping
the
release
branch.
There
is
also
the
factor
of
running
the
one,
a
the
latest
release,
jobs
in
CI,
so
also
it's
also
the
sooner
we
can
cut
the
release
branch.
D
A
A
F
A
So
before
countries
we
get
upgrade
signal
from
sick
cluster
lifecycle,
for
example,
as
they
go
from
prior
branches
to
master
branch
and
they're
testing,
and
that
should
be
equivalent,
but
knowing
for
sure
that
things
change,
when
you
have
different
branch
names
and
different
tags
and
and
things
like
that,
bugs
are
possible.
So
getting
some
of
that
signal
and
not
deferring
it
till
the
absolute
last
moment
is
beneficial.
A
A
And
I
think
we
would
probably
like,
like
Josh,
was
alluding
to
having
somebody
look
at
not
it's
not
just
run
the
script,
but
look
at
what
will
be
pulled
over
as
a
part
of
running
the
script.
That's
that's
something
that
we
practiced
in
the
past,
but
maybe
has
become
a
little
bit
mechanical
now
and
we'd
we'd
need
to
make
sure
that
people
are
engaged
in
that.
A
A
F
So,
at
least
for
the
current
release,
I
guess
the
TLDR
is
now
last
week
we
closed
with
the
potentially
with
the
potential
idea
of
delaying
the
release
to
allow
for
a
couple
of
bug
fixes
to
going
to
go
into
118,
which
also
means
of
the
church
deadline
was
soft,
a
guideline
this
day
this
time
around,
because
we
a
we
missed
a
couple
issues
in
KK
good
drop.
We
can
a
ton
of
wonderful
people
actually
stay
actually
kept
on
a
cap
working
on
things,
and
this
morning
we
actually
late
last
night
for
me
in
the
u.s.
F
A
A
A
B
B
Definitely
I'd
say
I'd
say
to
keep
it
kind,
slightly
lacks
I'd,
say
at
least
it'd
be
great
to
have
the
lead
selected,
I'd,
say
probably
sometime
next
week,
just
give
everybody
time
to
get
to
release
out
and
kind
of
deal
with
everything,
but
the
dust
set
a
little
bit
I'd,
say
probably
Anna
next
week.
Friday
would
be
good,
I'm
not
check
my
calendar.
Did
that
be
fine,
that
shouldn't
be
a
problem.
I
think
that's
the
third,
if
I'm
not
mistaken,
of
April.
A
Makes
sense
all
right,
I
guess,
moving
on
then
sub-projects,
so
the
working
group
LTS,
the
working
group
around
investigating
the
project
support
stance
is
one
that
was
how
do
we
where's
the
word
I'm
sponsored
by
cig
release,
so
we
periodically
have
readouts
on
that
here.
Two
weeks
ago
we
talked
about
it.
A
fair
amount,
I
think
for
most
of
the
folks
in
that
working
group.
It's
not
even
a
secondary
a
tertiary
thing
on
our
minds
and
not
a
lot
has
gone
on
there
over
the
last
week
or
two
I.
D
So
I
looked
at
the
cap
today,
Nick
was
going
to
take
on
having
the
comparison
between
the
two
major
options
that
is
eye
patch
support
for
one
more
release
versus
lengthening
the
release
cycle
to
four
months,
both
of
which
we
discussed.
That's
the
one,
that's
still
missing
from
the
cap
and
then,
of
course,
we
need
to
get
a
number
of
signals
engaged
with
it,
which
is
one
of
the
things
that
re
our
working
group
crew
is
working
on.
A
A
A
A
A
A
Alright,
so
I'll
walk
through
the
in
progress
and
see
if
we
have
any
updates
the
the
first
one,
things
related
to
go
modules
and
go
path.
Is
issue
number
eight,
two,
five,
three
one
and
KK
there's
been
a
whole
bunch
of
work
going
on
around
go
leg,
things
and
Steven,
who
I
don't
think
ended
up
on
the
line
today
had
been
doing
some
stuff
just
recently,
but
I'm
not
sure
it
actually
touches
quite
on
this.
A
So
we've
got
image
updates
coming
and
trying
to
move
things
forward
to
latest
grow
releases
this
week,
not
really
reflected
in
the
status
specifically
here
and
not
entirely
related
this,
but
all
I'll
touch
base
afterwards
with
folks
on
that
I
guess
and
see
if
there's
any
updated
status,
so
Jorge
and
Taylor
on
the
next
one.
116
release
retrospective
items,
I.
A
F
Plan
that
I
had
is
that
I
assigned
myself
and
Bob
Bob
and
Taylor
to
this
one
a
little
bit
late
in
the
in
the
release
cycle.
Things
started
to
pick
up
really
fast,
and
you
know
other
other
things
have
a
little
bit
higher
priority,
just
to
make
sure
that
the
curve
release
is
going
over
I
put
a
crimp
plan
that
had
and
by
any
means.
If
anyone
is
interested
in
this
place,
you
know
a
pleasure
name
and
where
a
this
is
not
a.
This
is
the
this
is
yeah
as
inclusive
as
it
gets
good.
F
The
plan
that
I
have
was
to
actually
start
going
to
this
one
this
week
and
try
to
polish
out
the
things.
I
have
been
done,
the
things
I
have
done
differently
and
it
just
resurfaced
all
the
issues
them
all.
The
things
are
get
to
be
done
yet
to
be
a
J
to
be
discussed
and
the
same
for
the
117
retrospective
items,
which
is
in
another
issue.
A
A
So
the
things
it's
they're
open,
but
it's
sort
of
confusing
to
look
at
because
there's
so
many
things
and,
for
example,
like
needs
issue,
I
wonder
if
we
should
just
scrub
through
this
decide
for
some
of
these
things
are
they
still
relevant
open
an
issue
and
let
them
be
tracked
separately
and
close
this
out,
and
then
we
can
it's
it's
a
little
easier
to
for
a
list
of
individual
issues.
We
can
prioritize
them
and
engage
on
them
as
needed
or
decide
we're
not
going
to
enclose
them.
F
F
So
a
lot
of
these
retrospective
items.
It
had
been
conducted
by
people
who
are
esta
a
by
people
who
are
willing
to
go
back
on
this
and
in
take
a
look,
but
that's
a
little
bit
a
that's
a
that's,
that's
something.
That's
I
mean
dependent
effort
from
any
position
that
we
get
that
we
have
right
now.
I
think.
A
Is
other
people
come
in
later?
They
lack
some
of
the
context,
it's
hard
to
recreate
what
was
like
if
you've
got
a
bullet
list
with
a
few
words
each.
What
all
was
behind
the
thinking
that
led
to
that
bullet
list?
In
the
moment,
it's
it's
fairly
obvious,
maybe
for
the
team,
but
for
the
next
team
or
later
volunteers
it
can
be
confusing
what
the
what
the
intent
was.
What
was
the
problem?
What
was
the
desired
outcome.
A
So
do
you
feel
like
I
guess
what
I
hear
you're
saying
maybe
is
that
we
need
more
continuity
in
in
how
we
handle
these
things.
But
do
you
do
you
have
thoughts
on
a
site
for
maybe
like
formalizing
this
to
ensure
that
it
is
part
of
somebody's
role,
whether
emeritus
or
a
new
different
role,
that
you
have
some
thoughts
on?
What
you
think
would
be
useful
there.
A
F
A
Chairs
relieves
whatever
word
you
use
the
the
role
sometimes
hasn't
been
defined
as
well
as
it
should
be,
but
in
my
mind,
I
view
those
people
is
not
just
ones
who
organize
meetings,
but
ones
who
have
been
present
for
a
while
and
understand
some
of
the
bigger
picture
and
can
provide
that
continuity.
So
yeah
I
think
it's
reasonable
for
us
leads
to
take
on
some
of
this
you
well.
A
We
can
iterate
over
the
coming
cycle
and
as
we
get
our
emeritus
lead
chosen
for
the
the
for
119,
we
can
have
some
or
discussions
about
how
we
push
forward
on
that
all
right.
Well,
I!
Guess,
there's
aside
from
that
kind
of
meta
discussion,
we
can
keep
pushing
along
116
action
items
behind
jobs
as
PR
and
release
blocking
I've
got
too
many
too
many
tabs
going
now
for
the
size
of
my
screen.
A
G
H
F
F
Yeah
I
was
also
gonna,
say.
The
last
type
remember
we
spoke
about.
This
was,
if
not
last
released
a
to
release
ago
and
I
believe.
The
reason
that
we
moved
kinder
to
inform
him
was
because
it
was
flaky.
Yet
at
the
time,
if
it's
not
flaky,
and
if
it's
not
flaky,
if
it
runs
constantly
and
it's
useful,
which
I
think
it
is
a
definitely
it
I
believe
we
can
prove
it
informing
now.
H
H
Mean
you
can
check
the
signal.
Basically,
when
you
I
can
give
you
a
concrete
example.
When
you
do
a
docker
copy
inside
a
container,
it
occasionally
decides
to
fail,
and
we
have
no
means
to
currently
debug
this
dot
or
why?
It's
very
so
it's
not
so
occasional
but
tip.
Can
you
please
open
up
like
one
of
the
upgrades
jobs,
for
instance,.
H
H
H
A
It
seems
like
it
is
mostly
greener,
confusingly
flaky,
as
any
of
the
other
infrastructure
providers
I
great
I
I
would
I
would
prefer
her
has
to
be
confidently
moving
towards
determinism
in
unhealthy
tests.
But
given
where
we
are,
this
doesn't
feel
worse
than
our
current
state
of
the
art
and
I
do
feel
like
it's
useful
signal.
H
F
Couple
a
couple
of
quick
questions
whenever
a
whenever
a
whenever
the
job
fails.
Because
of
something
like
you
just
said,
something
with
doctor
and
doctor,
doesn't
always
fail
to
to
bring
a
to
bring
out
the
rest,
a
those
are
always,
it
doesn't
always
feel
like
in
some
particular
stage
or
test,
for
example,
the
couple
ones
that
we
just
call
over
I
think
it
was
brother
if
the
faders
were
like
that
one
I
think
it
will
be
rather
easy
to
figure
out
whether
it
was
a
flake
due
to
our
natural
failure.
H
H
A
Canons
are
feeling
like
our
other
platform
tests
where
cluster
failed,
and
it's
not
downloading
there
like
something
from
business.
Trying
to
bring
the
cluster
up
some
artifact
is
not
available.
This
is
a
pretty
common
meta
symptom,
like
all
of
your
prerequisites,
somehow
weren't
satisfied
and
you
couldn't
get
the
thing
running.
F
In
also
problem,
at
least
from
the
CXC
note
perspective,
at
the
rear.
The
reason
why
I
was
asking
it
is-
and
you
know
flakes
happened
for
the
models
for
the
most
part
daily
for
the
most
part,
they're
always
gonna
be
person
in
some
way
or
another,
but
if
from
the
release
from
the
CAC
no
perspective,
I
think
it's
really
useful
to
just
be
able
to
say
the
job
is
failing,
the
infrastructure
is
failing
versus
something
in
cover,
ladies,
is
actually
in
company.
F
D
H
Help
pretty
much
nobody,
it's
only
beer
for
Britta
who
understands
how
this
infrastructure
setup.
If,
for
instance,
we
have
a
case
where
both
me
and
Fabrizio
PTO,
you
basically
talk
of
anybody
else
to
take
a
look
at
the
kind
of
jobs,
and
this
is
a
this
organization
which,
on
our
side
for
British,
take
lead
I'm
supposed
to
now
at
six
year.
The
problem
we
have
here
is
that
we
haven't
shared
the
knowledge
that
we
have,
and
it's
not
only
a
case
about
booking
a
meeting
and
something
to
explain
how
this
works.
H
H
D
A
So
we
could
all
folks
think
about
pragmatically
recognizing
everything
that
we
said,
giving
it
a
try.
We
could
promote
it
to
blocking,
give
it
a
month
or
so
see.
If
we
feel
like
it's
been
too
painful
and
and
decide
still,
I
mean
I,
don't
know
that
we
have
a
strict
criteria
for
when
when
and
how
we
we
set.
A
The
bar
like
I,
don't
want
to
move
the
bar
and
people
who
are
trying
to
get
things
into
119,
but
I
also
would
like
to
get
additional
signal
and
somehow
we
we
need
to
be
able
to
make
a
decision.
Do
we
do
we
trial
it?
Do
we
just
go
for
it?
Do
we
wait
until
it's
always
green
and
we
have
this
flake
sorted
out.
I
feel
like
those
are
our
options
and
I'm
kind
of
feeling
like
let
let's
go
for
pragmatically
and
evaluate
again
in
a
while.
F
Another
so
is
so
I.
You
know
that
that
proposal,
a
second
proposal,
is
technically
a
mushroom
for
a
massive
informing,
a
master
in
forming
jobs.
Are
they
should
be
us
really
spoke?
A
you
know
between
quotes.
They
shall
be
as
released
block
Inazuma
ast
as
a
master
portal.
We
take
cabe,
yet
the
a
some
job
is
some
jobs
have
some
things
in
them,
the
like
a
so.
It's
almost
really
must
be
informing
the
jobs
that
we
have
in
there.
They
are
as
important
as
master
parking
in
normally
I.
Believe.
F
The
motivation
for
a
for
grouping
them
in
a
different
dashboard
was
to
kind
of
inform
us
of
situations
like
this.
One
is,
for
example,
in
a
with
kinder
every
now,
and
then
we
might
get
some
flakes
with
a
doctor
in
doctors
are
just
tough
to
handle
and
with
the
scalability
with
the
scalability
jobs,
they
run
five
thousand
a
day
from
fighters
notes,
and
you
know
we
can
all
read,
only
run
them
one
a
once
a
day.
F
It
doesn't
willing
me
a
Sunday
for
the
most
part
I,
don't
think
it
should
mean
that
we
don't
look
at
them
and
we
don't
take
them
into
consideration,
but
it's
more
having
them
in
mastering
forming
a
I
guess.
It
could
be
another
way
of
saying
it
is
my
failed
if
he
fails,
let's
make
the
decision
of
whether
it
is
a
master
walking
in
the
strict
sense
or
whether
it's
something
related
to
the
job
in
there
you
know
for
an
a
for
now
we
can
say:
let's
wait.
Let's
move
forward.
A
F
A
F
A
If
it's
informing
I,
don't
think,
we
would
require
it
to
be
fixed
ahead
of
release,
but
we
could
still
make
the
same
exception
rationalization
there,
because
we're
actively
looking
at
not
just
ignoring
so
given
the
flight
system.
A
symptom
of
the
flake
I
feel
like
the
the
normal
outcome.
Here
is
gonna
just
be
in
both
cases,
neither
of
them
that
we
would
actually
solve
the
underlying
problem
versus,
for
the
most
part,
be
recognizing
that
it
fits
the
expected
pattern
of
flake
and
accepting
that.
H
Yeah,
because
of
the
uncertainty
of
this
docker
issue
that
I've
been
describing,
it
would
be
my
preference
to
keep
the
jobs
informing
for
now,
because
I
really
want
to
resolve
this
problem.
It's
not
I'm,
not
scared
of
the
extra
burden
of
being
into
master
blocking
I
just
want
to
resolve
this
problem.
Sampled.
H
A
A
Karuna
DS
ticket
72,
49,
updating
images,
this
one
we
could
use
Steven
for
he's,
been
doing
a
variety
of
image,
updates
and
I'm,
not
sure
which
relate
entirely
to
which,
but
I
do
think.
We
have
a
I've
not
seen
so
specifically
around
dis,
realist
attic
going
by,
but
I
think
we
have
kind
of
a
backlog,
and
this
probably
falls
into
release
engineering.
A
A
A
A
F
Long
is
more
layers,
I
think
in
a
stable
place,
there
was
a
after.
He
was
brought
up
and
there
was
some
conversation
with
people
from
sick
testing
on
the
proper
scope
that
we
shall
have
and
I
think
belonging
in
London
in
that
is
in
place.
The
last
time
I
made
a
I
brought
this
one
up,
a
Stephan
mention
as
an
action
topic
the
he
was
gonna
go
through
this
one
and
summarize
it
and
I
guess
Green,
but
a
more
readable
thing
that
we
can
probably
write
a
cap
and
get
it
up
and
running
now.
A
Yeah,
in
my
mind,
it
overlaps
a
little
bit
with
the
the
kept
on
triage
labels,
but
I
guess
that
kind
of
comes
down
to
who
is
is
doing
what
is
it
the
kept
by
viewers,
something
broad
for
the
project,
but
I
see
eye
signals.
Sub-Project
relates
a
little
more
to
the
release.
Team
still
like
this
is
something
that
is
is
spreading
out
from
a
role
within
the
least
release
team.
A
So
as
much
as
it
feels
like
we're
getting
towards
operationalizing
something
I,
don't
think
I
think
we
have
like
the
equivalent
of
a
role,
hand
book
or
a
this,
isn't
a
chartered
sub
project
where
it's
its
scope
and
deliverables
and
actions
are
fully
defined
just
yet,
but
I
do
also
recall
Stephan.
Having
said
Hewitt,
summarize
some
of
that
so
I'll
just
hang
on.
A
H
F
As
I
actually
actually
done
what
Zack
a
kind
of
a
thing
that
was
brought
up
on
in
the
discussion
that
the
OPR
is
sick
testing,
in
specifically
in
their
charter,
they
mentioned
the
date
on
a
they.
Don't
they
don't
maintain
any
and
to
went
into
intestine
job
stay.
You
maintain
the
tools
for
run
air
for
running
them,
but
actually
keeping
them
in
keeping
keeping
them
up
and
rolling
is
a
more
of
a
job
all
of
the
individual
six.
F
So
then
they
a
proposal
for
narrowing
the
scope
for
the
CAC
and
also
project
was
to
just
have
see
a
signal
so
project,
essentially
to
essentially
do
exactly
exactly
exactly
what
it
does
right
now
within
the
release
team,
so
just
focused
on
collaborate,
a
being
the
group,
a
between
six
collaborating
with
other
six
and
a
you
know.
If
they
you
see
that
something
is
something
is
read
right,
a
tries
to
tackle
a
boot
by
no
means
take
ownership
of
them
test
themselves.