►
From YouTube: 20190503 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
A
A
All
right
so,
let's,
let's
add
the
details
here.
A
B
So
the
image
D
duping
I
think
the
same
update
I
gave
last
time.
I
hadn't
worked
on
in
the
past
week
was
I
still
think.
The
right
approach
for
that
is
that
it's
gonna
be
effectively
impossible
to
take
all
of
the
e2e
images
and
deegeu
them
in
any
meaningful
way,
because
there
are
such
large
and
specialized
image,
especially
around
the
vector
and
you
can
use
stuff.
So
I
think
the
right
approach
is
to
try
and
break
down
a
list,
at
least
so
that
in
that
centralized
location
you
can
say
like
look.
B
A
B
Those
ones
I
did
see
it.
There
was
a
comment
about
trying
to
just
bump
all
the
versions,
because
the
the
windows
group
was
trying
to
make
Windows
versions
of
a
bunch
of
packages,
and
so
I
think
that
they're
pretty
far
in
the
review,
but
one
of
the
most
recent
ones
was
even
for
the
things
they're
not
making
changes
to
accept,
adding
a
Windows
one
like
maybe
it's
just
smart
to
bump
all
the
versions
so
that
it's
it's
more
clear
and
simple
how
to
revert.
If
we
need
to
change.
A
A
D
A
A
A
So
yeah
this
is
not
making
you
feel
free
to
knock
it
out.
I
think,
that's
probably
still
the
main
objective
for
us
to
just
get
this
part
done.
That
will
make
it
import
restrictions
even
smaller.
Once
we
have
the
import
restrictions
file,
then
then
we
can
actually
get
things
a
little
bit
clearer
and
then
we
could
take
the
second
passed
evaluation
of
harder
problems
to
solve
this.
This
problem
is
pretty
super
here
or
really
easy
to
understand.
It's
just
dependency
problems,
yeah.
C
A
A
C
A
A
B
Want
to
talk
about
the
import
restrictions
file
because
I
got
assigned
to
me
so
I
mean
an
example
was
given
in
that
ticket
and
that's
for
a
cube,
ATM
and
it
says
effectively
like
don't
import
the
internal
client
and
don't
import
provider
specific
implementation
details.
So
what
are
the
things
that
we're
trying
to
prevent
framework
from
importing?
Do
you
want
me
to
just
copy
those
like?
We
don't
use
the
internal
client
or
provider
specific
things,
or
it
doesn't
really
matter
what
I
put
there?
The
point
is
it.
B
A
A
A
A
B
A
The
biggest
problem
is
imports
right,
like
because
the
API
is
aren't
fully
fleshed
out.
There's
this
weird
dependency
graph
problem
where
like,
if
you
promote
one
thing
across
the
chain,
it
will
ripple
through
all
of
the
code,
because,
instead
of
having
like
an
extractive
model,
where
you
sort
of
have
a
model-view-controller
style
thing
where
you
have
a
layer
of
indirection
like
at
an
SDK,
is
a
good
example.
This
you
have
an
SDK
that
abstracted
the
actual
client
library,
which
is
the
most
level
thing
your
client
library
has
actual
Church,
which
it
does.
Then
you
would.
A
B
To
bring
us
back
just
real
quick
to
the
import
restrictions
file,
one
of
the
things
lumineer
had
requested
or
commented
would
be
helpful
is
a
visualization
of
the
dependency
graph,
so
I'm
gonna
try
and
work
on
that
again.
The
vanity
URLs
are
posing
a
problem
with
at
least
the
first
two
or
three
tools
that
I've
tried:
I,
just
can't
figure
it
out,
and
then
some
of
the
tools
just
haven't
been
updated
to
work
with
the
modules,
though
I
don't
know,
I'll
see
if
I
can
fix
that
and
maybe
bring
up
a
picture
to
show.
C
But
generally,
a
good
starting
point
is
to
just
do
like
go
list
in
the
framework
package
and
look
at
all
the
imports
to
back
to
KK
and
then
just
put
put
only
those
set
of
imports
as
the
allowed
set
and
everything
else
is
not
allowed,
except
for
external
imports
and
that's
usually
a
good
place,
and
then
we
can
just
start
trimming
off
each
import
one
at
a
time.
Okay,.
A
Yes,
so
as
long
as
we
have
the
approver
stretch,
this
file
that
gives
us
starting
to
point
to
to
start
to
cleave
off
stuff,
so
I
think
I.
Think.
Once
we
have
the
concrete
file
in
place,
we
can
start
to
take
a
look
at
it
inspect
and
then
start
to
you
know,
move
shuttle
shuttle
code
around.
We
got
plenty
of
work
to
do
and
because
this
is
kind
of
like
a
side
task
for
most
folks,
you
know
that
progress
is
still
kind
of
like
incremental
and
slow
and
that's
fine.
A
Are
there
any
questions
about
the
main
objectives
here?
Still
I
think
those
are
still
the
p0
items
of
what
we're
trying
to
accomplish
if
we
can
actually
get
like
a
chunk
of
this
chunk
done
for
115
I
think
that
would
actually
be
SuperDuper
progress,
because
you
know
it's
kind
of
lived
in
perpetuity
in
its
current
state
for
a
long
time,
I.
E
C
So
there's
there's
been
a
lot
of
folks
who
have
volunteered
for
the
work
but
then
has
not
picked
up
any
work,
so
I
need
to
groom
all
the
issues
and
remove
names
that
haven't
actually
been
acted.
So
I'll
do
that
right
now
after
the
meeting
and
then
you
can,
you
can
take
a
look
at
the
issues
and
assign
yourself
again
so.
A
So
TLDR
on
these
issues
is
if,
if
somebody
paying
the
person,
if
they
haven't,
actually
worked
on
it,
just
take
it.
That's
that's
the
common
modus
operandi
across
the
project
is
that
just
because
a
person's
assigned
doesn't
mean
that
they're
actually
actively
working
on
it
and
go
ahead
and
take
it
and
we'll
just
mark
or
update
the
actual
issue
itself
and
there's
there's
a
lot
of
actually
work
items
that
are
there
like
you
can
see.
A
C
So
one
other
question
I
had
was:
do
we
need
a
cut
for
this
work,
so
I
know
maybe
for
like
right
now,
like
just
breaking
up
utils
and
stuff,
maybe
not,
but
I
feel
like
whenever
we
get
to
the
point
where
we
can
actually
stage
the
framework.
We
need
a
cap
to
point
to
and
say
this
is
why
we're
doing
this.
A
Code
refactor
work
is
typically
not
kept
worthy
kept.
Weirdly
is
meant
to
I,
think
maybe
near
the
ends,
or
maybe,
when
we're
actually
getting
to
the
point
where
we
want
to
be
able
to
vendor
it.
We
can.
We
can
write
up
a
cap,
but
it's
only
ferment
to
be
as
a
consumption
is
that
we
are
creating
this
framework
to
be
venerable
right.
A
That's
promise
the
primary
goal
and
objective,
but
because
it's
not
like
a
high-level
feature,
especially
not
in
skirt
one
right
now,
it's
just
a
ton
of
refactoring
that
it's
says
when
you
rise
to
that
level.
It's
not
it's
not
and
use
your
consumable
doesn't
cut
across
the
project,
so
it
doesn't
meet
the
criteria.
A
A
C
A
So
here's
a
question
for
everybody:
well,
we
have
a
video
in
the
horn.
How
do
we
want
to
name
these
things
for
imports
right?
Because
that's
been
like
the
common
thing
that
we've
seen
over
and
over
again.
A
C
B
Now,
they're
going
to
be
a
requirement
in
all
cases,
just
like,
because
sometimes
there's
just
not
a
conflict
right
log
was
like
a
really
comedy.
It's
obviously
you
you
have
to
kind
of
change.
That
name.
I
have
one
open
right
now:
that's
SSH,
which
there
is
a
standard
library
SSH,
but
it's
just
not
commonly
used,
so
it
it
conflicted
in,
like
one
file,
I
think.
A
If
it's
very
germane
to
the
intended
testing
framework,
you
should
prefix
it
because
it
makes
a
lot
more
sense
when
you're
reading
the
code,
nothing
is
more
unintuitive
than
when
you
have
like
me
over
the
import
sort
of
naming
problems
or
like
collisions
around
what
behavior
belongs
to
one
thing,
especially,
we
can
go
from
file
a
to
file
B.
It
just
makes
your
brain
segfault
right,
like
if
you're,
if
you're
reviewing
a
ton
of
these
having
similar
patterns,
just
making
it
easier
right.
A
B
That's
mine
and
so
that
one
it's
pretty
straightforward.
There
was
one
one
or
two
changes
because
the
fact
there
was
one
function
that
used
the
S
context
so
I
had
to
change
in
signature.
All
it
really
needed
was
the
provider
name
and
so
I
just
had
that
function
take
another
parameter,
but
now
it's
sort
of
funny,
because
the
function
is
note
exact,
which
is
almost
identical
to
the
SSH
function.
Except
the
order
of
the
parameters
is
slightly
different
and
you,
like
you,
don't
have
to
join
it
to
the
SSH
port.
B
B
A
Yeah
I
think
it'd
just
be
easier
because
when
you
run
you're
referencing,
if
it's
a
framework
library
and
just
looking
at
the
code,
it's
actually
not
intuitive.
You
didn't
look
double
check
your
course.
You
know
for
every
single
file,
I
think
having
that
pattern
will
make
it
a
lot
easier
to
actually
read
the
framework
code.
Okay,.
B
E
C
What
so,
while
John
mentioned
test
contacts,
can
we
actually
talk
about
if
we
feel
the
need
to
remove
to
move
text
context
variable
into
a
separate
package,
because
what
I'm
finding
is
that
we
dump
a
lot
of
important
information
in
text
context.
So,
like
a
lot
of
times,
a
package
would
just
import
framework
just
because
it
needs
to
access
text
context.
So
if
we
moved
it
would
that
be
beneficial
or
if.
B
I
get
it
I
tried
to
do
that
and
it
was
pretty
much
impossible
in
the
current
state.
So
in
my
opinion,
like
that
seems
like
a
good
goal,
but
I
think
that
we've
got
to
finish
a
lot
of
the
other
stuff
first
and
then
maybe
even
consider
not
just
moving
test
context
to
another
place,
but
actually
breaking
apart,
the
god
object
object
that
is
test
compound.
So
there
are
some
really
specific
pieces
like
that:
are
just
provider
specific.
A
A
It's
9,
like
literally
on
the
order
of
months,
getting
our
config,
our
component
config
for
Covidien
to
be
where
it's
at,
and
it
has
warts
it's
not
perfect,
but
it's
a
composable
configuration
that
we're
only
dependencies
where
certain
things
are
isolated
to
their
their
domain,
based
upon
the
code
just
took
a
lot
of
time
to
get
their
order
of
months
to
get
this.
The
state
where
it's
at,
but
in
the
ideal
world
this
is
where
I
want
tests.
A
Contexts
to
go
is
to
be
a
well-defined
component
config
that
is
serializable
virginal
importable,
almost
like
an
API.
That
way.
If
a
person
wants
to
reuse
a
subsection
of
the
test
context,
they
can
still
do
that.
The
the
input
file
which
you'll
see
typically
here
is
they
have
the
separator,
so
the
various
separate
components
that
they
could
use
as
part
of
this,
and
that
means
that
they
can
take
the
pieces
that
they
need.
So
it
is.
A
It
is
a
well
structured,
well
versioned,
file
format
for
for
importing
for
the
for
chameleon,
in
this
case
right,
but
again
order
of
months.
So
I
this
is
the
where
I
want
to
get
to
you.
I
do
not
think
we're
going
to
be
able
to
accomplish
this
in
any
meaningful
timeframe
in
115,
but
I
do
think
it's
worthy
to
talk
about
like
we
could
restructure
the
objects
themselves,
and
that
alone
would
get
us
a
good
way
there
without
us
having
to
do
all
the
API
machinery.
A
If
you
just
made
the
objects
in
your
composable
structure,
but
you'd
have
to
tease
it
apart,
then
you'd
have
to
update
all
the
call
sites.
I
think
what
you
should
probably
do
for
something
like
this.
This
would
be
like
at
least
internal
proposal
level
thing
right
where
we'd
have
to
write
it
down,
talk
about
the
implications
of
what
it
means
and
then
figure
out.
This
is
what
we're
going
to
do,
because
it
will,
it
would
ripple,
through
all
of
the
tests
right.
C
B
C
Yeah
yeah
it'll
it'll
actually
be
like
a
full
blocker,
because
if
we're
importing
a
package
that
imports
stream
work
back,
there's
a
good
chance
that
somewhere
there
there's
an
important
cycle,
that'll
block
work
so
like
would
it
make
sense
to
just
do
a
lifted
shift
into
a
separate
package?
I,
don't
know
how
that
it
doesn't
sound
easy,
but
is
that
work
worthwhile
just
to
unblock
some
of
the
other
work
or
we
want
to
just
go
with
it
and
see
like?
Maybe
there
may
be.
A
What
this
specific
example
that
that
John
mentioned
earlier
I
think
decoupling
these
utilities
from
the
need
of
the
actual
framework
itself
or
the
parameters
I,
think
that's
a
useful
thing
to
do.
It's
a
worthwhile
effort,
because
you
know
these
utilities
should
not
import
back
in,
but
now
that
they're,
not
a
generic
utility
them
right.
I
think
that
decoupling
work
alone
is
worthwhile
and
that'll
also
give
us
context
for
how
we
want
to
shape
this
thing.
A
The
problem
with
changing
the
test
context,
is
it
ripples
through
everything,
so
you'd
have
to,
like
you'd,
have
to
figure
out
a
way
to
decouple
the
pieces
of
the
test
context.
So
I
think
this
work
is
still
beneficial
and
useful
to
do,
and
then
you
actually
have
an
important
SSH
framework
thing:
that's
external!
If
you
need
to
use
that.
C
A
Continue
down
this
road
for
this
cycle,
teasing
apart
the
dependencies
and
making
sure
that
they
do
import
cycle
through
back
into
framework,
because
that
that
makes
it
a
generic
utility.
Otherwise
it's
not
really
a
generic
utility,
it's
a
lump
of
goo
right
and
as
we
do
that
we
can
make
comments,
and
maybe,
in
the
test
context
about
where
the
parameters
and
structure
organizational
work
should
be
I.
Think
it's
going
to
take
awhile
to
get
us
to
the
point
where
we
have
a
well
factored
non
import
cycle
based
configuration.
C
A
A
Just
from
what
it's
worth
for
us,
at
least
that
there's
some
of
these
people
that
are
doing
this
or
geniusly
secretly
like
these-
are
the
Japanese
folks
they're
trying
to
help
out
it's
not
a
bad
idea
to
help
with
golden
it's,
not
a
prerogative,
though,
because
goal
it
does.
It
has
a
bunch
of
false
positives
and
we
have
a
bunch
of
other
utilities
are
in
place
for
checking
I've,
never
been
a
true
fan
of
going
like
some
things
are
useful,
like
in
particular
the
the
commenting
for
public
functions.
A
I
think
that's
the
useful
things
so
people
actually
depend
upon
pieces,
especially
as
spirit
gets.
Teaser
parts,
that's
a
useful
thing,
but
the
the
like
this
import,
one
that
on
imports,
it's
not
a
useful
thing:
III,
don't
I,
don't
see
this
as
being
like.
There's
no
tangible
benefit
to
this
particular
change.
So.
C
There's
an
so
there's
an
umbrella
issue
for
building
work,
but
I
think
what's
happening.
Is
that?
Because
we
have
the
auto
label
set
up
on
the
owners
file,
any
Dolan
changes
that
touch
the
framework
is
just
being
labeled.
So
should
we
just
go
ahead
and
like
unable
the
goal
net
ones
so
that
we're
not
it's
not
on
my
radar,
because
I
don't
like
opening
these
PRS
with
testing
Commons,
like
with
that
context
of
testing
Commons
they're
just
doing
like
generic
go
and
fixes
across
the
codebase,
and
that
happens
to
be
labeled.
A
A
B
I'll
just
mention
that
one
I
saw
you
haven't,
noticed
the
Hat
go
imports
or
update.
Go
imports,
that's
just
kind
of
a
work
in
progress,
I'll
cycle
back
to
it
at
some
point,
probably
break
it
up.
The
point
was
I
added
a
little
helper
script
to
just
one:
go
imports
everywhere,
but
I
think
I
was
hitting
some
odd
bugs
because
it
still
fails.
B
B
B
B
Also,
just
to
clarify
the
expectation
I
get
I
was
putting
in
there
sort
of
I
was
gonna
use.
It
myself
was
also
sharing
it,
because
I
thought
other
people
might
want
to
use
it,
but
I
wasn't
expecting
it
to
be
like
run
as
a
check
or
like
always
has
to
pass
this
or
anything
like
that.
So
I
guess
I'm
a
little
confused
why
it
would
need
particular
buy-in
from
a
bunch
of
Googlers,
because.
A
A
A
Sorry
yeah
it's
because
it
won't
or
files
references
right,
you're,
touching
you're,
touching
literally
everything
and
because
you're
touching
literally
everything,
here's
the
problem
with
the
Trinity's.
You
are
touching
code
that
exists
across
the
entire
code
base
and
because
of
that,
I
only
have
certain
rights,
because
I
willfully
cut
myself
out
of
pieces
of
the
code,
because
I
didn't
want
to
be
a
reviewer
for
that
code.
So
now,
because
you
touch
all
of
this,
you
need
to
you
need
a
level
curve
to
get
this
through.
I
see.
B
Yeah
I
might
like
I,
said,
just
break
this
up
because
I
somebody
else
was
complaining
about
that
v1
import
that
keeps
being
put
into
everyone's.
We
are
separately
yeah.
D
B
B
A
B
A
I,
don't
know
if
there's
anything
else,
that's
while
talking
about
I'm
gonna,
probably
punt
on
this
particular
one
I'm,
not
a
big
fan
of
how
we
do
command-line
interfaces
or
the
intent
and
testing
framework
and
I
really
want
to
use
component
config
and
get
that
in
place.
I
know
for
long-term
benefit
of
things
that
affect
both
cluster
lifecycle
and
testing.
Commons
Caponi
config
is
a
strategic
effort
that
I
think
will
has
high
impact
value
and
it's.
A
But
it's
a
hard
piece
of
work
and
I
think
that
that
is
a
good
piece
of
effort
and
that
would
affect
the
test
context
right.
So
having
a
systematic,
unified
way
of
being
able
to
create
a
configuration
file,
make
sure
that
you
have
plumbing
through
for
command
line
over
eyes
for
some
things
very
useful,
but
the
there's
like
two
contributors
working
on
it
and
one
of
those
key
contributors
is
like
a
part-time
in
it.
So
the
it's
a
problem,
progress
in
super-slow.