►
From YouTube: Kubernetes SIG Testing 2018-02-06
A
Hi
everybody
today
is
Tuesday
February
6th,
welcome
to
the
weekly
kubernetes
state
testing
meeting
I
am
your
moderator,
Erin
curtain
burger
and
this
is
being
publicly
recorded
and
will
be
posted
to
YouTube
to
exist
forever
and
ever
until
infinity
and
beyond
on
the
agenda.
Today
we
have
a
discussion
item
about
what
to
do
about
docker
and
docker,
so
I'm
gonna
hand
it
over
to
Tim
Sinclair
talk
about
that.
So.
B
I
want
to
preface
this
conversation
with
a
bit
of
history
and
understand
where
the
touch
points
are
there.
There
have
been
a
plethora
of
solutions
to
stand
up
doctor
and
doctor
clusters,
possibly
the
most
notable
one
has
been
brantas.
That's
the
been
the
most
widely
adopted.
One
and
we've
wanted
to
use
this
solution,
cluster
lifecycle
to
automate
some
testing
of
Covidien
for
some
time
and
in
fact,
we've
even
wanted
to
get
rid
of
a
lot
of
the
ad
hoc
developer.
Tooling,
that
exists.
B
We
just
haven't
had
people
to
see
it
through
in
the
sig
right,
it's
one
of
those
things
where
it's
been
on
the
Sega
Genesis
for
a
really
long
time,
and
we
want
people
to
execute
on
it.
But
we
haven't
gotten
consensus
to
get
a
group
of
people
to
want
to
do
it
because
there's
been
other
things
that
have
been
long-standing,
that
that's
the
sig
cluster
life
cycle
piece.
B
B
We
were
talking
about
a
common
set
of
tooling
and
a
little
abstraction
layer
that
we
wanted
to
write
a
spec
for
that
basically
allowed
folks
to
say,
give
me
a
cluster
and
that
cluster
you
could
almost
think
of
it
kind
of
like
the
cluster
API
word.
You
could
specify
some
configuration
of
nodes
and
it
would
basically
spin
up
a
cluster
for
you,
but
the
integration
piece
would
be
specifically.
B
B
Think
the
question
in
an
issue
that
a
row
is
is
where
should
this
live,
because
it
kind
of
falls
into
many
buckets
and
who
is
going
to
own
and
maintain
this
over
time
so
that
it
actually
solves
the
state
space
of
problems
so
that
we
can
kind
of
get
rid
of
the
tent
there's
about
at
least
four
or
five
different
d-ind
solutions
that
exist
right
now,
so
that's
kind
of
framing
the
whole
state
space.
In
the
background
of
why?
Why
we're?
Having
part
of
this
conversation
here.
B
Right
now,
the
integration
tests
that
exists
today,
there's
no
unified
and
Gration
test
that
for
people
across
repositories,
right
people
can't
really
reuse
the
current
integration
test.
If
once
we
do,
the
repo
forking
that's
impossible
because
they
would
have
to
vendor
in
kubernetes
right,
so
d-ind
gives
them
a
way
to
stand
up.
Well,
versioned
artifacts
in
an
actual
cluster
configuration
all
I,
really
want
back
from
an
API
perspective,
is
passing
a
configuration
that
says
my
cluster.
B
A
C
Think
to
me
the
difference
like
integration,
we
use
integration
and
end
pretty
loosely
because
the
style
of
test
you
see
in
and
today
isn't
necessarily
requiring
like
a
full
cluster.
For
me,
I
kind
of
had
the
distinction
and
end
test
is
given
configuration
to
test
it's
given.
You
know
the
cluster
client
or
whatever
integration
tests.
They
have
some
control
over
what
they're
going
to
test.
They
could
spin
up.
You
know
darker
darker
cluster.
They
could
spin
up
an
API
server
and
run
some
controllers
against
it.
C
They
have
a
lot
more
control,
but
it's
really
don't
know
whether
it
really
matters.
If
you
can
give
a
test,
client
or,
however
many
clients
you
need
for
whatever.
What
does
it
matter?
What's
on
the
back
end
could
be
an
API
server
back
by
hollow
nodes
could
be
a
server
back
by
marker
darknes.
It
could
be
a
real
clustered
particle.
D
So
I
go
ahead,
it
does.
It
does
depend
a
little
bit
because
every
solution
has
a
test
surface
they
can
handle.
For
instance,
dr.
darker
will
not
be
able
to
test
cloud
providers.
Darkened
doctor
will
probably
have
trouble
testing
anything
that
needs
kernel
modules
like
NFS
or
some
networking
solutions,
whereas
a
VM
integration
environment
would
be
able
to
test
basically
but
opensource
kubernetes
with
no
cloud
providers
and
no
storage
providers
like
vSphere,
so
the
testing
environment
you're
in
dictates,
which
of
our
tests,
you
can
run
fair.
C
D
B
But
I'd
still
want
to
keep
them
as
separate
into
any
conformance
test,
because
the
tests
themselves
are
an
artifact
that
you
can
produce
and
run
against
any
client
stuff
right.
I
wouldn't
want
to
drag
them
into
integration
tests
as
the
integration
tests
live
today,
because
that's
kind
of
a
lump
right,
you
can't
take
that
out.
You
couldn't
build
a
separate
artifact
would
be
a
monstrosity
right
sure,
but
so
with
our
with
our
current
testing
binary
that
we
build.
D
A
Okay,
I
think
that's
efficiently
answered
my
question,
so
I
want
to
go
back
to
Tim's
question
about
like
where
does
it
make
the
most
sense
for
this
to
live
and
who
makes
the
most
sense
to
own
it?
I
have
no
dog
in
this
fight.
I
saw
a
spirited
discussion
and
slack
to
the
point
where
we
couldn't
seemingly
resolve
this.
In
fact,
chat.
So
I
want
to
understand.
How
can
we
make
the
most
use
of
our
high
bandwidth
time
here
to
resolve
this.
D
Okay,
I'll
start
Michael
right
now
is
not
to
make
a
generic
doctrine.
Docker
solution,
I
think
that
would
be
nifty
and
I
certainly
considered
it
as
a
future
direction.
Right
like
it's
not
like
off
the
table
for
something
you
could
default
into,
but
it's
not
my
objective.
My
objective
is
continuous
integration
and
being
able
to
do
something
on
the
dev
desktop
that
is
effectively
the
same
as
continuous
integration
or
as
close
as
I
can
be.
D
You
know,
with
Colonel
differences,
so
a
very
limited
scope
and
also
very
specific
requirements,
for
instance
spinning
up
hundreds
or
thousands
of
beats
because
of
the
CI
environment,
and
we
would
we
would
like
this
sooner
than
later
right.
We
we
want
to
just
simply
go
get
something
working
for
our
use
case
and
if,
if
it
so
happens
in
the
future
that
a
generic
doctrine
docker
platform
works
for
us,
we
would
absolutely
use
that
for
better
maintainability,
but
it
does
not
exist
today.
E
One
thing
I'll
say
just
as
a
well
outside
collaborator
on
a
few
external
projects.
This
is
something
that
would
definitely
be
useful
externally
if
there
were
some
kind
of
generic
way
to
do.
This,
I've
been
trying
to
keep
track
of
the
dock
and
our
efforts
every
and
keep
that
his
project.
Right
now
we
have
to
use
mini
cube
in
the
mismatch
mismatch
of
a
VM
dragon,
so.
B
That's
kind
of
the
point
is
that
I
I
don't
want
to
have
a
certain
myopathy,
because
that
will
limit
that
would
potentially
limit
the
larger
scope
at
hand
when
I
kind
of
wanted
to
do
was
rally
in
a
proposal.
I
think
we
would
probably
bring
a
lot
of
ducks
to
the
fight
here
to
help
make
this
go.
If
we
had
a
proposal
in
place.
That
says
we
want
to
do
this,
and
these
are
the
reasons
why?
B
Because
I
think
there
are
many
interested
parties
that
all
want
this
piece
of
the
puzzle
and
for
me
I
would
absolutely
love
to
get
rid
of
the
Devon
test
environment
that
people
use
for
local
cluster
up
I.
Think
that's
a
monstrosity,
and
if
we
use
the
artifacts
that
we
produce
as
part
of
that
set
up
for
local
cluster
up
and
just
it
shims
around
and
creates
a
d-ind
cluster.
That's
even
better,
because
we're
testing
the
full
suite
Devon
developers
are
naturally
part
of
the
lifecycle
of
this
test
infrastructure
that
we're
creating.
So.
D
The
first
thing,
I'll
say,
is
I
think
iterative
solutions
are
normally
pretty
good,
I
think
if
we
do
this,
and
then
network
providers
want
to
use
it
to
test
their
CNI
implementation,
that's
not
actually
very
difficult
to
do.
It's
not
the
only
reason
it's
not
feasible
and
what
I've
done
is
because
I
haven't
put
the
time
into
it.
D
Yet
because
it's
not
my
particular
objective
I
have
a
pretty
good
idea
about
how
I
would
go
about
doing
it,
but
it
just
it
it's
not
what
I
put
my
time
into,
because
it's
not
what
I'm
trying
to
achieve.
However,
if
you
were
good
to
go
talk
to
the
weave
guys
and
say:
okay,
well,
why
don't
you
go
make
sure
that
that
works?
I,
think
that
that
is
is
optimal,
but
I.
D
B
What
is
the
specific
goal
that
you
have
in
mind
because
the
problem
with
you
creating
one
is
now.
This
is
the
sixth
incantation
of
a
system
which
would
eventually
my
goal
is
to
kind
of
reduce
this
reduce
the
problem,
space
right
and
and
if
it's
kind
of
like,
if
you
want
to
go
fast,
go
alone.
But
this
is
a
community
project,
so.
D
B
Guess
I
think,
but
the
the
way
the
community
operates.
Here's
here's
the
conundrum
right.
This
clearly
affects
a
lot
of
people
right
that
that,
by
definition
you
know
it
would
affect
us,
because
we
want
to
be
able
to
create
this
piece.
But
there
is
now
a
fourth
component
that
we
would
have
to
Redux
or
a
fifth
or
sixth
component
we'd
have
to
redux
into
this
like
well,
all
I'm
trying
to
do
is
we
can
rally
on
a
spec.
B
D
D
C
Think
my
my
concern
with
this
is,
if
you're
just
using
this
in
CI-
and
that
was
its
only
purpose-
have
at
it
right
but
where
I
get
concerned
is
talking
about.
Yes,
you're
gonna
get
developers
starting
to
use
this
well,
there's
already
tools
in
the
developer
space
and
by
putting
this
front
and
center
in
KK.
D
Like
a
lot
of
Myr
antis
is
so
the,
and
this
is
just
a
test
kubernetes,
that's
the
that's!
The
objective
Miranda
has
a
lot
of
other
goals
right
it
wants
to.
If
I
recall
correctly,
it
wants
to
be
able
to
test
kubernetes
on
multiple
base
images
to
simulate
multiple
operating
systems.
We
don't
care
about
that
because
we
have
the
node
ete
tests.
D
C
We
want,
why
is
what
I
mean
I
kind
of
get
the
darker
and
darker
and
darker
piece.
That's
not
really.
What
Miranda's
does
the
one
I
think
about
like
if
I'm
a
developer
and
I'm
one
of
running
something
I,
don't
really
need
darker
and
darker,
and
darker
and
I
just
need
to
be
able
to
run
the
cluster
on
a
single
docker
host?
My
concern
is
kind
of
seems
like
in
a
lot
of
ways.
C
D
So
there
are
a
few
major
TechNet
areas
and
more
antis,
and
if
you
go
back
and
you
look
at
the
github
issues,
talking
about
mainlining
Marant
Azure,
even
bringing
it
into
an
incubator,
the
discussions
are
largely
like.
This
is
a
great
idea
in
concept,
but
we
don't
want
Marant
is
in
particular
because
of
its
various
forms
of
tech
debt,
for
instance,
several
thousand
lines
of
bash
code.
D
Another
thing
it
does
that
I
do
not
believe
we
should
do.
Is
it
uses
the
build
system
as
an
API,
which
is
simply
it's
not
reliable
and
it's
actually
downright
dangerous
for
testing,
because
if
the
build
system
is
used
as
an
API
and
we
want
to
change
the
build
system,
but
the
CI
will
actually
kick
that
out
because
we
won't
be
able
to
build
the
system.
D
B
I
agree
with
Eric's
comment:
I
think
we
are,
we
are
starting
to
go
into
the
weeds
a
little
bit,
I
think
there's
priorities
and
landing
all
right.
So,
like
you
have
a
high
priority
to
get
this
done,
whether
it
be
Google
or
whatnot,
but
the
the
where
it
crosses
the
line
is
from
CI
to
dev
and
test
right.
Well,.
A
Hang
on
just
real
quickly
before
we
we
get
there
cuz
I,
heard
Eric
up
top
say
like
he
wants
to
move
to
a
world
where
this
is
used
as
a
merged
blocking
test
right,
I'm
trying
but
I
heard
I
feel
like
I
heard.
Quinton
say
that
he's
he
wants
to
be
able
to
stand
up
a
doctor
and
doctor
cluster
with
his
tool
set
on
a
local
dev
machine.
Those
seem
to
be
two
goals
at
odds
and
I'm
hearing.
You
guys
say
that
it's
not.
A
D
G
To
me,
Quinton
I
would
say
it's
fair
to
say
that
you
are
committed
to
wanting
to
do
this
project.
Correct
yeah,
I
want
this
project.
Okay,
so
I
would
like
I
feel
like
we're
spending
a
lot
of
effort
with
potential
with
very
valid
points
about
like.
Maybe
this
is
not
a
great
project
to
be
doing,
because
there's
a
bunch
of
existing
efforts
that
are
very
similar
being
a
great
but
I
feel
like
that's
not
really.
The
conversation
you
are
interested
in
having
but
I
feel
like
also
I
feel
like
there
is
substantial
push
back
around.
G
You
know
the
idea
that
if
this
is
in
the
main
repo
it
makes
it
seem
like
the
this
is
a
blessed
project
when
it
doesn't
deserve
that.
Yet,
given
that
this
is
more
of
a
experiment
than
a
best
practice,
I
feel
like
I
feel,
like
you
know,
there
I
mean
what
I
you
whenever
Timothy
and
Maru
are
here,
I,
don't
necessarily
feel
like
they
I
feel,
like
you
know,
there's
whatever
that's
not
necessary
that
these
are
two
outliers.
D
Problem
is,
is
that
is
the
the
difficulty
in
complexity
and
the
reliability
increases
dramatically
when
you
move
it
out
of
the
repo
out
of
the
build
system
for
an
instance
trying
to
hook
into
basil
from
outside
of
it
now
outside
of
build
system
has
problems
with
the
transitive
dependencies
of
workspaces.
We
pull
in
all
kinds
of
the
you
know,
repositories
inside
of
kubernetes
that
we
would
then
have
to
maintain
also
in
the
build
system.
Turning
build
API.
D
The
build
system
into
an
API
of
course
creates
problems
of
ever
changing
the
build
system,
because
CI
will
reject
those
changes.
There
are
also
lots
of
basil
issues
about
like
what.
If
the
basil
versions
are
version
st.
because
basil,
since
it's
not
1.0,
will
make
breaking
changes,
these
systems
will
need
to
be
changed
and
locks
that
which.
B
D
G
G
D
I
was
just
giving
it
as
an
example
of
when
we
go
to
multi
repo.
We
will,
of
course,
have
different
tooling
and,
with
the
different
tooling,
there
will
be
a
different,
a
different
way
that
we
integrate
and
the
the
tool
that
goes
and
tests.
Everything
will
have
to
aggregate
or
collate
all
of
these
things
in
a
different
way,
but
that's
not
how
it
is
today
today.
How
it
is,
is
it's
all
run
together
in
this
one
main
repo.
D
So
the
idea
is
that
this
build
system
will
publish
much
like
republish
detest
this
binary.
What
I
want
to
do
is
I
want
to
publish
a
docker
image
that
you
can
use
to
spin
up
your
cluster
right.
That's
all
it
does.
Is
it
basically,
the
only
thing
this
needs
to
do
in
the
repo
is
grab
the
Debian's.
You
need
shove
them
into
an
image
and
pack
it
to
that
all
together.
Right.
A
couple
things
like
that,
and
so
all
it
does
is
produce
a
docker
image
that
you
can
run
from
anywhere.
How.
D
So
at
the
moment,
I
initially
wrote
it
with
some
more
config
options,
but
at
the
moment
there
are
there.
Are
it
spins
up
a
cluster
in
one
configuration
and
that's
the
configuration
we
want
to
test
it's
three
nodes,
one
master.
It
would
be
what
I,
what
I
would
like
to
do
if
we
decide
to
configure
it
in
a
more
advanced
way,
is
to
either
use
the
config
api's
inside
of
the
master
or
pass
and
again
we'll
file
to
cube
admin
and
I'm
I
think
we're
losing
our
room.
G
I'm
I
think
you
know
Maru
and
Timothy
I'd
be
interested.
You
know,
are
there
things
that
would
I?
Are
there?
Is
there
anything
that
would
convince
you?
That's
putting
this
into
the
main
repo
now
would
be
a
good
idea,
and
or
when
would
you
feel
like
putting
it
into
the
main
repo
like
what
what
like
I
feel
like
you
guys,
are
primarily
against
having
this
experiment
happen
inside
the
main
repo.
But
what
would
change
that,
if
anything.
B
Write
a
proposal
and,
let's
scatter
the
troops
and
execute
on
it,
I'm
totally
fine
with
it
being
external
I,
have
no
qualms
at
all
with
it
being
in
testan,
fro
or
some
type
of
release
trigger
II,
but
I.
Think
in
the
mainline
there's
a
political
ramification
that
seems
to
be
ignored
and
I
don't
want
to
undercut
other
people's
work
and
I
wanna
make
sure
we
rally
them
together.
So
that
way
you
can
have
a
solution
for
that
long
term.
Right,
I
think.
C
A
I
I'm
in
the
interest
of
like
most
compromise
possible,
I'm
wondering
like
what's
what's
how
could
we
make
it
very
clear
that
this
is
an
experiment
while
still
iterating
in
the
main
repo?
Is
it?
Is
it
such
our
hard
political
stance
that,
if
it
goes
in
the
mainline
repo
at
all,
it
is
suddenly
considered
blessed
or
is
there
anything
we
can
do
to
make
it
clear
that
we're
iterating
here,
because
it's
easier
for
now
and
it
will
be
moved
out
as
a
long-term
plan
or
something
well.
D
It
won't
necessarily
be
moved
out
unless
there's
a
technical
reason
to
do
it.
The
reason
I
wanted
in
the
Gruber
Nettie's
repo
is
that
it's
the
it's
the
only
place
where
it
is
sort
of
technically
correct
to
do
it
and
you
end
up.
You
end
up
running
into
a
lot
of
problems,
no
technical
problems
that
require
code
and
failure
modes.
C
D
A
Not
sure
I
understand
that,
like
in
my
head,
I
have
this
dumb
assertion
that,
at
the
end
of
the
kubernetes
build
that's
run
for
every
poll
request.
You
have
a
tarball
that
has
all
the
binaries
and
I
could
very
easily
see
some
external
repo
or
some
external
set
of
scripts,
consuming
that
tarball
stuffing
those
binaries
into
the
appropriate
docker
containers
and
then
pushing
those
someplace
as
a
set
of
artifacts
to
be
run
as
like
docker
and
docker
yeah.
D
C
D
A
D
For
instance,
hypercube
I
don't
need
hypercube
I,
don't
need
to
find
on
tar
Bowl
we
produce
I,
don't
need
all
the
the
swagger
stuff
right.
I
I
really
only
need
cue,
cuddle,
cube
admin,
cubelet
and
the
master
components,
and
so
I
simply
depend
directly
on
those
and
grab
them,
and
it's
considerably
faster
to
do
so,
and
in
addition
to
that,
another
problem
is,
is
that
there
are
components
that
I
need
that
don't
exist,
awesome!
A
A
Go
ahead,
Aaron
I,
just
like
I,
didn't
think
that
the
pull
request-
Eric,
maybe
you
know,
I,
didn't
call
like
I,
didn't
think
the
kubernetes
build
job
that
runs
on
every
pull
request.
Does
a
full
fledged
release,
build
I
thought
it
only
built
like
just
those
confide
in
think
it
build
hypercube,
maybe
I'm
wrong.
It
does.
G
So
while
you
were
changing
rooms,
you
know,
Timothy
was
suggesting
that
if
we
wanted
in
the
main
repo
we
should
have
a
proposal
to
you
know
talk
about
these
sorts
of
details,
which
sounds
to
me
reasonable
and
like
an
appropriate
thing
to
do,
for
the
main
repo
and
yeah
I
mean
I,
don't
know,
I,
don't
know
how
interested
people
are
in
talking
about
all
the
details.
I
mean
I,
guess
I
am
and
maybe
seems
like
most
of
the
people
on
this
call
are,
but
maybe
yes.
A
I
didn't
mean
to
run
it
long
and
you're
right.
I
did
just
want
to
circle
back
to
I
think
like
if
that,
if
it
sounds
Quentin
like
kind
of
have
the
same
goal
as
Tim
does,
which
is,
we
do
actually
want
to
rally
the
troops
around
one
true
way
of
doing
this,
instead
of
having
yet
another
implementation,
every.
D
A
I
guess
I'm
just
getting
a
strong
sense
from
Tim
and
Marie
that,
if
you're
doing
something
that
you
think
is
just
well
scoped
for
CI,
it's
going
to
be
confused
as
an
attempt
to
fulfill
all
of
these
other
goals.
We've
talked
about
Plus,
since
it's
being
done
in
the
mainline,
kubernetes
repo,
it's
being
implicitly
blessed
as
the
one
true
way
of
doing
this,
I
mean
I.
Don't
actually
agree
that
putting.
A
How
many
words
you
know
all
of
the
time
yeah,
but
no
matter
how
many
words
we
use
about
it.
People
are
still
gonna.
Look
at
it
that
way
it's.
This
is
part
of.
Why,
like
we,
as
in
with
my
steering
committee,
have
on
right
we're
really
trying
to
like.
Not
have
anybody
create
anything
new
in
that
repo?
It's,
it
should
be
a
really
high
wall
to
climb
with
written
justification
in
the
fore
of
a
proposal.
D
C
C
Alhasan
II
as
an
example
of
a
technical
reason,
but
but
well,
but
I
think
that
the
this
so
like
there
is
a
sociological
aspect
to
this,
which
is,
if
it's
in
that
repo
that's
kind
of,
becomes
the
focal
point,
because
it's
already
there,
it
is
implicitly
blessed
whether
you
want
to
think
about
it
that
way
or
not.
If
something
is
done
outside
the
repo,
that
leaves
a
lot
more
room
for
other
people
to
experiment
because
you're,
it's
not
the
only
solution.
C
E
C
Not
one
but
a
technical
reason
for
that,
or
is
it
only
political
I
think
it's
it's
less
about.
Do.
I
want
vodka,
okay,
so
I!
It's
not
that
I
don't
want
to
see
a
darker
darker
solution
in
the
repo
but
I
think
as
Tim
was
saying,
there
should
be
a
process
to
get
it
there.
There
should
be
a
degree
of
like.
Is
this
a
good
idea
from
the
community
at
large
all
interested
parties,
not
just
our
limited
cabal?
That's
the
main
thing!
C
C
G
Feel,
like
you
know,
if
they're
I
feel
like
the
focus
should
be
on
one.
You
know
explaining
either
why
you
know
it
whatever
we
want
to
do
why
this
is
not
the
best
way,
but
just
an
experiment.
That
is
not.
You
know,
preventing
other
potential
competing
ideas
from
proving
themselves.
The
second
thing
might
be
are
explaining
why
it
is
necessary
like
why
the
why
the
pains
of
not
having
to
be
in
the
main
brief,
oh
would
be
so
great
that
this
is
the
only
end
or
best
way
to
do
that.
G
You
know
given
even
given
the
fact
that
it's
sort
of
suggesting
the
blessing,
despite
the
mitigations
of
the
you
know
whatever
the
mitigations
about
how
it's
just
experimental
and
then
the
third
thing
would
be
showing
why,
if
this
has
earned
its
rightful
place
as
the
you
know,
solution
and
I
to
me,
it
seems
like
yeah
to
me.
I
feel
like
the
proposals
that
sort
of
focus
on
those
three
things
and
I
feel
like
that,
would
make
it
clear.
G
A
Like
the
reasoning
of
that,
like
look,
I
didn't
again,
like
I,
said
not
having
a
dog
in
this
fight,
I
just
didn't
particularly
care
for
the
way
it
seemed
as
though
two
people
swooped
in
at
the
lot,
seemingly
the
last
second,
it
said,
whoa,
what's
going
on
here
as
an
impediments
progress
at
the
same
time,
I
recognize
this
issue
has
been
discussed
before
and
like
it
was
really
hard
for
interested
parties
to
figure
out.
What's
going
on
so
like
I.
A
Think
Eric's
proposal
sounds
to
me,
like
the
best
compromise,
to
sort
of
allow
work
to
continue
if
it
has,
if
it's
truly
easier
to
happen
in
the
mainline
repo,
and
it's
really
just
an
experiment
from
now
writing
down
and
explaining
how
and
why.
What
would
be
useful
to
communicate
this
to
the
wider
audience
and
then
I
agree
with
Murray's
point
that
you
know.
F
D
A
G
I'd
be
happier
if
we
got
to
a
place
where
the
arguments
were
like.
Oh,
we
need
to
have
an
entry
because
of
X,
and
then
we
can
either
agree
that
X
is
makes
it
necessary
or
no
actually,
we
could
do
X,
prime
or
why
but
I
feel
like
we're
not
actually
having
we're
sort
of
having
all
these
overarching
arguments
about.
You
know
other
things
and
I'd
like
to
switch
it
to
where
you
know
we
have
that
discussion
like.
Is
this
an
effective
mitigation
or
not?
Is
this?
C
Not
entirely
clear
like
why
there
just
couldn't
be
a
build
target.
The
produce
is
exactly
what
you
need
versus
having
had
intrigue
for
the
sake
of
that
same
result,
but
maybe
I'm
missing
something
I
do
and
I
apologize.
I
didn't
see
that
PR
I
didn't
see
that
document
and
I
was
like
I,
had
some
pretty
crazy
personal
stuff
happening
to
me
in
August.
C
That
kind
of
like
caused
me
to
disconnect
from
a
lot
of
things
and
so
I
totally
like
hit
reset
on
my
email
and
unfortunately
you
didn't
see
that
so
my
discovering
it
now
and
the
last
minute
wasn't
like
it's
not
personal
and
I'm.
Really.
Sorry
certainly
wouldn't
want
to
be
on
the
receiving
end
that
sort
of
last-minute
attention
either
I.
A
Mean
that's:
that's
totally
understandable,
like
I
said
having
no
dog
in
this
fight,
it
seemed
like
just
a
repeat
of
the
discussion.
We
had
the
last
time
acquaintance
came
up
and
sort
of
demoed
his
work.
We
were
all
at
like
this
is
great,
but
we've
seen
this
four
or
five
times
before.
Why?
Why
are
we
meeting
this?
And
so
now
it
seems
like
the
work
has
progressed
a
little
bit
and
we're
still
kind
of
having
a
similar
conversation.
F
A
Because,
again,
to
go
back
to
the
thing
up
top,
like
my
my
personal
big-picture
view
of
this,
is
the
largest
win
is.
If
we
get
to
the
point
where
this
is
of
sufficient
fidelity,
that
we
could
use
this
to
block
all
pull
requests
going
in.
Instead
of
spinning
up
full
fidelity
clusters
on
GCE
and
AWS
and
everywhere
it
would
rapidly
increase
our
testing
velocity
across
the
project.
D
A
D
We're
gonna
document
writing
up
all
of
these
technical
reasons
of
why
it's
not
more
antis
and
why
it
should
be
in
the
tree.
So
it's
kind
of
the
I
already
did
a
lot
of
that
work.
Cuz
I
kind
of
thought.
That's
the
discussion
we'd
be
having
now,
but
for
now
I
think
I.
Think
I'm
gonna
have
to
call
it
I,
don't
actually
have
a
chair
here.