►
From YouTube: 20190419 testing commons
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
B
So,
we've
been
getting
a
lot
of
contributors
helping
there
we're
finding
that
some
of
the
packages
are
really
some
of
the
files
are
really
easy
to
clean
up,
but
some
of
them,
like
util
dot,
go.
It
is
massive
and
a
lot
of
things
are
importing
things
from
that,
and
so
John
and
I
started
collaborating
on
a
Google
Doc
on
how
we
can
break
just
util
dot,
go
into
separate,
smaller
tasks,
and
so
we
wanted
opinions
on
what
people
think
how
people
think
this
can
be
broken
up
too.
B
So
in
the
doc,
what
I
did
was
I
just
printed
out
all
the
methods
in
Utah
CO
and
then
I
put
a
proposed
package
structure
for
how
we
should
where
we
should
move
all
these
files.
So
what
we
can
do
is
like
we
can
delegate
a
package
to
each
person
and
then
each
person
can
go
through
the
list
of
methods
see
if
it
belongs
to
that
package
and
then
open
it
up.
A
That
seems
reasonable
to
me.
I
was
actually
doing
a
PR
review
for
somebody
who
submitted
a
massive
goal
in
to
modification
for
util,
deco
and
I.
The
first
thing
I
looked
at
this
last
week,
was
that
it
is
a
ginormous
thunk,
so
I'm
wholeheartedly
in
support
of
it,
because
in
particular,
I
was
never
saying
there
was
there
were
things
specific
to
given
areas.
B
A
The
one
thing
it's
gonna
be
a
little
bit
weird
or
common
functions
right
and
how
they
get
used
across
some
of
it.
I
think
just
teasing
it
apart.
One
by
one
will
is
the
way
to
go
and
start
with
the
simple
ones
so
I
could
eat.
You
could
easily
tell
right
away
that
node
and
pod
or
easy
to
disentangle,
because
I
was
looking
at
that,
like
just
the
other
day.
A
Some
of
the
other
ones
like
there's
there's
services
should
be
reasonable
to
disentangle
and
point.
Should
you
reasonable
this
dangle
some
other
ones
are
gonna,
be
a
little
bit
weirder
just
because
the
cascading
dependencies
but
I
start
signal,
I,
think
pause
and
nodes
make
a
ton
of
sense.
It
should
be
easy
there
about
I
liked.
The
idea
I
think
should
go
forth
and
do
it
alright.
I
would
add
it
to
that
umbrella
issue,
though
so,
if
looking
over
here,
where
is
the
this
one,
maybe
add
the
dock
as
a.
B
A
A
I,
don't
know
if
it's
people
that
are
working
on
this
one
or
people
that
are
overlapping
with
the
conformance
effort,
because
I
know
people
watch
the
recordings,
because
there's
a
bunch
of
people
who
are
submitting
patches
that
are
not
on
the
call,
and
so,
if
you're
listening
later
on,
I
do
appreciate
Golant
style
PRS,
but
they're
not
of
greater
importance
at
this
point
so
like
actually
executing
against
the
milestones.
If
you
want
to
lint.
A
Alongside
of
doing
these
modification,
that's
even
better
right,
because
sometimes
when
I,
when
I
get
a
bunch
of
onesie
twosie
PRS,
it's
can
be
time-consuming
to
try
and
figure
out
what
effort
this
is
going
along
with.
And
whether
or
not
it's
a
Rando,
because,
like
part
of
part
of
being
an
approver,
is
figuring
out.
If
people
want
to
be
engaged
in
the
community
or
if
they're
just
doing
flybys
right
and
if
a
person
wants
to
be
engaged
in
the
community
doing
this
type
of
effort
is
more
beneficial
to
the
community
as
a
whole.
B
A
A
B
C
A
D
A
Yes,
I'm
a
big
fan
of
documentation
that
lives
resides
close
to
the
code.
I've
been
not
a
fan
of
how
we've
bifurcated
documentation
inside
the
community,
because
if
a
person
is
working
on
an
area,
then
they
just
see
it
right
there
in
further
face,
may
be
a
simple
readme
guide
in
the
end-to-end
directory
or
readme
empty.
Let's
take
a
look
here
for
a
second.
A
If
we
wanted
to
outline
like
how
a
developer
could
you
know
get
started
modifying
it
like
welcome
to
the
intent
tests,
you
are
there
be
dragons,
you
know
in
an
outline
how
to
get
involved,
and
you
know
how
to
actually
verify
your
changes
are
running
and
working
properly.
D
A
C
Is
it
confusing
it
is?
It
is
helpful,
but
there's
so
much
crap
that
it's
it's
it's
really
good,
but
there's
still
there's
still,
there's
still
a
lot
so
a
so.
For
example,
he
gave
me
a
it
gives
a
good
overview
of
four
somehow
code
to
run
cube
tests
and
in
all
the
brown
that
having
having
is
iron
a
I,
don't
exactly
know
how
to
test
shows
the
partner
of
work.
You
know
and
I,
and
that's
and
that's
really
the
only
the
common
issue
that
I
found
I.
D
Also
have
a
problem
with
gink
go
and
focus,
it
doesn't
work
as
I
expected
me,
Felisa
see
if
I
want
to
test
a
single
file
instead
of
a
namespace
or
like
using
the
focus.
Then
there
is
this
flag
for
ginko
that
lets.
You
provide
a
path
to
what
tests
you
want
to
test,
but
it
doesn't
work
and
it
basically
runs
everything
again.
Also
the
focus
I
I
cannot
get
the
focus
more
correctly.
I
see
no
errors,
it
just
runs
the
whole
suite
again.
No.
D
D
A
A
Think
that
would
that
would
go
a
long
way
like
what
I
would
do.
First
is
outline
a
couple
of
user
stories
of
what
did
you
want
to
do
like
I
want
to
refactor
this
end-to-end
test
and
then
I
want
to
be
able
to
just
run
that
test
right.
That
I
just
reflected,
and
you
know,
outlining
that
user
story
for
that
developers
story
inside
of
here
will
be
in
like
an
action
item
for
us
to
do.
B
Just
one
Laura
seems
to
mention,
so
there
is
another
file
service
you
to
Togo
is
also
very
large
files
over
15
South
1500
lines,
I
think
because
I
was
a
break
it
up
into
small
small
files.
I
just
looked
into
it,
but
nothing
too
much
just
program
prepared
a
first
step
coming
up
ProQuest,
but
I
can
also
do
a
like
a
prepare,
a
doc
like
Andres
or
just
append
to
Andres
doc,
and
to
see
that
what
we
can
do
well.
B
A
A
A
Like
I'd
expect
things
like
update
service
or
update
service
or
fail
that
makes
total
sense
for
a
service
utility
file
yeah.
So
you
might
want
to
do
this
in
pieces
right
on,
like
just
do
the
shuffling
first
and
find
out
who's
depending
upon
this
stuff,
and
then
you
might
even
evaluate
some
of
these
functions
and
their
utilities
I.
A
A
A
B
A
A
D
A
Have
to
look
through
it
there's
the
conformance
treat,
is
growing
a
lot
this
cycle
and
last
and
there
haven't
been
a
lot
of
cereal
ads
that
I've
seen
as
I've
went
through
it,
but
there
have.
There
are
a
set
of
cereal
tests.
I,
don't
know
exactly
know
what
they
are
to
do
to
get
the
full
list.
You'd
have
to
do,
focus
is
performance
and
do
a
dry
run,
and
then
you
would
get
the
full
list
of
all
the
tests.
A
A
So
you
can
do
a
dry
run
like
whenever
you
want
to
do
an
evaluation
that
should
be
part
of
like
the
documentation,
if
you're
doing
a
developer.
If
you
want
to
verify
the
test
that
you
will
run
before
you
do
anything,
do
a
dry
run
first
and
verify
that
your
regex,
that
you
use
for
focus
and
skip
is
giving
you
what
you
want.
E
E
D
A
We'd
have
to
sit
figure
out
what
we
have
to
evaluate
the
test
and
see
what
it's
doing
and
verify
that
it
truly
needs
to
be
serial
I,
don't
think
I,
don't
think
most
of
those
tests.
It
might
be
long
right,
but
I,
don't
think
they
necessarily
need
to
be
serialized
right.
There's,
no
reason
why
a
lot
as
long
as
yours
capacity
there's
no
reason
why
you
shouldn't
be
able
to
run
the
demon
set
test
in
parallel
with
everything
else.
D
Yeah,
because
because
of
these
this
weird,
like
delaying
I
mean
the
comparison
in
the
time
is
like
five
times
slower
I
mean
that's
one
of
the
actions.
They're
action
is
to
basically
instruct
people
to
to
do
a
couple
of
passes
in.
Maybe
we
should
do
the
same
for
actually
John.
Oh
really
said
that,
so
no
boy
is
doing
that
as
part
of
the
instructions
yeah.
F
A
We
can
so
who's
affected
by
this,
the
most
who
are
the
poor,
the
major
stakeholders,
and
what
is
it
they
want
other
than
speed
like
because
a
lot
of
a
lot
of
the
conformance
tests
allow
the
intent
test.
Suites
are
basically
periodic
that
people
pay
no
attention
to,
except
for
when
things
fail.
So
like
so
long
as
they're
green,
they
don't
really
care
about
s
ellos,
who
are
the
primary
people
that
really
want
this
I
guess.
D
A
D
G
Hey
Tina,
I
would
say
the
developer,
who
set
up
their
conformance
test,
see
I
are
the
one
who
will
be
benefited
from
this,
because
my
experience,
we
is
a
conformist
past
valuing
is
the
debug
time.
Just
add
up
if
you,
if
you
cup
some
failure
and
you
have
to
figure
out
and
fix
and
retest
take
a
couple
hours
for
simple
fix.
G
D
B
A
A
A
D
I
wanted
to
focus
on
the
last
issue
by
Jeff,
but
that's
in
the
list,
so
I
already
started
doing.
What's.
Basically,
this
ticket
recommends
because
everywhere
we
have,
you
know
no
annotation
for
the
error
that
happens
so
basically,
after
have
accurate.
You
cannot
miss
some
text
of
what
is
the
reason
for
this
timeout
and
basically,
if
I
see
a
PR
I
saw
a
PR
yesterday,
didn't
have
annotations,
so
I
immediately
recommended
them.
So
I
just
wanted
to
say
that
we
should
do
this.
E
E
A
A
Are
there
other
people-
and
this
is
a
good
way
for
George,
for
you
to
get
engaged
to
other
people
that
want
to
do
this?
I
would
find
I
would
I
would
parse
backwards
and
talk
with
the
tests
infra
group,
because
they
have
a
good.
They
have
good
apparatus
to
determine
what
are
the
most
flaky
tests.
They
actually
have
like
a
counter,
it's
all
punched
in
a
big
query
and
they
have
charts
and
graphs
for
all
this,
so
you
can
actually
figure
out.
A
D
A
A
And
this
was
the
main
one,
so
the
the
last
two
umbrella
issues
are
kind
of
overlapping
with
each
other
I
think
we
have
plenty
of
work
to
do.
Are
there
any
other
questions?
Folks,
it's
it's
all
been
triage
in
larger
umbrella
issues
and
I
have
a
couple
of
action
items.
One
is
for
the
documentation
and
for
me
to
follow
up
on
the
status.
Oh.
D
This
is
this
is
currently
on
hold,
but
the
existing
logic
to
get
the
list
of
schedule
all
notes
uses
the
master
nor
draw
like
we
have
incubate
am
also
copses.
Has
it
yeah,
so
basically
Jordan
Jordan
spear
removes
like
this
logic
from
the
framework
completely
the
problem
there
is
that
now
the
there
is
no
good
logic
to
determine
if,
if
the
node
is
schedulable
or
not,
so,
basically
the
suite
waits
for
indefinitely
until
until
the
goroutines
basically
sing
about
that's
the
problem.
D
A
D
D
Basically,
we
have
to
change
it
in
a
way
that,
okay,
if
a
node,
does
not
have
the
schedulable
effect
for
the
taint,
we
can
basically
start
consider
this
node
to
be
something
that
we
can
schedule,
except
that
currently
the
logic
is
broken.
Well,
so
it's
a
wider
question
like
what?
What
is
the
initial
state
of
the
question
that
we
should
consider
as
a
starting
point
for
the
work
holds
that
the
suite
is
going
to
the
point
say:
I
have
a
master
node
and
a
couple
of
workers
my
master
has
attained.
D
A
Would
agree
or-
or
you
need
to
add
a
parameter
that
there's
another
wider
problem
with
taints
of
the
intent
Tesla
or
some
people
like,
because
the
intent
test
suite
there's
a
there's,
a
fundamental
problem
with
a
lot
of
the
core
developers
and
that
they
do
not
realize
that
this
test
suite
is
run
in
the
wild
with
the
many
incantations
that
currently
exist.
So
a
lot
of
people
will
defoliate
ain't
their
whole
cluster
and
we
need
to
have
a
toleration.
A
D
Jordans
solution
to
that
is
to
are
the
label
selector
and
it
works,
except
that
now
even
Superboy
has
to
apply
this
it's
basically,
this
PR
is
breaking
everything
and
I
think
that
the
labels
little
should
be
optional.
That's
fine,
but
the
default
should
be
like,
like
figuring
out
what
what
paints
to.
Basically,
if
there
is
a
taint
of
a
schedulable,
we
ignore
this
mode
and
I
think
they
should
be
at
the
food
logic
that
works
everywhere
and
the
layer.
The
neighbor
selectively
is
optional
solution
that
this
PR
provides.
A
A
A
A
D
There
is
another
pair
that
merged
from
Patrick
only
about
about
the
flags
that
basically
David
it's
David.
It's
reported
some
problems,
Patrick
only
fixed
the
problems
and
then
I
believe
just
in
Santa
Barbara
said,
like
correctly,
for
only
the
end-to-end
testing
framework
is
using
Viper
in
communities.
Yes,.
D
So
maybe
like
what
what
testing
for
did
they
say
that
cube
test
is
completely
unmaintainable
at
this
point
there.
So
so
we
should
create
cutest
or
maybe
we
should
do
the
same,
which,
basically,
if
you
want
to
use
doll
version,
okay,
but
mind
that
we
have
this
new
version.
That
is
better.
The
Flex
have
been
a
maintains,
and
things
like
that.
Well,.
A
A
It's
meant
to
do
that
on
purpose,
to
simplify
the
user,
because
the
number
sheer
number
of
flags
that
actually
exists
inside
of
the
intent
testing
framework
is
actually
phenomenal
in
my
opinion,
because
it
it
exposes
all
of
Ginkgo,
as
well
as
all
of
the
other
parameters
that
are
kind
of
riddled
throughout
the
test.
Without
us
having
like
a
centralized,
we
have
this
thing
called
a
test
context
which
is
geranyl
versus
like
a
broken
down
set
of
sub
structures,
very
akin
to
how
cou
medium
kind
of
has
its
its
config.
A
But
we
should
have
a
component
config
very
analogous
to
how
and
well
thought-out
right,
that's
composable,
very
analogous
to
how
we
address
things
in
committee
m.
That's
the
pattern
we
should
be
making
here.
If
people
depended
upon
those
things
from
the
intent
test,
suite
I
don't
think
we
have
any
guarantees,
because
it's
not
it's
it's
a
consumable,
artifact
but
I.
Don't
think
we
follow
the
same
policy
for
the
test
suite
or
ever
have.
D
That's
true:
I
spoke
with
stilt
ebooks
and
Michael
Dauphin
about
basically
what
what
are
the
plans
in
terms
of
the
working
group
component
standard
handling
the
flag
problem
in
communities?
So
so
basically
they
said
that
Michael
does
not
even
know
what
VIPRE
is
so
he
has
to
like
investigator.
Consider
he
also
immediately
brought
some
problems
with
like
kubernetes
implementing
their
own,
like
a
version
of
VIPRE,
or
something
like
that.
D
D
A
Well
that
you
know
Andrew
if
you're
going
to
that
separate
sake.
Arch
working
group
with
regards
to
code
structure
like
boosting
up
the
component
config
work
should
be
like
a
primary
function
of
that,
because
if
you
were,
if
you're
globally
across
every
single
component
inside
of
kubernetes,
if
you
were
to
actually
try
to
ascertain
what,
how
we
do
config
file
handling
and
how
we
do
feature
gates
in
the
uniform,
systematic
way,
you'd
probably
lose
your
mind.
A
B
B
A
One
of
the
things
I
want
to
try
to
do
and
what
one
of
the
things
I
have
a
tendency
to
do.
You'll
find
is
I
want
to
find
the
highest
priority
thing
that
eliminates
core
problems
in
the
dag
and
concentrate
fire
on
those
things
that
this
one
is
lower
priority
for
me
like
this
one
lower
priority,
then
we
can
see
it.
You
can't
see
it
serials
lower
priority,
but
component
config
is
up.
There
is
higher
priority.
Oh.
D
A
Function,
the
the
highest
priority
thing
is
to
refactor
the
intent
test
suite
to
be
able
to
bender
it
in
easily,
so
the
the
most
important
ones
are
decoupling
cloud
provider
and
the
framework
refactor.
So
the
the
work
that
we're
currently
doing
for
the
utils
function
to
get
them
out
is
a
portion
of
the
decoupling.
B
B
A
A
So
right
now,
in
order
for
you
to
extract
cloud
providers
right
to
get
them
all
the
way
out
of
on
a
tree,
we
need
to
be
able
to
have
the
framework
easily
importable
and
to
have
them
be
able
to
vendor
in
a
debt
graph
that
doesn't
like
subsume
the
universe
and
part
of
that
was
like
changing
the
client
set
to
use
the
external
client
set.
That
was
a
good
progress
for
us,
then
also
the
dependency
graph,
because
we,
the
utils,
are
smashed
into
framework.
A
You
import
in
all
the
dependencies
that
are
there,
even
though
you
you
may
only
need
a
portion
of
the
framework
right
so
slowly,
teasing
apart.
Those
utilities
is
a
generally
useful
thing
to
get
to
allow
provider
extraction,
but
also
to
allow
other
people
to
use
the
framework
in
a
more
substantive,
substantial
way.
So
that's
like
that
includes
Patrick's
work
right
for
storage,
feet,
people,
so
the
CSI
drivers
are
a
good
example
there.
A
F
F
A
D
D
Question
but
maybe
we
can
at
least
define
a
roughly
what
the
answer
to
this
is
because
it's
like
an
a
deep
question,
the
tie
out
one.
So
what
is
the
rule
of
thumb
in
terms
of
the
framework
like
what
we
should?
We
include
in
the
framework
and
import
in
the
framework
and
what
we
shouldn't
like
if
we
stay
that
staging
is
something
that
we
can
import.
That's
fine,
probably
but
probably
package
is
not
a
good
idea
or
like
to
tomato
sitting.
D
If
we
move
the
framework
to
a
new
repo
and
somebody
uses
core
modules
in
let's
say
the
imports
like
the
framework
in
his
project,
they
they
basically
should
not
pull
anything.
That
is
from
cases
that
are
your
slash,
and
here
is
my
question.
Mark
like
we
should
basically
define
what
is
not
a
good
import
path.
A
Think
we'll
get
there
I
think,
there's
so
much
low
hanging
fruit
before
we
get
to
the
point
of
staging
that
I
think
we
have
plenty
of
work
to
do.
I
do
see
what
you're
saying
that's
the
endgame
right
like
where
we're
going
to
have
this
thing
live
and
how
do
we
tip
set
up
the
import
boss
and
everything
else
to
make
sure
that
we're
not
doing
it
doesn't
violate
those
properties?
And
so
is
he
a
good
venn,
durable
library
but
I
think
there's
just
a
seen
amount
of
work
to
get
us
there.
First
I.
D
A
I
only
have
some
logistic
stuff
before
we
end
so
when
people
are
new
to
the
testing
framework
and
they're.
Making
modifications
and
folks
are
reviewing
make
sure
that
they
have
one
commit
per
type
of
change
that
they're
making.
So
sometimes
people
will
do
like
refactor
work
along
with
some
other
work
has
a
theme.
You
know
we
do
this
and
everything
else.
So
we
should
make
sure
that
we
adhere
to
that
same
pattern
as
well.
A
So,
let's
just
make
sure
that
when
we
review
stuff
that
we
leak
all
out
stuff
to
be,
is
atomic
commits
and
then
it'll
be
like
refactoring
work
for
blah
blah
to
make
it
a
little
cleaner
for
readability
or
whatever,
and
like
okay,
that
I
guess
that
makes
sense
right
all
right,
nothing
else.
There
are
a
lot
of
time
so
I'll
caught
here
thanks,
you
ready
things.