►
From YouTube: Kubernetes Meet Our Contributors March 2019 2nd Session
Description
When Slack seems like it’s going too fast, and you just need a quick answer from a human...
Meet Our Contributors gives you a monthly one-hour opportunity to ask questions about our upstream community, watch interviews with our contributors, and participate in peer code reviews.
Check this out for more information: https://github.com/kubernetes/community/blob/master/mentoring/meet-our-contributors.md
A
Hello
kubernetes
world.
Welcome
to
the
second
edition
today
of
meet
our
contributors
today
is
March
6th.
We
do
this
every
month
on
the
first
Wednesday
of
every
month
at
7:30
a.m.
Pacific
and
1
p.m.
Pacific
time.
These.
This
is
recorded
as
well
and
will
be
posted
to
YouTube.
So
if
you
miss
something
feel
free
to
go
back
and
get
it
first
off,
thanks
to
the
folks
that
are
joining
us
today,
taking
time
out
of
their
day
to
help
us
understand
kubernetes,
upstream
contributing
a
little
bit
more.
That's
awesome.
A
We
have
a
saying
in
this
community
is
that
you
can't
know
everything,
so
don't
even
try,
but
these
folks
are
here
to
at
least
help
you
get
unblocked
in
whatever
area
that
you
are
in
right
now.
Also
thanks
to
George
Castro,
who
is
our
VJ
today,
helping
us
out
with
the
YouTube
stream,
make
sure
that
is
going
awesome
and
to
make
sure
that
you
can
hear
us
and
all
that
other
good
stuff
George
works
at
VMware
thanks
for
George's
time,
VMware,
alright
and
then,
of
course,
we
do
have
a
code
of
conduct.
A
Today,
that's
valid
on
all
of
our
channels.
That
goes
for
our
panelists,
as
well
as
the
people
that
are
participating,
answering
questions
or
asking
questions
how
to
participate.
Today
we
are
doing
a
few
different
ways.
One
is
through
our
slack
Channel
and
that's
meet
our
contributors
on
the
kubernetes
slack.
If
you're
one
of
60,000
people
feel
free
to
ask
access
that
there
there's
also
a
discuss
thread
on
discussed
kubernetes
io,
that's
our
web
forum
that
we
use
feel
free
to
ask
questions
on
the
thread.
A
That's
that
you'll
see
in
the
contributors
channel
there
and
there's
also
Twitter
stuff
floating
around
in
Twitter
fete
and
Twitter
space.
Dm
me
there.
If
you
see,
if
you
see
anything
so
short
short
story
is
get
us
a
question
and
we'll
figure
out
how
to
answer
it,
and
we
already
do
have
a
few
questions
that
you
doubt,
which
is
awesome,
but
first
things.
First,
we're
actually
gonna.
Do
some
intros,
really
quick.
Let's
see
dims,
you
start
hi.
B
My
nickname
is
dims,
I
have
a
longer
name.
So
ask
me
on
slack,
if
you
want
to
know
I
work
on
a
few
things
here,
mostly
I
try
to
look
look
for
problem
areas
where
other
people
are
not
working
on
stuff,
or
maybe
things
that
I've
gone
bad
still,
and
no
no
one
has
taken
care
of
it
that
kind
of
stuff.
You
know
I
like
to
do
that
kind
of
work,
so
I
work
across
a
few
SIG's
like
cig
testing,
and
you
know
cig
release
and
I'm
on
the
steering
committee
as
well.
A
Awesome,
thank
you
and
again.
I'm
Parris
orchid
Google
do
fun
contributor
experience
related
stuff,
like
this
George
Jonah
wave
ray.
If
George
he's
he's
behind
the
veil,
all
right
and
so
again,
we've
already
got
some
good
questions
queued
up
here
and
every
time
I
get
a
DM.
And
again
that's
it's
okay,
if
you're
anonymous,
I'll,
just
post
it
for
you
in
the
Select
Channel.
So
the
first
question
today.
What's
one
thing
you
wished,
you
knew
about
contributing
in
the
beginning
that
would
have
helped
you
more
get
started.
C
Sure,
let's
see
so
on
on
main
kubernetes,
like
the
list
of
the
list
of
scripts
that
take
forever
to
run
versus
the
list
of
scripts,
that
you
can
run
quickly
and
like
when
you
generally
have
to
run
the
scripts
that
take
forever
to
run
so
like
some
of
the
especially
for
a
while
some
of
like
the
code
generation
scripts
took
forever
and
like
a
lot
of
times.
C
C
So
I,
if
you're,
if
you're
working
on
like
an
API
change,
so
things
like
the
the
deep
copy
gen
code,
which
I
think
it
is
behind
update
code
gen
is,
is
probably
like
the
really
big
one
and
or
updating
like
the
conversions.
If
you're
working
on
API,
if
you're
not
working
on
an
API
change
chances,
are
you
don't
need
to
touch
most
of
the
code
gen
and
just
making
sure
to
like
manually
run
stuff
like
go
format
on
the
individual
files?
C
You
changed
and
then
you
know
like
once
before
you
submit
your
PR,
then
do
like
a
run-through.
It's
like
making
sure
you
haven't
missed
like
a
bunch
of
the
go
format
or
like
making
sure
you
run
update
Basel.
Just
before
you
push
your
PR
to
make
sure
you
haven't
missed
any
of
the
basel
file
updates
or
something
like
that.
But
in
the
meantime,
for
most
changes,
I'd
say
probably
just
making
sure
you're
running
updating,
go
format
individually
and
save
most
of
the
generation
scripts.
For
the
end
right,
yeah
matches.
B
My
experience
exactly
so
for
me
it
was
it's
it's
as
the
people
here
are
very
welcoming,
but
they
need
to
get
to
know
you.
So
you
have
to
kind
of
say
what
you
do,
what
your
background
is
and
how
you
could
be
helping,
because
otherwise
they
don't
know
you
and
they
don't
know
when
to
call
on
you
so
and
that
takes
a
little
bit
of
a
time.
So
don't
be
shy,
you
know
introduce
yourself
at
meetings,
you
know
when
the
six
have
meetings
and
you
know
show
up
on
pull
requests
and
issues.
B
Even
if
you
have
reviewed
something-
and
you
do
not,
you
know
everything
looks
good
to
you.
Just
leave
a
note
saying
that
you've
reviewed
it
and
you
know
what
you
like
and
what
you
don't
like
what
you
can
do
better.
You
know
some
some
information
about
yourself
and
you
know
so.
People
can
know
that
you
are
actually
looking
at
things
and
what
kind
of
things
you're
looking
at.
So
we
can
call
upon
you
the
next
time
when,
when
we
need
you
essentially.
A
B
Typically,
what
we
point
out
is
look
look
for
an
issue
that
so
the
best
things
to
work
on
are
the
things
that
affect
you.
If
you
see
a
problem
like
yesterday,
we
broke
a
script,
a
bad
step
by
when
we
were
making
changes
for
something.
Typically,
you
know
we'd,
you
would
have
found
it
if
you
were
running
if
you
caught
it,
you
know
just
after
that
change
got
merged.
So
so
things
like
that
right,
there
is
always
things
just
due
to
the
velocity
or
the
project.
B
There
are
things
when
we
start
making
changes
in
one
place,
it
might
affect
other
places.
So
sorry
going
back,
so
you
try
to
fix
something
that
matches
your
needs
say.
You're
working
on
OS
X
try
to
get
something
working
which
wasn't
working
before
say
you
are
using
a
feature,
and
there
is
like
small
things.
Some
small
thing:
that's
bothering
you
about
like
a
field
in
one
of
the
api's,
or
something
like
that.
C
Scratch
an
itch
even
if
it's
just
like,
like
Tim,
said
even
if
it's
just
like
oh
yeah,
this
script,
like
assumes
something
that's
not
true
about
my
system
and
it's
just
something
reasonable,
reasonably
easy
to
fix
or
like
this
test.
I
was
looking
at
this
test
to
try
to
figure
out
how
this
feature
was
supposed
to
work,
and
the
test
is
really
hard
to
follow
and
I
think
I
could
reactor
it
to
make
it
easier
to
follow.
C
If
you
happen
to
be
interested
in
an
area
that
has
also
has
good
like
Help,
Wanted
or
a
good
first
issue,
tag
look
to
see
if
those
are
available,
they're
not
always
available,
and
sometimes
it's
hard
to
can
be
hard
to
apply
them
just
depending
on
like
whether
or
not
you
have
an
a
lot
of
issues
with
like
design,
nuances
and
them
or
stuff,
but
like
if
you're
in
an
area.
Look
look
to
see
if
they're
there
and
those
are
usually
just
chime
in
and
be
like.
C
C
I
think
we
have
a
couple
in
the
Q
builder
project
that
are
are
like
this
is
a
helper
or
utility,
or
a
feature
that,
like
people
have
asked
for
a
couple
of
times
that
are
that
would
be
relatively
easy
to
implement.
I
can
like
I,
can
actually
see
if
I
can
drop
some
links
in
the
chat.
If
people
are
interested,
which.
C
A
Tying
to
put
people
on
the
spot
to
do
those
things,
I
didn't
just
I,
see
James's
smile,
all
right,
all
right
next
question
figuring
out
who
owns
something
for
review,
isn't
easy,
any
tips,
so
I
guess
from
a
current
contributor
who's.
Looking
for
some
reviews
and
not
sure
of
where
to
go
exactly
right.
B
So
here
are
the
breadcrumbs
for
it
right
so
you
say:
you're,
making
a
change
in
a
subdirectory
go
look
at
the
owners
file.
That
is
there
in
subdirectory.
It
typically
has
a
list
of
reviewers
and
or
approvers.
So
go
look
there
first,
then,
if
it's
not
there
then
go
up
the
directory
hierarchy
till
you
find
one
right.
So
that
is
one
technique.
The
other
technique
is
to
have
a
general
idea
of
which
sick
this
could
be
belonging
to.
B
So
there
are
individual
people
who
are
reviewers
and
approvers,
and
also
the
code
belongs
to
assay,
so
you
have
to
kind
of
figure
it
out
and
if
you
can't
figure
it
out,
just
just
ask
ask
us:
the
third
tip
is
look
at
the
get
blame
history
of
people
who
have
touched
that
code
right.
So
between
these
three
things,
you
should
be
able
to
get.
A
good
idea
of
you
know
who
will
be
a
good
set
of
people
to
talk
to
the
other
tip
is
when
the
bot
picks
up
your
PR.
B
It
automatically
assigns
folks
as
well
or
it.
It
will
tell
you
to
assign
people,
and
it
will
give
you
some
clues
on
who
might
be
a
good
fit.
Sometimes,
if
you
are
making
a
large
amount
of
changes,
what
we
call
route
owners
will
get
involved,
because
the
bot
is
trying
to
select
a
minimum
set
of
people.
And
if
you
are
touching
a
lot
of
files
in
across
multiple
directories,
then
it
will
ask
somebody
who,
like
you
know,
Brian
or
Tim,
or
somebody
very
senior
who
will
who
will
need
to
you-
need
to
pull
it.
C
So,
just
following
up
on
on
what
I
promised
a
moment
ago,
it
occurs
to
me
that
actually
a
number
a
couple
of
our
few
of
our
good
first
issue.
Issues
were
actually
just
taken,
so
I
need
to
go
through
and
triage
and
make
sure
I
haven't
missed
any
more,
but
another
option
is
to
kind
of
so
for
areas
that
use
the
priority
flags
look
for
things
that
are
like
marked
as
not
like,
immediately
critical,
urgent,
because
those
are
or
or
important
soon
but,
like
maybe
important,
long-term,
which
kind
of
means.
C
We
want
to
do
this
eventually,
but
it's
not
like
our
immediate
priority,
and
then
that
probably
means
that
there's
some
good
room
for
you
to
take
some
time
to
get
to
know
stuff
in
like
figure
stuff
out
and
so
I
can
I'll
drop
a
link.
But
there
are
a
couple
of
there
are
a
couple
of
pretty
clear
ones
ranging
from
like
we
should
have
better
examples
of
how
to
use
the
context
argument
with
our
clients
to
like.
B
Right
so
another
thing
that
I
will
give
you
an
example
is
say
you
you
want
to
figure
out
how
you
know
the
code
base
is
structured.
How
how
things
are
put
together,
go
look
at
the
vendor
directory
and
look
at
all
the
dependencies
that
we
dragged
in
right
from
other
co
projects
and
then
try
to
you
know,
search
and
figure
out
where
those
files
are
you
with
the
packages
that
we
render
and
are
used
and
see.
B
If
we
it's,
those
vendor
projects
are
really
needed
or
not,
and
whether
you
can
just
write
a
new
function
to
replace
one
entire
library
because
from
the
library
only
one
function
is
being
used.
You
know
things
like
that.
You
can
do
to
familiarize
yourself
with
the
code
also
the
build
process
and
looking
at
the
logs,
what
failures
to
expect?
What
values
you
will
see
and
kick
the
tires.
You
know
that's
a
good
way
of
trying
to
do
stuff.
Just
cleaning
up
the
vendor
vendor
lists.
A
Good
tips
and
that
actually
flows
in
nicely
to
the
next
question
and
this
person
it
sounds
like
they're
sort
of
confused
about
the
group's
occur
Burnett
is
in
general,
so
like.
What
like
tell
me,
tell
us
a
little
bit
about
Dems
and
I.
Think
you're
gonna
be
perfect
to
answer
this,
like
what's
a
sake,
what's
a
working
group,
what's
a
sub-project
just
that,
like
a
high
level
breakdown
of
what
some
of
those
groups
are
right.
B
B
To
be
able
to
do
this
delegation,
the
sig
has
to
write
a
charter
and
say
this
is
what
we
are
responsible
for.
For
example,
you
can
look
at
the
charter
for
six
storage
or
sink
node
or
any
sig
release
or
suggesting,
and
they
they
will
say
what
pieces
of
Cuban
interests
that
they
own
so
and
the
once
the
steering
committee
approves
the
Charter.
Then
the
six
essentially
can
go
do
what
they
want
to
do
and
to
do
what
they
want
to
do.
B
Essentially,
we
are
talking
about
creating
git
repositories,
setting
up
CI
jobs,
owning
code,
owning
releases,
building,
container
images,
shipping,
but
container
images
release
artifacts
in
you
name
it.
Those
are
all
things
that
six
work
with
each
other,
for
example,
signal
works
with
sig
testing
and
similes,
for
example
right.
So
that
is
this
overall
structure
between
the
steering
committee
and
the
six
and
to
organize
the
work
within
the
sink.
You
can
have
sub
projects.
B
For
example,
if
you
take
say
cluster
life
cycle
right,
it
has
a
number
of
projects,
including,
like
mini
tube
kind,
QB,
diem,
and
things
like
that.
So
each
of
them
are
sub
projects.
We
are
trying
to
it
exactly
nail
down
what
and
write
what
a
sub
sub
project
is.
I,
don't
believe
we
have
a
pair
up
for
that
yet.
B
We
sorry
one
more
okay,
one
more
entity
that
is
crawling
in
right
now,
which
we
call
user
groups
is
that
what
they,
what
we
call
them
I
think
so
so
the
user
groups
are,
are
what
we
call
them:
Parris,
yeah,
okay,
so
the
user
groups
are
more
like
six.
There
are
they
used
to
be
six
like
sig,
big
data
which
didn't
own
any
code.
So
what
we
are
trying
to
do
is
turn
them
into
like
informal
birds
of
a
feather
kind
of
an
organization
where
they
can
meet.
B
B
For
example,
there
is
a
working
group
that
I'm
leading
where
we
we
are
essentially
trying
to
take
control
of
the
infrastructure
that
we
rely
on
for
the
day-to-day
business
of
of
Cuba
renters
from
Google
infrastructure,
to
CN,
CF
infrastructure
so,
and
that
spans
multiple
SIG's
and,
by
definition,
the
user
groups
and
the
working
groups
do
not
own
code
or
release
artifacts.
Sorry,
sorry,
please
go
ahead.
Okay,.
C
So,
for
instance,
you
have
sig
API
machinery,
which
is
the
sig
that
is
in
charge
of
everything
having
to
do
with
the
nitty
gritty
bits
of
interacting
with
it
and
building
the
kubernetes
api
so
from
the
parts
on
the
server
that
actually
generically
serve
api's
for
different
kubernetes
resources
to
the
bits
on
the
client
for
interacting
the
standard
clients
for
interacting
with
those
api
is
all
of
that
is
owned
by
api
machinery
and
then
so.
The
sub
project
that
I
I,
hopefully
a
cute
builder,
is
kind
of
specifically
designed
around.
C
A
But
I
actually
wanted
to
recycle
a
question
from
this
morning
session
because
it
was
so
vaguely
good.
It
actually
brought
out
some
really
good
responses.
I
thought
and
the
question
from
this
morning
was
name
one
thing
that
you
think
is
a
priority
for
the
community
to
focus
on
right
now,
so
nice
and
big
yet
will
capture
what
we
think
is
a
priority
to
you.
B
So
the
priority
to
me
is
trying
to
encourage
people
to
participate
and
own
pieces
of
things
that
we
do
and
trying
to
do
that,
so
that
it
gives
more.
We
are
growing
like
crazy.
You
know
no
questions
asked
if
you
look
at
anything
from
number
of
slack
interactions
to
the
code
or
the
number
of
users
or
whatever
statistics
you
take.
We
are
growing
like
crazy
and
we
need
to
have
a
structure
in
place
where
we
are
promoting
people.
B
You
know
people
are
doing
their
work
and
they
are
getting
recognized
for
what
the
work
that
they
are
doing
and
they
have
a
ladder
to
aspire
to
within
the
project
and
how
they
can
do
better.
You
know
for
their
own
career,
as
well
as
for
the
good
of
the
health
of
the
project
as
well
that
that
I
think
is
my
first
priority
at
this
point.
I.
C
This
way
we
write
controllers.
Where
you
you
set
up
some
informers
which
generate
which
produce
events,
which
you
then
add
to
a
queue.
And
then
you
pop
this
up
off
the
queue
and
you
make
decisions
on
whether
or
not
to
do
stuff
with
that
there's
a
lot
of
duplicated
code,
but
it's
all
done
slightly
differently
and
it
means
that
people
going
in
to
contribute
are
a
going
to
have
to
know
how
to
filter
out.
C
This
is
all
the
common
code
versus
this
is
like
the
actual
meet
of
the
controller
that
I
actually
want
to
care
about.
Looking
at
and
be,
they
have
to
learn
like
okay,
this
bit
of
code
in
this
bit
of
code,
even
though
they
look
like
they're
different,
are
actually
doing
the
same
thing,
because
they
popped
into
existence
at
different
times
in
the
project
and
so
I
think
we
can
buy.
A
A
C
Well,
I
some
of
that
is
like
knowing
the
right
people
to
talk
to
so
like,
for
instance,
one
of
the
working
groups.
That's
working
on
a
number
of
factors.
Right
now
is
the
component
standard
working
group,
and
so
that's
that's
kind
of
working
on
refactoring
out
some
of
our
common
infrastructure
like
how
do
we
set
up
logging
in
flags
across
all
of
our
binaries?
C
How
do
we
set
up?
How
do
we
move
from
flags
to
decorative
configuration
files
for
some
of
our
binaries
and
some
of
that's
like
large
overarching?
How
do
we
design
all
of
kubernetes
kind
of
things,
but
there's
a
lot
of
within
those
bits,
there's
a
number
of
small
things
that
are
like
okay.
We
know
this
particular
combination
of
behaviors
is
kind
of
hacky
we'd
like
to
make
it
clearer
and
so
like
show
up
there,
for
instance,
and
say:
hey
is
there
like?
What
do
you
need
help
with?
Is
there
something
that
I
can
help
ship.
B
B
I
can
give
another
example
similar
to
what
you
were
saying.
So
typically,
cuban
artist
is
tested
on
GC,
gke
kind
of
environments,
but
a
lot
of
people
use
these
things
on
AWS
and
OpenStack,
and
other
places
too
so
thing
that
we
are
trying
to
do
is
like
Moo
remove
cold
actually
from
the
Cuban.
It
is
Cuban.
It
is
repository
and
run
them
as
like
separate
binaries,
which
is
specific
to
your
own
cloud
right.
B
So
the
idea
here
is
what
you
can
do
is
say:
you're
using
the
cloud
provider
against
one
specific
provider
which
is
not
highly
tested.
So
then
what
you
can
do
is
you
can
see
if
the
external
version,
external
cloud
controller
of
the
same
thing
has
all
the
features
that
you
need
and
if
something
is
missing,
then
you
can
work
with
us
to
figure
out
what
is
the
right
way
to
do
it,
for
example,
one
example
would
be:
you
are
using
a
storage
provider
there.
B
B
You
know
across
you
know
the
combinatorial
explosion
right.
So
what
you
can
do
is
you
can
test
these
things
in
your
own
environment,
with
your
own
combination
and
see
if
these
things
work
and
tell
us
what
doesn't
work
and
maybe
do
a
small
patch?
And
you
know
you
contribute
that
way
as
well,
because
we
don't
have
access
to
everything
around
the
world.
You
know
and
we
need
your
help,
trying
things
out
as
well.
Hey.
C
B
B
B
That
is
going
to
be
available
across
all
the
different
vendors,
and
you
know:
if
I
run
this
set
of
tests,
then
it
gives
me
an
assurance
that
I'll
be
able
to
do
the
same
thing
if
I
move
to
another
provider.
But
then
you
will
run
into
all
these
issues
about
but
I'm,
using
this
storage
vendor,
but
I'm
using
this
networking
thing,
but
I'm
using
this
other
thing.
So
how
do
we
test
for
conformance?
B
A
C
I
have
a
few
things:
I
sometimes
collect
like
little
like
quality
of
life,
things
that
I'd
like
to
help
out
with,
but
like
always
run
out
of
time,
so
like
our
test
infrastructure
currently
doesn't
expose
the
intermediate
like.
So
when
you
write
end-to-end
and
integration
tests
in
kubernetes,
we
use
this
tool
called
this
testing
framework
called
ginko,
which
I
think
is
actually
really
awesome.
C
So
if
you,
for
instance,
like
if
you're
writing
a
test
and
it
you
say
it
should
do
to
blow
a
little
blah,
you
can
then
write
like
sub
lines
in
that
saying
by
this
by
that,
and
so
so,
like
let's
say
you
have
a
test
like
a
client
duck
yet
you're
saying
describe
client
thought,
yet
it
should
fetch
the
object
from
the
server
and
deserialize
it
into
go
type
way,
and
so
you
might
say,
by
constructing
a
new
rest
client
by
making
a
call
to
the
server
by
checking
that
it
actually
deserialized
the
right
information
on
those
by
lines
are
ideally
help.
C
You
figure
out
like
where
the
test
went
wrong
within
the
test
and
our
test
infrastructure.
Because
of
the
way
we
generate
our
test
output
doesn't
expose
those
by
lines
very
well.
It
exposes
the
it's
the
it
statement,
but
it
doesn't
expose
the
underlying
five
lines
and
so
like
when
a
test
fails,
those
could
potentially
be
really
useful
in
figuring
out
why
it
failed,
so
I
would
love
to
go
and
fix
that
and
I
haven't
I
have
a
few
things
like
that
that
are
just
like.
C
B
C
Yeah
it's
and
it's
something
like
that
could
turn
into
a
long
like,
and
those
can
actually
be
interesting
places
to
get
started
right
because,
like
they
might
not
be
initially,
the
vast
like
immediate
I'm
gonna,
turn
around
and
get
something
submitted,
but
sometimes
they
end
up
taking
you
through
some
an
accidental
tour
of
the
codebase,
and
you
end
up
learning
about
all
sorts
of
things
that
you
didn't
know
before.
So
you
might
end
up
learning
like
with
the
ginko
one
like
you
might
end
up
lurking.
C
Okay,
how
do
we
turn
our
our
test
output
into
a
structured
test
output?
How
does
that
get
fed
into
our
testing
dashboard?
And
so
you
might
end
up
being
like
starting
out
like
oh
I'm,
just
gonna
make
sure
that
my
lines
are
exposed,
and
you
know
you
end
up
learning
how
kubernetes
does
its
testing
I
give.
B
You
one
more
example
right
flakes.
We
are
beset
with
flakes.
The
flakes
are
essentially
tests
that
passed
most
of
the
time,
but
they
fail
from
off
the
time.
So
what
and
we
do
have
dashboards
which
surface
the
data
which
CI
jobs
are
flaky,
which
tests
are
flaky
in
the
CI
jobs?
So
we
mean
kind
of
like
bug,
hunters
who
are
willing
to
take
this
on
and
try
to
figure
out
what
to
target
all
the
top
flakes
and
try
to
figure
out
a
way
to
you
know
make
sure
that
we
can
get
rid
of
them.
B
So
that
would
be
a
very
interesting
thing
to
do
so.
This
would
be
like
trying
to
figure
out.
You
know
what
is
the
frequency
of
the
flakes
the
you
know.
Do
they
happen?
Do
they
have
how
many,
which
kind
of
jobs
do
the
flakes
happen
in?
Is
it
specific
to
a
cloud
provider
or
is
it
in
not
specific
to
a
cloud
provider?
So
you
have
all
these
things
that
you
can
try
to
narrow
down,
but
it
will
also
help
you
to
learn:
go
through
the
codebase.
B
Look
at
the
e
to
e
tests,
how
the
e
to
e
test
works
and
then
what
are
the
logs
for
a
good
run?
What
is
the
log
for
a
bad
and
then
trying
to
pinpoint
to
to
the
point
where
you
can
say?
Okay,
this
is
the
file.
This
is
probably
the
method
where
you
know,
wherever
you
know
something
is
triggered,
is
failing,
and
then
you
have
to
go
through
logs
and
try
to
figure
out.
Is
it
a
timing
issue?
Is
it?
You
know
something?
B
C
Errands
errands
actually
errands
here
in
spirit
but
I,
which
I
mean
he's,
been
dumping,
helpful
links
and
information
into
the
meet
our
contributors
channel
so
and
also
a
a
video
on
walking
through
tracking
down
flakes
from
the
contributor
summit.
So
if
you're,
if
you're
interested
in
that
there's
a
bunch
of
Link's
errands
slack
handle
is
Biff
XP.
So
if
you
look
for
this
Biff
XP
messages,
you
can
see
some
really
awesome.
Information
he's.
A
A
B
Steering
company,
so
the
steering
committee
is
trying
to
what
is
it
trying
to
do
so
we
used
to
have
a
product
security
team,
it's
turned
and
we
turned
it
into
a
committee.
So
that's
just
a
logistical
stuff
that
we
had
to
take
care
of.
So
one
thing
that
is
also
happening
is
there
is
we
have
been
talking
about
bug
bounty
stuff,
so
you
will
hear
some
of
it
coming
through
soon,
then.
B
We
have
to
formalize
the
what
is
the
sub
project
as
well,
that
that
is
another
thing
that
is
important,
but
just
recently
we
were
working
with
all
the
charters
from
different
sticks
and
making
sure
that
everybody
has
a
charter
and
their
charter
was
approved
so
that
that
was
a
big
thing
that
we
were
doing.
What
was
the
other
thing?
The
other
thing
that
we
we
are
kind
of
investigating
is
CVS.
If
you
have
not
been
under
a
rock,
you
would
have
heard
about
all
the
different
CDs
that
you
know
we
have
been.
B
You
know
fighting
but
against
as
well
right.
So
we
have
a
lot
of
dependencies
lavender
dependencies
that
we
are
talking
about
right.
How
do
we?
We
already
have
a
process
for
security,
disclosure
and
stuff
like
that?
So
and
we
have
security
team
in
place
and
we
have
processes
in
place
to
it
too,
and
a
secure
test
environment
where
people
can
go,
try
things
out
and
disclosure
mechanism
by
which
people
are
notified,
and
you
know
there
is
all
kinds
of
stuff
that
usually
happens
in
a
security
process,
yeah
so
CVS.
B
So
we
are
trying
to
figure
out
how
we
can
get
a
better
handle
on
our
vendor
dependency,
especially
if
there
is
something
like,
for
example,
we
render
in
docker
docker
repository
we
render
in
Lib
container
what
if
there
is
a
CBE
in
one
of
those
dependencies.
How
do
we
track
them?
How
do
we
get
notified
when
there
is
a
problem
somewhere
else
in
the
ecosystem,
gulang
ecosystem?
B
A
B
Absolutely
it's
every
other
week
it
was
supposed
to
be
in
the
same
slide
time
slot
as
this
one
so
the
next
week
you
should
come
to
the
steering
wheel
to
get
watch
this
on
video
right
Paris.
Yes,
exactly
but
yeah,
really
you!
The
steering
committee,
has
a
public
mailing
list.
The
steering
committee
now
has
a
public
meeting.
B
Introduce
yourself
when
this
steering
committee
you
know
meets
as
well.
If
you
have
some
business
just
say
hi,
and
this
such-and-such
and
I
was
interested
in
whatever
question
you
wanted
to
ask.
So
please
be
vocal,
please
step
up,
we
need
you
and
we
don't
know
who
you
are.
So
please
take
the
first
step
forward
from
your
side
and
then
you
know
hopefully
we'll
be
able
to
engage
you.
It.
A
C
B
So
it's
when
you
have
to
escalate
stuff
from
the
SIG's
or
the
working
groups
or
the
user
groups.
Typically,
we
have
two
destinations
either
the
cigar,
collector
or
the
steering
committee.
The
steering
committee
tries
to
stay
away
from
the
technical
decisions
and
you
know,
and
vice
versa.
So
again,
so
you
go
to
if
you
have
like
an
issue
say
how
the
hell
we're
doing
install
CRTs
at
when
when
Cuban
artists,
arts
and
Solly
is
you
know
in
that
mix
as
well
right
so
I?
B
B
Yeah
but
that's
the
way
it
works,
so
if
you
want
to
escalate-
and
you
talk
to
the
cygnets
and
take
them
matter
to
the
cigar
collector,
there
is
a
again
there
is
a
mailing
list.
I
know
that
not
it's
not
convenient
for
everybody
because
of
time,
zone,
issues
or
timing
issues.
So
please
use
the
slack
Channel.
Please
use
the
meaningless
and
then
throw
things
onto
the
agenda
with
enough
information,
so
people
can
and
possibly
delegate
somebody
to
go
talk
on
your
behalf,
if
you're
not
able
to
make
it
I.
C
Think
this
is
also
a
case
of
like
maybe,
if
you're
like,
if
you're,
just
starting
out
on
contributing
to
kubernetes
like
you
might
not
need
to
care
as
much
about
the
steering
committee
or
sake
architecture
immediately
but
like
as
you
as
you
get.
You
know
more
experience
with
the
project.
If
you
decide
hey,
like
I
kind
of
want
to
keep
an
eye
on
like
some
of
the
meta
questions
of
the
project
as
a
whole,
not
just
like
my
particular
area,
but
like
things
that
affect
the
entire
project
it
can
be.
C
It
could
be
really
interesting
and
enlightening
to
start
even
just
like
listening
in
on
meetings
or
reading
through
what
the
meeting
notes
and
the
decisions
are.
And
you
know,
maybe
you
see
something
that
you're
like
I/o
conformance.
This
is
really
cool.
I
would
love
to
start
helping
out
with
conformance,
and
so
you
see
something
that
you're
interested
in.
C
You
find
another
kind
of
larger
project
area
to
contribute,
to
and
and
also
like
in
general,
as
the
project
leadership
tries
very
hard
not
to
bite
so
like
all
the
sig
weeds
and
the
sub
project
leads
and
the
steering
committee
members
are
all
all
people
right
so
feel
free
to
approach
and
and
say
hi.
If
you
have
questions
or
whatever
right.
B
The
other
tip
I
can
give
you
is
about.
How
do
we
work
right?
So
typically,
you
find
an
issue
and
then
you
have
a
discussion
in
a
sink
meeting.
You
throw
it
open
to
other
people
by
writing
an
email
to
the
mailing
list,
maybe
even
Kuban.
It
is
dev
and
then
you,
when
you
have
some
kind
of
consensus,
then
you
write
a
cap
and
when
you
write
a
cap,
that's
when
people
will
have
to
like
agree
to
what
you're
saying
or
disagree,
and
then
you
know,
depending
on
the
dispensation.
B
C
B
B
But
remember
it's
not
a
waterfall
model
bit
where
you
are
trying
to
do
everything
up
in
front
up
up
in
front
it's
a
living
document.
So
once
it
merges,
you
still
have
to
keep
update
updating
with
the
research
the
options
and
which
one
will
got
picked,
and
so
it's
a
living
document
which
will
also
help
the
cig
release
and
cig
testing
and
the
people
who
put
out
blog
posts
you
once
we
do
the
release
to
figure
out
what
exactly
of
the
changes
that
ended
up
in
a
specific
and.
C
And
even
even
contributors
going
back
and
looking
at
like
hey,
why
did
we
decide
to
do
this
thing?
The
way
it
is
it's
kind
of
like
it's
kind
of
weird?
Hopefully
the
idea
is
that
you
can
go
and
look
at
the
cap
that
introduced
it
and
you
can
see
like
this
is
how
it
ended
up
the
way
it
was.
It
was
originally
proposed.
Like
this.
We
considered
these
options.
We
decided
that
these
options
other
options
weren't
good,
so
we
went
with
this
one
we
started
implementing.
A
B
C
B
A
That's
quick
chair
of
the
LTS
group,
paying
me
to
say
that
so
enjoy
your
sponsor
to
add
I'm
just
kidding
anyway,
no,
but
that
does
wrap
up
the
March
editions.
Now
that
we've
been
for
both
of
them
of
meat,
our
contributors,
next
April
I
know
we
already
have
a
code
based
or
lined
up.
We've
got
some
really
awesome
stuff
again,
our
episodes
are
7:30
in
the
morning
Pacific
time,
1
p.m.