►
From YouTube: Kubernetes 1.12 Release Team Meeting 20180716
A
C
A
All
fixes
a
bitly
later
I
guess
after
the
meeting
and
we
can
just
repay
sit
in
the
chat
as
others
join
if
they
bump
into
that.
So
let's
go
ahead
and
get
started.
We've
got
the
recording
going
on.
This
is
a
reminder,
as
with
all
of
our
community
meetings,
that
it
is
being
recorded
and
on
the
internet
and
I
trust
that
we
will
all
treat
each
other
in
a
positive
and
collaborative
way
so
welcome
everybody.
A
I
think
we've
got
nearly
a
critical
mass
I
see
one
or
two
names
missing,
maybe
on
the
participants
from
the
release
leads,
but
I
wanted
to
kind
of
start
with
that
today
go
around
and
have
each
of
the
leads
and
any
of
the
shadows
who
are
here
as
well,
just
very
briefly
introduce
themselves
so
I'll
start
I'm,
Tim,
pepper,
I'm.
Your
release,
lead
I've,
been
involved
with
kubernetes
for
just
barely
about
a
year
now,
but
I've
been
doing
open
source
and
systems
development
for
20
years.
A
B
B
So
that's
why
I
have
more
more
of
the
testing
and
the
test
and
try
and
the
signal
thing
falls
into
my
domain,
quite
quite
naturally,
from
working
for
Google
in
that
area,
I
really
enjoyed
the
111
work
as,
as
mentioned
multiple
times,
the
great
team.
It's
it's
extremely
collaborative
and
I
got
to
learn
a
lot
and
I'm
hoping
to
learn
much
more.
This
release
and
be
of
help
to
in
whichever
capacity
again.
A
E
Hello
I'm,
quite
a
bear
or
Gwen
currently
I
work
at
Samsung,
SDS
and
I
was
shadowing
Tim
for
bug
triage
on
the
last
release,
somewhat
unofficially,
but
there
was
some
shuffling
around
and
so
now
I'm
finding
myself
in
this
position,
where
I
hope
to
be
learning
a
lot
about
just
this
project
on
the
whole
and
the
structure
are
also
who
everyone
is,
which
is
always
my
favorite
part
and
I'm
yeah.
So
I
will
be
the
person
nagging
everyone.
A
A
Oh,
he
dropped
I
was
gonna,
say
I'd
have
Caleb,
say
something
possibly
briefly
as
well,
but
Doug
is
our
branch
manager
and
he's
in
a
somewhat
unique
position
and
that
he
hadn't
shadowed
prior,
because
the
branch
manager
role
has
been
something
that's
been
google-specific
and
during
this
release,
I
expect
that
well,
we're
gonna
be
slightly
stumbling
our
way
through,
but
kind
of
graduating
that
roll
from
one
that
was
google-specific
to
actually
community
based.
So
doug
has
been
a
gracious
volunteer.
F
G
Everyone
I
am
Zach
Arnold
I
work
as
a
software
engineer
for
a
finance
company
called
wide
green
energy
fund
were
a
teeny,
tiny
little
startup,
but
I
was
a
cluster
operator
for
our
culture
and
we
had
enough
issues
that
I
was
like
hey,
there's
some
stuff
that
has
not
talked
about
and
called
her
in
the
docs,
so
I
started
contributing
and
here
I
sit.
So
it's
been
a
world
run
and
an
honor
and
I
think
is
crazy.
H
A
H
H
So
I
am
Nick
chase
and-
and
that's
that's
my
assistant-
he
has
a
lot
of
energy,
but
he
doesn't
type
very
well.
Fortunately,
I
have
I
think
three
shadows
this
time
around,
which
is
awesome.
I
have
been.
This
is
my
fourth
release.
I
think
we
are,
we
hope
to
get
it
right.
One
of
these
times
no
I'm
just
kidding
anyway.
H
I
Hey
everyone,
I'm
Caitlin,
Barnard
communications
coordinator
for
1.12
I've,
been
involved
somewhat
an
unofficial
or
official
capacity
in
the
release
process
since
I
think
one
day
this
has
been
a
lot
of
fun.
I
also
helped
manage
the
kubernetes
blog
and
a
lot
of
the
web
updates.
There
I'm
still
looking
forward
to
working
with
you
all.
J
A
Will
we
will
get
some
of
your
your
words
throughout
the
release,
I'm
sure
Caleb
and
thanks
for
joining
today,
would
any
of
the
shadows
like
to
introduce
themselves
as
well.
I
know:
we've
got
I
think
if
that
I
can't
write,
maybe
34
folks
across
the
entire
team,
between
the
leads
in
the
set
of
shadows.
A
This
is
for
me
this
is
somewhat
daunting
and
that
that's
a
lot
of
people
too
to
keep
track
of
and
talk
to
and
make
sure
we're
mentoring
and
helping,
but
at
the
same
time,
I
think
it's
really
important
that
we
have
a
little
bit
more
pipeline.
So
I'm
I'm
really
happy
that
we
have
so
many
people
who
volunteered
to
try
and
get
into
the
pipeline.
So
any
any
of
the
shadows
like
to
introduce
ourselves.
K
Yeah
I'll
go
so
this
is
Suraj,
so
yeah,
hi,
I'm,
sue
res,
naturally
I'm
a
contributor
and
maintainer
of
the
project
compose
which
is
in
Cuba
Natasha
and
for
work.
I
work
at
Red,
Hat
and
I,
basically
work
around
applique
definition
and
the
developer
tooling,
experienced
developer
experience
and
tooling
around
Cuba,
netizen,
OpenShift
and
I'm
looking
forward
to
contribute
to
released
him.
No
thanks.
L
My
name
is
Mike,
I
was
a
really
snowed
shadow
in
the
last
release
and
I
will
be
continuing
on
as
released
nerd
shadow
and
mostly
the
niche
that
I've
kind
of
carved
out
for
myself
is
writing
tools.
Writing
the
release,
notes
generation
tools,
so
we
I
learned
a
lot
personally
last
release
about
the
kind
of
manual
process
that
we
go
through
to
get
notes
from
the
commit
log
into
what
actually
goes
to
users
so
I'm,
trying
to
kind
of
encode
more
of
that
into
the
software
this
release.
L
M
Well,
I
can
go
hi
everyone,
my
name's
Travis
I'm,
shadowing
Doug
for
branch
management,
I
work
at
VMware
only
been
there.
A
few
months
been
doing
the
open
source
development
for
the
last
five
to
six
years,
previous
companies
at
Red,
Hat
and
then
Dell
and
then
at
VMware
and
fairly
new
to
contributing
to
kubernetes
in
the
last
six
months
and
I
think
this
will
be
a
great
additional
way
to
get
more
experience
with
that.
M
N
A
J
J
N
Sorry
I
had
a
conflict
before
Stephen
Augustus
I
am
the
futures
lead
for
112
I
was
features
shadow
on
111,
apparently
I'm
good
enough
at
it
to
be
the
product
management
here
now.
So,
if
you
have
features
related
issues,
give
you
me
to
beg
people
on
six
I
think
we're
all
pretty
good
at
nagging,
or
we
all
get
really
good
at
nagging
but
excited.
P
N
P
P
O
C
Q
A
Alright,
I
guess
with
that
I
really
want
to
just
again
say:
welcome
to
everybody
it.
This
is
the
third
release.
I
think
that
I'll
be
involved
in
I
kind
of
started,
paying
a
little
bit
of
attention
for
ago,
but
got
sucked
in
and
have
just
found
her
really
fun
and
collaborative
and
rewarding
the
the
type
of
work
that
we're
doing
is
important
and
valued
by
the
community,
and
it
doesn't
happen
without
volunteers.
So
it's
it's
really
awesome
that
all
of
you
have
chosen
to
take
part
in
it.
A
So
the
bitly
link
I
apologize
for
it
not
being
editable
I've
pasted
and
for
anybody,
who's
joined,
late,
I'll
repay
stand,
editable
version
of
it
in
the
zoom
chat
and
then
I'll
get
the
the
link
updated
later,
but
I
wanted
to
kind
of
go
through
the
schedule.
A
little
bit,
I've
had
a
few
questions
about
different
memberships.
A
Over
the
last
week's
talked
a
few
things
about
the
retrospective
and
then
I
would
like
to
have
I
guess:
Steven
talk
for
a
little
bit
about
where
we
are
on
features
and
then
Muhammad
just
give
us
an
update
on
current
CI
status,
so
I'll
run
through
the
the
first
sets
of
things
and
then
hand
it
off
to
Steven
and
then
we'll
go
to
Mohammed
and
I
I,
really
like
meetings
that
are
collaborative
so
feel
free
to
raise
your
hand
like
actually
literally
in
the
camera
or
on
zoom.
A
If
your
zoom
client
has
the
little
raised
hand,
option
or
just
kind
of
like
put
your
hand
up
in
the
chat
with
the
little
emoji
or
whatever,
and
and
let's
hopefully
make
this
actually
a
team
I
shouldn't
be
the
one
talking
most
of
the
time.
Hopefully,
even
though
in
the
lead
so
scheduled
in
the
minutes
is
the
link
and
those
who
have
gone
around
via
email
already,
hopefully,
no
surprises
there.
A
That
CI
shows
the
tests
are
good,
we'll
be
in
a
much
better
place
over
time
as
a
project.
So
that's
that's
probably
the
biggest
thing
to
note
and
I
guess:
I'll
leave
that
there
until
we
drop
down
to
the
retrospective
items,
so
the
other
thing
to
talk
about
was
scheduling
is
how
we
do
meetings.
So
historically,
it's
always
been
kind
of
this
Monday
10:00
a.m.
A
meeting,
and
there
have
been
doodles
that
have
happened
in
the
past
and
attempts
what's
a
better
time
day
and
there
there
hasn't
been
a
clear,
a
clear
winner
that
they
came
out
of
that
versus
this
particular
slot.
Now
later
in
the
cycle
will
go
to
having
Monday
Wednesday
Friday
meetings
and
then
we'll
go
to
to
where
we
actually
have
Monday
Tuesday
Wednesday,
Thursday
Friday,
all
five
days
of
the
work
week,
and
for
that
we
did
in
the
last
cycle
shift
some
of
the
times
around.
A
It's
it's
a
real
challenge,
especially
as
we've
grown
the
team
now
and
we
have
a
bunch
of
shadows
that
are
in
a
whole
bunch
of
time
zones,
but
I
really
want
to
emphasize
I,
don't
know
how
to
how
to
quite
say
this,
there's
no
positive
way
to
say
it.
Maybe
you're
spreading
the
pain,
I
I,
don't
want
our
folks
in
Europe
or
our
folks
in
Asia
to
be
the
ones
who
are
feeling
pressure
to
attend
meetings
at
inconvenient
times.
A
So
what
we
did
in
the
last
cycle
is
a
few
of
the
days
when
we
went
to
regular
or
daily
sort
of
meetings.
Instead
of
just
the
Monday
regular
meeting,
we
had
those
quite
a
bit
earlier
so
that
they
they
were
not
so
late
or
early,
depending
on
your
times.
On
the
other
thing
that
I
would
like
to
propose-
and
we've
we've
got
a
few
folks
from
from
Europe,
and
at
least
one
from
Asia
I
would
be
willing
to
have
sort
of
a
second
follow-up
meeting
to
this
Monday
meeting
very
early
on
Tuesday.
A
It
would
be
me
choosing
to
take
the
time
to
get
up
very
early
on
Tuesday
to
meet
with
folks
that
were
in
Europe
or
Asia
time
zones
in
a
slightly
better
time
for
them,
possibly
if
there's
interest
and
then
I
would
make
a
strong
effort
to
to
not
just
be
telling
everybody
what
happened
but
make
this
actually
a
productive
meeting
as
well
and
in
bridge
the
two.
So
if
we
have
two
sets
of
people
who
are
meeting
at
two
different
times,
that
I
would
be
the
facilitator,
bringing
information
across
those
but
I.
A
A
P
O
P
D
R
O
A
A
A.M.
PC
it
would
be
fine,
ok,
well
I'll,
go
ahead
and
put
that
on
the
calendar
for
the
next
couple
of
weeks,
and
we
can
see
how
it
goes.
I
won't
do
it
this
week
since
you're
here
the
no
point
repeating
it
to
in
20
hours
just
now,
but
starting
next
week.
Let's
give
it
a
try
and
and
see
what
happens
and-
and
you
can
flexibly
see
if
one
works
better
than
the
other,
and
we
can
give
it
a
try
and
see
honestly.
E
For
me,
6
a.m.
is
a
PST
right
on
the
west
coast.
This
United
States
is
better
than
the
slot
between
7:00
and
9:00,
because
that's
where
everything
happens
on
my
commuting
all
my
school
kid
drop-off,
so
that's
just
my
two
cents,
so
I
would
be
willing
to
get
up
for
6,
6
a.m.
meeting
for
sure.
It's.
O
A
Well,
let's
give
this
a
try
and
experiment
and,
and
then
we'll
see,
especially
as
we
have
a
more
diverse
set
of
folks
from
around
the
world
in
the
shadow
rolls,
especially
as
those
come
into
prospective
lead
roles
in
113.
We
want
to
have
figured
out
whether
there's
some
scheduling
way
or
some
way
to
have
a
a
set
of
collaborative
meetings
and
note-taking
and
sharing
of
information
that
we
can
model
and
give
to
the
113
team
and,
in
the
hope,
of
helping
those
people
be
successful
as
well.
Alright,
just.
J
J
A
A
Putting
it
in
github
is
probably
better
for
folks
who
may
not
have
Google
Docs
access
doing
things
like
that
or
when
we
post
videos
not
just
to
YouTube,
but
also
to
some
of
the
other
platforms
that
are
video
hosting
tools
that
are
more
native
and
other
geographies.
And
that
may
be
something
that
supplements
and
makes
things
a
little
more
accessible
for
others.
A
It's
already
now
in
post
minutes
to
github,
okay.
So
the
next
thing
that
I
come
up
was
group
memberships,
so
all
of
the
leads
I
believe
I've
gone
through
embedded.
All
the
leads
are
members
of
the
kubernetes
org,
but
there's
a
link
there
in
the
minutes
for
the
shadows
who
are
not-
and
this
is
something
that
I'd
encourage
you
to
work
towards
as
you
go
through
the
shadow
process.
A
It's
it's
not
something
that's
strictly
required,
but,
as
you
become
more
active
in
the
community,
it's
a
way
of
formally
recognizing
your
contributions
and
with
that
comes
some
accesses
that
if
you
move
up
into
leadership,
roles
become
necessary.
So
it's
a
relatively
lightweight
process,
but
something
to
give
a
read
through
and
be
thinking
about
as
you,
you
grow
in
your
role
within
this
community
and
and
leverage
your
opportunity
here
within
the
release
team
as
a
shadow
to
do
that.
A
The
next
one
is
the
kubernetes
milestone,
maintainer
x',
so
I'm
not
sure
how
much
everybody
really
needs
access
to
this
generally,
it
should
be
the
sig
leads
who
have
access,
but
historically
folks
who've
come
onto
the
release
team.
We've
we've
gotten
the
impression
that
we
need
it
and
have
asked
for
it,
but
then
haven't
necessarily
needed
to
wield
it
and
I
really
think
that
comes
down
to
one
of
the
things.
That's
kind
of
a
fundamental
of
what
we
do
on
the
released
is
that
we're
facilitators
more
than
choice
makers.
A
So
something
like
the
milestone,
maintainer
z'
group
that
allows
you
to
tag
an
issue
or
a
PR
and
github
is
going
to
be
part
of
the
milestone.
So
in
this
case
version
1.12,
but
that's
a
choice,
a
decision
and
whether
a
particular
feature
or
bug
fix
comes
into
the
release
that
really
should
be
being
made
by
the
owning
cig
and
really
the
main
place.
I've
ended
up
using
sort
of
this,
this
privilege
to
to
label
things
it's
just
going
through
and
bug
triage
when
it's
really
clear
that
somebody
had
had
missed
something.
It's
obvious.
A
The
choice
has
been
made,
but
the
the
bookkeeping
hadn't
quite
followed
and
I
think
maybe
Nick
or
but
between
release,
notes
and
Docs
and
issue
triage
and
CI
signal.
We
we
on
occasion
will
label
things,
but
it's
just
where
we
at
most
noticed
that
this
was
like
oh
yeah,
obvious
and
rather
than
sort
of
trying
to
poke
and
poke
and
remind
somebody
to
just
update
their
documentation.
A
Sometimes
there's
just
no
point
nagging:
you
just
label
the
thing
and
and
done
so,
but
that's
not
making
the
choice
to
say
like
oh,
this
content
is
now
going
to
be
in
the
release.
So
I
know
a
number
of
you
all
have
requested
access
and
I
think
I
granted
a
few.
But
generally,
if
you
don't
have
access,
don't
worry
about
it.
If
you
find
that
you
need
it
ping
me
and
we'll
figure
it
out.
E
I
just
yeah
like
what
you
said,
then
the
default
should
be
don't
make
decisions
for
others.
I
do
in
the
interest
of
practicality.
A
If
you
didn't
see
it
I
encourage
you
to
maybe
take
the
time
and
look
at
the
recordings
of
the
retrospective,
so
those
would
have
been
they're
they're,
linked,
I,
think
from
the
1.11
minutes,
the
release,
minutes
Google,
Doc
or
also
the
community
meeting
on
Thursday
the
the
minutes.
They're
one
of
the
retrospective
sessions
was
held
during
the
community
meeting,
so
that's
easily
findable
on
YouTube,
but
the
other
session
was
within
I
believe
the
the
sig
release
meeting.
A
So
the
video
that's
there
and
if
you
have
the
time
to
look
through
and
kind
of
hear
the
discussion,
it's
it's
I
think
it's
pretty
informative
to
kind
of
hear
the
prior
folks
talking
about
the
issues
that
they
ran
into,
how
they
tried
to
resolve
them
or
the
compromises
they
made
and
maybe
what
got
deferred
to
us.
The
the
things
that
weren't
solved
and
there
are
things
that
maybe
aren't
even
near-term
solvable
but
are
kind
of
ongoing
issues
that
we're
trying
to
wrap
our
heads
around.
A
So
we
try
to
have
an
ongoing
conversation
about
that,
and
then
we
also
try
to
capture
as
we
go
along.
So
the
retrospective
document
for
1.12
is
already
created
any
week
or
any
day,
as
you're
bumping
into
things
feel
free
to
just
note
it
down
in
that
doc,
because
in
12
weeks
we're
liable
to
have
forgotten
about
them.
But
then
we
can
circle
back
around
and
think
and
chat
about
them
as
we
go
so
some
stuff
that
came
up
in
the
retrospective
last
time.
A
I
guess
the
first
point
on
CI
signal
and
really
trying
to
form
the
culture
around
keeping
CI
tests.
Passing
I.
Really
spoke
to
that
just
at
the
beginning
of
the
meeting
already,
but
just
to
reiterate
that
that's
a
large
part
I
think
of
how
the
last
release
went.
Well,
the
next
one,
our
our
documentation,
deadlines,
they're
there
at
least
called
aggressive,
I
I,
don't
know
how
aggressive
I
feel
they
are
in
Goins,
shaking
her
head
and
I'm
gonna.
A
Guess
that
Nick
and
and
Zak
maybe
would
also
disagree
but
like
this
is
historically
in
our
industry,
like
developers
like,
oh
I,
don't
want
to
write
Docs
right
now,
a
type
of
a
situation,
so
we
just
we
have
to
gently
and
constructively
nudge
and
remind
folks.
So
that's
an
important
part
of
the
process
and
important
part
of
what
our
output
for
a
release
is
and
the
earlier.
We
start
them
the
easier
it
becomes
instead
of
waiting
till
the
last
moment.
A
Similar
to
that
is
test
cases
and
test
additions.
We
we,
as
a
release
team
part
of
what
we're
doing,
is
risk
management
trying
to
assess
the
state
of
things
and
how
to
ensure
that
that
is
good
and
positive
healthy
for
the
the
project,
and
we
do
that
through
through
test
results.
If
we
have
major
features
that
come
into
the
release
and
those
land
right
at
the
end
of
code
freeze,
but
don't
have
tests
yet
or
don't
have
Docs
it's
really
hard
to
assess
is
the
thing
working?
How
do
we
know?
Is
it
all
there?
A
A
Whether
the
test
case
is
failing
initially,
because
it's
not
implemented
yet
as
a
feature,
but
then
we
get
that
that
change
where
it
starts
working
as
the
feature
is
implemented
or
they
both
come
together
in
the
feature
and
the
test
code
are
there
and
it's
provably
working.
We
want
to
get
to
that
sort
of
transparency
on
features
that
we're
not
all
just
kind
of
guessing.
Is
it
done?
Is
it
ready
and
as
a
release
team,
then
we
can't
do
kind
of
risk
management
on
it.
A
The
next
bullet
they're
interdependent
features.
This
is
something
that
we
bumped
into
late
in
the
cycle
for
1.11
and
I
feel
like
this
is
kind
of
a
classic
software
engineering
problem.
You
you
don't
realize
what
cohesion
you
have
across
different
things
and
you
have
something:
that's
that's
brittle,
II
coupled
and
that
brittleness
bites
you
so
as
a
release
team
and
doing
risk
management.
A
We
want
to
watch
for
and
and
highlight
that
and
figure
out
how
we
can
can
try
and
improve
it
and
and
not
really
I
think
does
something
to
just
be
mindful
of
as
we
go
when
you
when
you
hear
feature
a
and
hear
feature
bead,
don't
necessarily
assume
that
they're
unrelated,
if
they
seem
related,
ask
a
question:
are
these
things
related?
Are
you
talking
if
you
see
an
issue
and
github
and
it
seems
related
to
another
one
and
they're
they're
not
linked
pose
the
question.
A
Talk
to
the
folks
associated
with
it,
should
there
be
a
linkage
there,
because
what
happened
in
the
last
release
was
we.
We
had
something
that
was
a
relatively
critical
feature
that
was
supposed
to
have
been
gated
by
something
else
that
didn't
quite
make
it
and
there
was
sort
of
an
inversion
and
it
led
to
what
might
have
been
viewed
as
a
security
problem.
Even
so,
and
it
would
have
been
completely
avoidable
with
earlier
communication
and
so
watch
for
those
types
of
things
and
ask
questions,
we
won't
again
know
the
answers.
A
We
can't
make
the
choices,
but
by
asking
the
questions
it
gives
visibility
and
and
facilitates
moving
towards
a
better
situation
and,
finally,
a
release
notes.
We
have
sort
of
like
a
bimodal
distribution,
people
either
say
no
release
not
required
or
bla
bla
bla
bla,
bla,
bla
bla
bla,
like
some
a
whole
bunch
of
stuff,
and
it's
hard
to
tell
some
of
those
really
verbose
things.
It's
like
did
that
really
matter
actually
and
the
ones
where
it
says
nothing.
You're
like
that
clearly
is
something
important.
A
Quinn
never
saw
it
because
she's
in
this
meeting,
so
it's
only
the
more
persistent
things
that
get
noticed,
and
then
all
of
us
in
aggregate
need
to
just
kind
of
try
to
have
a
pulse
on
things
and
watch
for
those
little
transients
that
go
by
so
that
Nick
doesn't
end
up
at
the
end,
with
a
list
of
500
really
verbose
things
that
seem
like
actual
trivia,
trivialities
or
500
issues.
That
look
really
scary.
That
say
nothing
about
what
the
impact
is.
Yeah.
H
A
Is
one
of
my
pet
peeves
as
well
and
I
think
that
we
as
a
release
team?
We
have
the
opportunity
to
interact
a
lot
with
individuals,
but
especially
with
cig
leads
and
one-on-one.
We
can
model
desired
outcomes
with
individuals,
but
that's
less
scalable
than
with
the
cig
leads.
So
if
you're
seeing
trends
like
that
really
remind
the
cig
leads
and
their
core
reviewers
and
approvers
that
we
need
to
avoid
a
tragedy
of
the
Commons
and
work
together
for
some
of
these
really
critical
quality
points
to
to
enable
the
overall
aggregate
to
be
more
healthy.
B
A
Definitely
so
feel
enabled
even
as
shadows
one
of
the
the
biggest
potential
outcomes
I
see
with
the
size
of
our
release.
Team
is
that's
more
more
eyes
to
notice
something
that
maybe
looks
a
little
questionable
and
to
ask
the
question
there:
there's
no
harm
or
foul
and
asking
the
question
and
best-case
it
results
in
a
better
outcome.
N
N
Milled
out
the
features
that
were
initially
in
the
2011
release
that,
where
I
hurt
by
Sigma
weeds,
are
effectively
removed
from
the
milestone,
have
been
added
to
the
Future
tracking
shape.
As
an
initial
step,
I've
done
some
quick
syncing
with
all
of
the
feature
shadows.
There
is
a
draft
of
the
features
lead
and
I
can
link
to
I
will
later,
but
over
all
the
features
processes
going
well.
I,
I
shied
noticed
your
comments.
N
I'll
be
working
on
making
sure
that
people
are
aware,
the
docs,
the
testing,
all
the
deadlines
as
I
start
snagging,
but
overall
people
are
being
responsive.
I'm,
seeing
ting
people
are
being
more
proactive
instead
of
reactive
with
regards
to
giving
the
futures
updating
so
definitely
a
better.
Since
then,.
A
So
one
thing
that
I'll
throw
out
there
just
as
a
reminder
kind
of
the
the
net.
Well,
there's
two
there
I
guess
I'll
just
say
that
the
next
major
date
that
people
should
be
aware
of
is
the
end
of
July.
July
31st
is
feature
freeze,
so
that'll
be
kind
of
the
the
initial
milestone
that
we're
working
towards
getting
a
really
good
handle
on
the
set
of
features
that
are
intended
to
be
coming
in.
B
A
And
if
you
want
to
do
that,
also
on
slack
just
kind
of
give
a
shout
out,
anybody
else,
who's
interested
and
whether
doing
that
or
if
say,
is
receiving
RI
or
going
to
a
particular
sig
on
a
particular
day
that
sig
meeting.
If
you
wanted
to
attend,
also
just
kind
of
see
and
hear
the
conversation,
it's
a
great
opportunity
just
to
kind
of
see
how
how
interaction
interactions
happen
and
it's
all
it's
lightweight
and
friendly
and
collaborative.
So
it's
nothing
to
be
intimidated
by.
But
it's
easy
to
get
a
sense
of
that.
D
Yeah,
okay,
so
I've
been
following
up
the
test
setup
under
master
blocking
and
up
didn't
answer,
so
we
do
have
a
bunch
of
reading
tests,
mostly
around
AWS
and
qaq
barium
and
networking
and
scalability
so
a
button
and
then
also
multiple
lovely
flaky
tests.
Now,
as
far
as
updates
are
concerned,
the
last
I
checked
there
was
one
failing
test
and
a
couple
of
Nikita's
I
just
checked
like
one
unit
ago
and
couple
more
have
appeared
that
so
I
ended
up
together,
have
more
issues
now
and
I.
D
Guess
we
need
to
keep
keep
an
eye
on
that
because,
as
we
go
on
more
and
more
stuff
starting
to
feel
about
flaky
tests,
so
I
was
just
thinking
about
how
do
we
and
how
do
you
make
sure
that
people
are
made
aware
of
the
flaky
tests
as
well
like
for
reading
test
videos,
issues,
of
course,
and
thank
me
time
right.
People
about
flaky
tests
are
not
what
that
meant
to
take
it.
As
when
our
shadow,
you.
B
B
Flaky
tests
I
would
still
go
ahead
and
file
an
issue
and
follow
up,
especially
if
the
frequency
of
flake
is
like
pretty
high,
so
it
doesn't
hurt
to
like
file
an
issue
and
definitely
especially
if
it's
in
the
race
blocking
dashboard,
then
we'd
want
them
to
look
at
it.
Sooner
than
later,
I
also
used
to
generally
send
out
a
weekly
flake
report.
B
I
haven't
been
doing
that
for
last
two
weeks
because
I've
been
traveling,
but
that
also
helps
people
take
notice,
they're,
roughly
crate,
and
generally
one
more
thing
when
you
sent
that
VT
CI
report,
maybe
if
you
want
to
you,
can
easily
call
out
flake
tests
there
as
well.
These
are
continuously
failures
and
these
are
like
flaky
tests
that
are
not
give
them
as
yeah.
G
J
R
J
A
And
I'm
not
sure
if,
if
the
team
broadly
would
be
interested
in
this
and
I
suppose,
I
could
lead
it
or
give
it
to
Mohammed
or
I
sure
anybody
who
really
wanted
to
volunteer,
but
something
that
might
be
useful
early
on
in
the
cycle,
is
to
just
give
a
little
walkthrough
of
test
grid.
How,
like
me,
maybe
maybe
Mohammed
if
you
were
to
just
kind
of
spend
five
minutes
like
okay
here,
I'm
gonna
share
my
screen,
I
haven't
looked
at
desperate
today.
A
Here's
how
I
click
around
and
look
at
things
and
kind
of
talk
out
loud
and
describe
what
you're,
seeing
because
test
grid
could
be
confused.
It's
it's
often
not
clear
where
you
can
put
your
mouse
and
click
and
how
to
tunnel
down
into
actual
detail
so
I'm,
seeing
a
number
of
thumbs
up
there.
So
I'll
put
that
on
the
agenda
for
for
next
week,
yeah.
D
A
A
Recall
having
trouble
with
the
PR
some
time
last
year,
where
a
simple
PR
that
was
like
changing
a
few
words
and
documentation
was
Faye
on
a
test.
A
kubernetes
functional
tests
like
clearly
not
related,
but
I,
was
able
fairly
easily
to
click
down
into
something
and
find
that
there
was
an
existing
issue
already
opened
for
this
set
of
flakes.
Well
I'll,
try
and
find
that
see.
If
there's
nothing
else,
I
can
go,
find
the
old
issues
and
see
if
I
can
map
where
that
had
been
coming
from,
but
I
don't
recall
seeing
those
lately.
A
A
B
Mohammed
I'd
I'm,
not
sure
if
your,
if
you
already
started
talking
to
the
GK
team
or
the
specific
teams
to
remove
the
non-blocking
test
from
the
released
logging
dashboard,
because
that
was
one
of
the
items
that
came
from
retrospect,
where
there
are
GK
specific
tests
that
are
there
in
the
release
blocking
for
blocking
the
release
on.
So
some
useful
comment
that
way,
it
will
take
you
a
take
out
the
number
of
jobs
that
you.
A
A
Okay,
well,
this
meetings
been
relatively
long
for
an
early
in
this
release.
Cycle
meeting
I
would
suspect
for
the
next
few
weeks
or
our
meetings
become
a
little
shorter
as
it's
a
quieter
part
of
the
the
the
cycle
and
then,
as
we
get
into
later,
August
and
especially
in
September,
things
will
wrap
up
quite
a
bit
in
intensity.
So
I
appreciate
all
your
time
today
and
I'll
schedule
a
early
Tuesday
meeting
early
Pacific
time
for
the
next
two
weeks,
and
we
can
just
kind
of
try
all
that
and
see
how
it
goes.