►
From YouTube: 20190405 sig 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
Hello
today
is
Friday
April
29,
the
sick
testing
testing
Commons
sub-project
meeting.
Why
don't
I
show
my
screen
and
we
can
walk
through
the
agenda?
It's
a
kind
of
a
light
agenda,
but
I
kind
of
wanted
to
walk
through
code
today.
So
to
give
folks
an
idea,
because
I
know
we
last
time
we
struggled
to
figure
out
where
to
tease
apart
things
and
I
have
a
plan
for
how
to
attack
this.
So
I've
spent
a
good
chunk
of
my
morning,
walking
through
some
of
the
code
and
want
to
use
an
example
laughter
all
right.
A
So
hopefully
it
looks
good
see
my
screen.
Let's,
let's
walk
through
the
first
one
here
live
Amir.
You
talked
about
splitting
out
a
package
from
cube,
ATM,
potentially
putting
in
a
different
location,
yeah.
B
Briefly
spoke
with
dim
sum
pen
about
this.
We
need
some
sort
of
a
new
but
quote-unquote
that
big
round
for
a
bunch
of
tools.
One
of
them
is
the
system
validators
that
we
have
incubate
in,
because
also
the
nodes
framework
I
believe.
Oh
no,
it
wasn't
a
lot
Remo.
Something
else
is
using
them
in
the
test
folder
in
KK
and.
C
B
F
Well,
the
kids,
io
/
Turtles
was
more
towards
people
who
we
don't
know
who
might
need
that
kind
of
thing,
those
kinds
of
things
this
seems
very
specific
to
testing
or
rivality.
You
know
validation
when
cube
Adium
comes
up,
so
I
thought
it
would
make
sense
to
me
anyway
need
a
grab-bag
for
other
testing
stuff
based
on
what
comes
out
from
here
right
from
this
room.
E
A
I
don't
know
about
some
of
these
validators.
There
already
is
a
separate
structure,
amita
testing
directory.
So
if
you
look
over
here
and
you
look
at
tests,
there
are
separate
utilities.
If
they
are
true.
This
isn't
just
testing,
though
it's
that's
the
part
that
kind
of
drives
me
a
little
bit.
Nutty
is
their
validation
utilities,
so
so
they
would
be
more.
Generic
and
they'd
live
on
a
host
they're,
not
just
for
testing
I.
B
Can
give
him
some
historical
context?
Context
of
these
validators,
so
I
believe
randomly
from
Google
created
at
first
and
they
resided
in
the
load
end-to-end
tests,
but
at
some
point
they
related
to
all
the
tests
that
they
that
they
were
that
were
using
these
validators.
So
we
moved
the
validator
to
cube
ATM
because
cube
areum
started
using
them
as
pre-fight
checks,
but
then
at
some
point
somebody
decided
to
vendor
cube
to
import
CMD,
/qp
diem
for
I,
believe
the
kernel
checks
or
the
talker
checks.
F
And
the
other
issue
I
have
with
this
packages
vendors
and
things
like
docker,
which
we
are
trying
to
get
it
off.
So
if
we
end
up
pulling
in
additional
inputs,
who
knows
what
it
will
drag
stuff?
For
example,
if
you
drag,
if
you,
if
you
have
a
validate
of
us,
that
uses
see
advisor
import
right
now,
I,
don't
think
there
is
one,
but
then
that
will
turn
around
and
call
a
whole
bunch
of
other
cloud
provider
stuff
right.
A
We
I
think
if
we
cleaned
it
up,
it
makes
sense
to
have
a
host
validation
or
node
validation
or
preflight
host
pre-flight
or
whatever
I
call
it.
It's
not
specific
to
test
in
putting
an
earth
package.
Util
makes
a
heck
of
a
lot
more
sense
than
putting
it
into
a
separate
six
testing
utility
repository
because
it's
used
by
both
Covidien
and
tests
right.
F
A
G
A
C
A
Have
that
I
don't
care,
because
if
we
have
v1
component
config,
we
can
move
comedian
totally
out
of
core
and
we
won't
have
to
mess
with
this
stuff
that
and
test
automation
and
apparatus
and
release
versioning
automation.
So
if
the
working
group
for
infra
exists
and
has
the
ability
to
publish
artifacts
in
a
seamless
fashion
for
us
to
be
able
to
publish
as
an
external
entity
and
if
component
config
is
v1,
then
I
will
absolutely
move
out
of
core
and
I
will
care.
Okay,.
A
A
A
I
would
think
that'd
be
a
terrible
idea
for
Covidien
I,
to
be
honest,
I
think
the
decoupling
and
repositories
and
the
current
incantation
and
I've
made
I
talked
to
Clayton
about
this
many
times.
I
think
it's
the
worst
of
all
worlds.
What
we
currently
created
with
the
stage
repository
Clayton,
loves
I,
think
is
an
abomination
unto
God
yeah.
B
A
So
I'm
gonna
kind
of
table
this
conversation
for
folks
to
I
think
that
path
is
cleared.
What
we
want
to
do
is
move
the
validators
under
details
and
minimize
if
we
have
specific
validators
that
are
that
are
not
used
across
hosts,
try
to
make
them
more
generic
and
try
to
push
them
into
the
utils
and
call
it
like
a
host
validation,
and/or,
no
validation
or
something
of
that
nature.
B
A
Alright,
so
the
long
and
the
short,
our
objective
is
to
minimize
the
depth
graph
of
framework
and
make
framework
be
in
portable
by
other
things.
Ideally,
it
would
become
another
aspect
of
staging
to
make
it
easier
for
other
people
to
import
right.
So
that
way
we
can
create
plugins.
We
can
create
different
conformant
suites
that
are
out
of
core
right.
That's
that's!
The
high
love
objective
of
what
we
want
to
accomplish.
A
The
external
deployment
client
is
is
well
factored
to
minimize
the
dependencies,
so
it
can
be
outside
the
internal
client
is
just
like
a
buckyball.
You
touch
one
thing:
you
touch
all
the
Trinities.
The
import
is
just
a
tree
of
everything
all
right.
So
then,
then
you
look
at
the
framework.
That's
one
thing
that
we
know
for
certain.
We
can
do
all
right.
That's
great!
Now,
that's
almost
done.
What
is
the
next
thing?
We
do.
How
do
we?
A
How
do
we
decouple
this
in
a
systematic
way
and
the
answer
that
I've
come
up
with
for
the
time
being,
is
to
do
it
one
by
one
in
the
very
painfull
auditing
process
right?
So
let's,
let's
do
a
specific
example
underneath
the
framework
directory
there
is
aa
ton
of
things
called
youto
right
and
it
doesn't
make
any
sense
right.
A
We
basically
bundled
all
of
these
things
underneath
one
large
utility
right
and
you
know
if
you
go
back
underneath
package
utils,
you
find
that
things
are
way
well
factored
into
individual
sub
things
for
the
specific
domain
that
it
matters
right.
So
the
there's
no
easy
answer
here.
The
answer
for
this
is:
don't
trust.
A
thing
you've
seen
inside
of
the
framework
as
de
facto.
So
if
you
look
at
something
like
authorizer
util,
this
is
where
I
started.
You
kind
of
have
to
start
to
tease
things
apart.
A
You
have
to
figure
out
where
the
dependencies
for
authorizer
detail
are
being
used
and
most
of
the
stuff
for
authorized
or
utilities
is
being
leased
by
the
auth
package
right,
it's
not
being
used
by
most
other
things.
Some
of
these
things
are
kind
of
general-purpose.
So
the
answer
is,
you
have
to
use
a
lot
of
discretion
and
you
have
to
do
a
lot
of
thinking
about
where
the
dependencies
exist,
but
you
also
have
to
question
the
heck
out
of
what
is
currently
there.
Some
of
some
of
this
kind
of
makes
sense.
A
A
Should
we
just
remove
stuff
like
this
and
on
the
entire
dependency
for
from
the
tree
and
basically
say
if,
if
you
don't
have
our
rec
enabled
you
just
fail,
because
we
don't
want
to
enable
the
test
apparatus
for
all
of
the
incantations
where
our
back
has
done,
enabled
now
that
that's
an
opinionated
thing
that
we
we
need
to
take
a
stance
on.
So
what,
if
folks
think
they're
for
something
like
this
well.
D
A
Can
I
mean
the
super
old-school
way
for
doing
stuff
like
this?
Is
you
basically
put
Apache
on
the
front
end
and
Apache?
Is
your
your
entire
inbound
authorization
tool?
But
if
that
becomes
a
little
weird,
because
the
the
granularity
of
access
control
it
gets
lost
and
you
have
to
basically
redo
our
back.
D
B
A
Yeah
that
should
be
dinner,
but
the
whole
purpose
of
doing
the
audit
and
walking
through
this
way
is
that
I
want
people
to
question
everything
they're
right
and
like.
If
you
look
out
here,
is
our
beckoned
evil?
What
are
the
actual
call
sites
for
this,
and
the
answer
is
it's
all
basically
off
related
utilities
right
is
our
BEC
enabled
is
arbitrable,
is
all
in
the
auth,
so
you'd
have
to
basically
trim
this
down,
eliminate
this
call
site,
eliminate
the
dependencies
of
the
call
site
and
push
some
of
these
utilities
into
a
framework
auth
directory.
A
That
is
one
way
for
us
to
sort
of
get
things
into
place.
So
look
at
the
you
tell
patty
jizz,
evaluate
whether
or
not
it
even
makes
sense
for
these
things
to
exist
inside
a
framework.
The
answer
unequivocally
in
my
mind,
for
most
of
them
is
no.
They
should
be
underneath
their
own
separate
directory
or
hierarchical
directory,
where,
if
we
had
util
and
then
we
had
off
just
a
lot
like
packaged
off.
I
A
And
then
we
could
actually
sit
down
here.
We
could
even
debate
whether
or
not
some
of
these
things
should
go.
Some
of
these
utilities
should
go
into
packaged
off,
but
you'd
have
to
refract
or
the
framework
out
of
this.
But
there's
no
reason
why
you
couldn't
have
a
generic
casting
in
a
client
set
and
say:
is
our
BEC
enabled
with
the
client
set
and
do
the
same
type
of
behavior
instead
of
these
being
logs?
That
can
be
here's.
A
F
A
But
the
the
utils
is
like
a
clean
place
to
start
right
now.
If
people
want
to
coordinate
the
idea
of
moving
the
utils
into
a
separate
location
and
then
ven
during
those
things
that
see
that
mirror
kind
of
the
same
directory
structures
package,
that
is
a
reasonable
first
step
to
do.
I
do
think
you're
kind
of
avoiding
the
the
core
crux
of
the
problem.
So.
A
There
is
not
a
package,
there
is
a
package
utilities
test,
but
some
of
this
stuff
I
would
still
stick
underneath
framework,
so
B
framework,
util
and
then
it'd
be
like
some
of
this
stuff.
A
question
like
is
our
Beck
and
evil.
If
you
modify
this
call,
there
is
no
reason
that
this
can't
be
generic
enough
to
be
in
package
detail
and
use
their.
The
only
reason
why
this
leave
annex
it
or
question
why
we
even
need
it
at
all.
Okay,.
F
F
A
Iii,
personally,
don't
think
you
need
this,
because
I
think,
if
our
back
is
not
enabled,
we
should
just
fail.
That's
my
opinion,
but
the
I
think
the
the
interim
thing
is.
The
evaluation
process
makes
sense
right,
create
a
framework
util,
and
then
you
could
break
it
out
to
be
like
a
mirror
of
some
of
these
things
like
off
framework
util
off
and
then
step.
One
would
be
to
push
this
stuff
in
there
and
update
the
call
sites
step.
Two
would
be
evaluation
of
what
you
need
to
do.
A
I
would
say,
like
you,
should
do
one
and
two
together
and
just
do
it
on
each
util
at
a
time
and
do
the
hard
work
upfront,
because
otherwise
you're
gonna
have
to
do
two
PRS,
and
then
you
can
start
doing
that
with
every
single
one
of
these
utils.
That
exists
underneath
side
underneath
the
main
directory,
and
as
you
start
to
do
this,
you
will
find
that
you
are
refactoring
along
the
way
and
it's
a
very
clean
way
for
us
to
get
one
step
further
in
this.
This
pipeline.
F
D
I
have
a
question:
is
there
like
one
clear
de
suite
Network
we
can
use
to
decide
like?
Are
we
making
forward
progress
like
import
the
framework
and
just
count
the
lines
of
code?
Is
that
kind
of
the
bar?
If
we're,
if
importing
the
framework
in
ports
less
and
less
stuff,
that's
anonymous
with
us
making
progress.
That's.
A
Does
what
I
did
what
I
said
makes
sense?
It's
a
hard
thing
to
do.
I'm,
not
asking
for
an
easy
thing:
I'm
asking
to
actually
do
the
hard
work
of
refactoring
and
start
with
the
utils
like
do
you
want
it?
Do
you
want
a
buddy
there
John
to
someone
to
walk
through
it
with
you,
then
we
can
actually
evaluate
what
happens.
What
you
found
I
mean.
F
D
D
A
I
think
the
the
you
tools
are
better
than
actually
trying
to
decoupled
portions
of
the
framework
as
far
as
refactoring
goes,
because
the
call
sites
will
be
pretty
synonymous
with
its
function
right,
like
a
pv
util.
Obviously,
that's
used
by
storage
right,
but
it
might
be
used
by
a
couple
of
other
call
sites.
So
where
can
you
put
it
in
a
place
that
makes
the
most
sense
and
when
you
actually
look
at
the
the
pv
util,
you
can
evaluate
and
do
the
harbor
vector
does.
Does
this
structure
of
these
utilities
mix?
A
No
TV
utility
has
been
a
lot
cleaning
it
a
lot
cleaner
than
the
other
ones.
Another
thing
I
would
do
along
the
way
when
you're
doing
this,
so
one
thing
we
might
want
to
do
is
like
start
to
create
criteria
on
what
we,
what
we
mean
by
refactoring,
for
example,
like
I,
would
consider
this
to
be
a
no-no
right.
A
Direct
frameworks,
style
logging
inside
of
here
I,
would
just
make
it
an
error
right
return,
actual
well,
well-defined
ears,
so
that
the
call
sites
have
to
then
use
the
log
in
the
logging
inside
of
the
test
themselves
versus
actually
logging.
You
know
in
this
utility
library
I
generally
try
to
avoid
that
in
any
utility.
I
B
B
A
All
right,
so
that's
my
current
strategy
of
thinking
are
there
other
folks
who
want
to
maybe
tackle
a
couple
of
the
other
ones
like
there's
deployment.
Utility
I
would
avoid
flake
reporting,
but
there's
other
things
too
inside
of
here
that
underneath
the
utilities
that
make
sense
to
just
break
out
into
their
own
location
are
there
other
folks
who
want
to
volunteer
for
this
work.
E
A
A
Let's
take
a
look
at
what
we
originally
wrote
and
see
where,
where
we
kind
of
made
progress
and
we're
given
given
findings
of
taking
a
look
at
things,
what
makes
the
most
sense
to
do
next,
so
the
biggest
one
here
was
the
the
primary
thing
we
started
with
the
internal
client.
I
know
that
you
did
a
lot
of
work
there
and
Lumiere
helped
out
to
ownership
problems
who
active,
maintains
the
tests
and
the
sake.
I
do
know
that
we
have
a
label
update
for
intend
testing
framework,
so
I
can
walk.
A
I
was
going
to
walk
through
the
pull
request
at
the
end
of
what
currently
exists
in
the
PRS
providers
needed
external
vendor,
I.
Think
part
of
what
we're
doing
here,
part
of
this
breaking
apart.
Maybe
we
should
have
a
separate
umbrella
issue,
which
is
the
breaking
apart
the
utilities
and
then
link
to
this
parent
issue.
Oh.
A
Firm
recuse
is
not
incremental
looking
that
this
is
no
way
to
change
this,
and
not
with
it
not
without
us
like
extracting
out
the
details.
So
I
think
we
have
a
good
start.
I
think
this
this
once
we
create
this
checklist,
that's
going
to
be
a
lot
of
work
items
to
decouple.
We
can
federated
up
and
there's
a
lot
of
utils
and
there's
there's
even
more
there,
which
I
kind
of
question
like
this
I.
A
A
I
A
A
A
B
A
Don't
know
if
this
is
a
fix
is
seven
five,
five,
nine
on
the
second:
let's
take
a
look
at
this
issue:
e
to
e
imaginary,
command
line
flags
with
flag
definitions
from
a
function
into
a
framework
to
register
colored
flags
into
an
it
section
of
the
cell
of
some
packages.
God,
that's
awful
that
just
bristles
neither
own
way,
that's
okay
for
the
career
days
into
a
test
suite
where
the
flags
traditionally
a
couple,
but
no
just.
I
B
A
Question
is
like
it's
one
of
those
things
where
we're
kind
of
pushing
stuff
around,
and
not
necessarily
solving
the
problem
like
I,
like
the
way
we
currently
handled
flags
in
the
internet.
Testing
framework
was
only
because
we
didn't
have
a
good
solution
and
because
component
config
never
existed
like
we
didn't,
have
versioned
ways
of
handling.
A
A
This
particular
one
I,
don't
even
know
if
I
want
to
I'll
evaluate
this
one.
Unless
somebody
else
wants
to
take
a
look
at
it,
it
is.
It
is
really
weird
it's
not
something
that
I
really
want
to
change
or
even
want
to
address
it's
a
it's
a
deficiency
that
I'd
rather
look
at
the
hard
way
in
the
correct
way
of
solving
a
problem.
B
B
I
A
B
Mean
that
the
goal
in
fixes
are
pretty
pretty
easy.
Basically,
they
are
mostly
adding
comments
on
top
of
the
functions,
so
we
face
the
the
lack
of
approval
from
time
to
time,
because
we
don't
have.
We
only
have
control
with
the
framework,
but
not
over
the
tests.
If
the
limiting
fixes
are
fixed
in
test
as
well.
A
B
A
A
A
I
A
Why
don't
you?
Why
don't
you
work
with
loop,
Amir
and
once
you're
done
with
your
review?
You
know
you
guys
can
chat
together,
but
I
specifically
want
to
train
up
more
folks
on
this
call
right.
So
that
way
they
can
always
be
reviewers,
though
the
way
you
get
street
cred
the
way
you
get
approval,
rekkles.
The
way
you
get
review
Eccles
is
by
making
the
pr
is
doing
all
the
hard
work
during
the
reviews,
and
then
you
know
volunteer
for
things
and
then
you
will
get
more
rights
and
privileges.
B
Let's
talk
about
the
aggregated
stuff,
if
you
want
so
first
of
all,
I
make
the
mistake
originally
that
the
the
aggregate,
the
aggregated
API
server,
has
a
couple
of
clients.
One
of
them
is
the
internal
one.
The
other
one
is
like
a
standards,
simple
client
and
apparently
the
framework
we
are
using.
The
quote:
unquote,
simple
one.
So
we
are
okay
with
not
removing
this,
but
what
I
did
as
I,
because
only
a
single
test
uses
it.
I
move
this
to
a
guy
machinery.
A
A
Before
each
well,
the
question
I
had
was
like:
why
are
we?
Why
are
we
reloading
versus
doing
like
a
modification?
What
is
special
about
the
aggregator
client?
That's
different
from
the
standard
set
of
client
sets,
because
there's
so
many
different
clients
sets
that
currently
exist
and
can
we
can
restructure
camera
reject
from
the
client,
or
do
you
actually
need
to
load
from
the
config
I?
Don't
I'd
have
to
take
a
look
to
know
the
difference
there
so.
B
We
in
the
framework
from
my
understanding,
we
don't
store
the
config
anywhere
after
it's
loaded,
so
we
place
so
we
basically
have
to
reward
it.
That's
the
reason
for
the
vault,
but
the
creation
of
the
the
client
said
itself
to
my
understanding.
We,
the
API
machinery
test,
is
testing
a
very
old
version
of
communities
like
something
like
1.10,
it's
specific
to
the
test,
and
maybe
I
should
talk
with
them
about
this,
but
that's
the
only
test
that
is
currently
consuming
this
special
client
and
I.
Don't
know
the
details
like.
Why
do
we
need
this?
D
A
This
was
this
was
weird
in
a
couple
different
ways:
the
config
loading
randomly
and
before
eh
I
would
avoid.
I
would
try
to
do.
There
are
a
separate
utilities
inside
of
API
machinery
and
the
client
tool
in
that.
Allow
you
to
get
different
clients
from
a
parent
client,
so
I.
What's
the
difference
between
an
aggregator
clients
and
the
initial
client
set
that
you
got
from
load
I.
C
D
D
A
B
A
Already
a
cold
so
leave
it
there.
Okay,
so
I
think
we
have
more
than
enough
items.
I
think
once
Andrew
creates
the
checklist
from
the
current
and
links
it
to
the
main
parent
for
the
utilities.
That's
a
lot
of
work
items
to
federer
down
on.
Are
there
folks
that
want
to
volunteer
for
this
work
besides
John,
who
wanted
to
work
on
the
first
one.
A
Anyone
else
Euler,
Bueller
Bueller,
all
right
all
right.
So,
let's
create
the
issue.
It's
start
to
break
down
some
of
the
work
items
if
you
want
to
volunteer
for
them,
otherwise,
I'll
vomit
old,
some
of
you
to
work
on
them
also
a
little
mirror
I
want
to
help
build
everybody
else
up.
So
we
got
six
seven
people
on
the
call.
So,
let's,
let's
try
to
get
folks
into
the
engaged
and
start
to
help
them
review
and
mentor
them
up
to
be
active
participants.
So,
let's
get
them
up
to
speed.
Yes,.
A
B
A
D
D
D
At
the
last
place,
I
worked
what
we
did
when
we
had
all
these
like
testing
things
was
you
you,
even
just
created
like
a
special
testing
image,
so
that
you
didn't
have
to
have
like
a
special
echo
image
and
a
special
this
image?
It's
just
you
had
one
image
and
you
said
like
this
runs
a
server
and
it
can
run
these
like
five
endpoints,
that
a
few
different
tests
will
use
and
at
least
centralized
and
they're,
like
I,
think
what
you
here's.
A
Why
I
use
it
yeah,
d2p
music,
is
a
good
effort
and
I
think
he
should
open
if
there's
not
an
issue
open
already,
which,
if
there
probably
is
somewhere,
feel
free
to
open
it,
and
if
you
want
to
work
on
it,
let
me
go
ahead.
Yes,
it
would
fall
underneath
this
umbrella
because
it's
basically
refactoring
the
framework.
A
The
problem
we
currently
have,
though,
is
that
the
only
way
to
push
a
new
image
is
to
get
a
Googler,
so
we
can
create
a
new
image
and
make
a
1-over
test
image
which
I
highly
endorse,
but
the
well.
We
will
be
blocked
until
we
can
like
corner
XT
or
some
other
person
who
has
image
push
rights
from
Google
knew.
D
About
that
that
I
mean
like
even
that
seems
sort
of
strange
to
me,
especially
now
that
there's
like
five
different
repos
or
registries,
where
we
pull
images
from,
is
there
not
a
way
that
we
can
have
a
a
registry
where
other
blessed
people
can
do
it
or
will
it
just
for
all
time,
be
only
Googlers
and
only
Google,
repos
or
registry?
Again.
A
This
has
been.
This
is
only
because
of
the
current
state,
where,
like
we've,
wanted
to
get
Google
out
of
the
driver's
seat
for
a
long
time,
and
they
want
to
be
out
of
the
driver
seat,
but
there's
a
bunch
of
ongoing
work.
What's
called
the
the
working
group
that
working
in
for
a
working
group,
which
is
basically
to
get
Google
auto
test
through
these
automation,
image
management,
all
the
other
stuff
that
is
related
to
this
okay.
D
A
A
Wildered.
So
just
a
recap.
On
items
before
we
split
Andrew
said
he
was
going
to
create
the
umbrella
issue,
which
is
going
to
have
a
whole
bunch
work
items
sync
with
John
and
George
Lou
Amir
is
not
gonna.
Try
to
do
less
of
the
things
and
help
train
up
some
of
the
other
folks,
and
we
will
follow
up
on
the
acronyms
next
week
and
I.
Think
that's
everything
and
if
their
last
questions
comments,
complaints,
concerns.