►
Description
Topics
New name!! (??) [GC]
Poll and results thread: https://cloudfoundry.slack.com/archives/C0297673ASK/p1645525741882959?thread_ts=1644421762.480579&cid=C0297673ASK
Bifrost (78.5 Borda, 73 Condorcet)
Korifi (67.5 Borda, 62 Condorcet)
Faros (64 Borda, 58 Condorcet)
Chris Clark to engage with Linux Foundation legal
Giuseppe and Birdrock to mention this at CFF governing board meeting
[RI] Anything we can start to demo yet ? Or document?
Agreed that docs/installation experience could use some improvement. Concerns on amount of dev bandwidth available right now to do this
We think it’s worth demo-ing still even though these aren’t perfect.
Ram to try this installation to a K8s cluster and provide installation experience feedback on Slack. We can get some quick doc wins this way as well
The “deploy on kind” script works well for folks looking to kick the tires
Ram: This project could benefit greatly from having a fool-proof set of installation instructions documented
[PC] v0.1 Milestone Progress?
[PC] Testing Proposal(s)?
Initial style proposal hoping to wrap up in the next day or so
Need to discuss the bigger issue of what kind/type of tests to write. End-to-end (running against KinD by default), vs envtest “integration”, vs regular unit
API Shim and Controller tests might be two separate convos
Integrated tests are a scam!
2 week experiment to try no new API shim “envtest integration”, only e2e
[GC] Presentation to board tomorrow
A
B
Yeah
so
yesterday
I
crunched
the
numbers
had
a
lot
of
fun
with
it,
because
we
had
this
like
couple
of
alternative
ways
of
calculating
you
know
the
ranking
and
it
turns
out
they.
They
both
lead
exactly
the
same
ranking
which
was
really
fun
and
yeah,
so
the
bifrost
seems
to
be
by
far
the
preferred
option.
B
So
I
guess
next
is
to
just
make
sure
it
doesn't
mess
up
with
any
anything
like
legally
or
I
don't
know,
check
check
that,
there's
no
copyright
problems
or
whatever,
and
then
we
move
on
with
it.
I
guess,
and
the
good
thing
is
that
we
I
mean
if,
if
buy
first,
doesn't
work,
I
guess
we
can
just
drop
to
the
second
choice
and
then
third,
by
having
used
like
a
rent
system,
we
have
a
ranking.
So
we
don't
have
to
vote
again.
B
Yeah,
that's
it
I've.
The
question
marks
out
because,
yes,
I
I've
seen
some.
I
saw
some
doubts
on
slack
about.
I
don't
know
companies
using
the
name,
I'm
not
particularly
concerned
about
it,
just
because
I
think
there
is
a
risk
that
any
name
we
pick
will
have
been
picked
by
some
remote
company
somewhere,
it's
more
like
how
problematic
is.
It
is
for
us
first
from
a
legal
standpoint
and
then
from
a
ceo
in
a
way
like
seo.
B
C
C
I
do
think
tomorrow
in
the
you
know,
when
you
and
andrew
present,
giuseppe
to
the
to
the
governing
board.
You
know
they
might
have
some
input
into
this.
I
mean
those
three
are
all
I
think
quite
viable
yeah
I
like
pharos,
maybe
the
ph,
maybe
not
it's
one
of
the
seven
wonders
of
the
ancient
world,
very
cool
by
frost.
C
My
only
concern
with
bifrost
is
that
I
think
that,
like
I
guess,
there's
a
marvel
like
more
recent
cultural
reference
there
too,
but
but
like
the
the
pronunciation
of
it
is
like.
Maybe
it
would
be
like
in
the
original.
Like
kind
of
nordic
would
be
like
beef
roast
or
something
like
that
which
doesn't
roll
off
the
tongue
generally,
but
you
know,
but
it
just
sounds.
C
You
froze
yeah,
and
then
you
know
we.
We
discussed
these
these
three
at
the
the
tse
call
just
before
this,
and
someone
mentioned
that
okay,
so
so
so,
bifrost
like
it's
a
rainbow
bridge
connecting
the
the
realm
of
the
gods
to
the
realm
of
humanity,
which
one's
which,
like
this
is
platform
to
humanity
and
kubernetes,
is
the
realm
of
the
gods.
I
that
would
be
my
inference,
but
but
I
don't
know
exactly
so
I,
like
the
metaphor,
the
bridge,
but
just
you
know,
we
should
talk
through
these
things
and.
E
C
B
C
C
C
B
A
F
So
if
there,
if
there
is
like
an
initiative
there
or
if
that
needs
to
be
picked
up
and
get
done,
then
I'm
more
than
happy
to
you
know
get
on
with
that
and
help
out
in
some
form
of
manner,
because
you
know
it
will
be
really
useful
and
even
if
there's
so,
I
think
the
document
could
be
the
first
step
and
some
demos
that
can
follow
up
on
the
on
that
documentation
and
go
on
like
the
foundation,
youtube,
channel
and
other
places.
I
think,
would
be
useful
in
getting
that
initial
traction.
B
G
We
have
talked
about
this
that
we
don't
really
have
an
official
way
to
deploy,
there's
a
dev
script
that
deploys
it.
We
really
haven't
thought
about
this
so
far,
so
I
guess
it's
an
open
discussion.
We
don't
really
know
what
tools
we're
going
to
use
is
going
to
be
like
right.
Now
it
is
customized,
it's
probably
not
going
to
stay
like
that.
G
G
H
G
B
B
D
A
Because,
like
one
of
the
questions
is,
is
it
worth
demoing,
even
though
the
docs
and
installation
is
subpar,
which
I'd
like
personally
think?
It
is
because
it's
very
demo-able
right
now
and
then
like?
Maybe
that's
just
a
caveat
that
we
mentioned
like
this,
is
all
still
being
worked
on
and
in
flight.
B
G
G
I
wonder
how
hard
it
would
be
to
deploy
this
to
some
sort
of
real
cluster.
What
would
be
the
main
things
that
don't
work
because,
like
ram
said,
he
would
be
happy
to
like
help
with
this
one
so
maybe
like?
If,
if
maybe
ram,
if
you
take
the
script
like
try
to
do
it,
we
can
probably
help
like
you
can
write
in
the
in
the
public
channel.
We
can.
G
H
Yeah,
I
just
wanted
to
comment
that
I
think
I
had
to
deconstruct
some
of
the
steps
in
like
the
install
dependency
script.
This
was
maybe
a
little
bit
out
of
date
now,
but
I've
been
able
to
get
this
deployed
successfully
to
gke,
with
all
the
dependencies
again
with
just
pretty
manual
use
of
the
assets
and
and
customize.
H
So
I
mean,
I
think,
it's
pretty
straightforward,
but
I
I
think
it's
going
to
look
more
attractive.
If
we
do
at
least
I
mean
it
doesn't
have
to
be
a
one-click
install
of
a
file,
but
if
we
have
a
reasonable
set
of
steps
for
someone
to
say,
okay,
here's
a
release
of
this,
I'm
okay,
pulling
the
images
from
docker
hub
or
wherever
or
gcr
public
registry,
but,
like
you
know,
give
me,
give
me
a
fairly
prescriptive
set
of
steps
to
follow
to
install
this
on
a
kubernetes
cluster.
H
I
wouldn't
have
a
lot
of
compunctions
about
that,
but
I
also
wouldn't
rely
on
that
being
the
only
cluster
type
somebody
has
so
if,
if
we
have
time
to
take
a
pass
just
to
say
like
okay,
here's,
here's
the
steps
to
go
through
to
install
the
dependencies
and
then
install
the
resources
of
the
actual
cf
on
kids
project
at
a
particular
set
of
images
and
resources
for
configuration.
Then
that
sounds
appealing
like
a
good
minimum
for
to
accompany
that.
First,
beta.
F
I
mean
in
some
sense
the
cf4
gates.
Installation
was
also
a
bit
hacky
because
there
was
like
there
was
quite
literally
a
script
named,
generate
values
for
the
yaml
file,
and
that
was
under
a
folder
named
hat,
and
so
it
would
cough
up
a
one
and
saying
hey
make
sure
you're
not
using
the
sun
production.
This
is
no
way,
you
know
good
and
stuff
like
that.
So
but
then
I
think
it.
F
F
But
yes,
there
should
be
a
foolproof
set
of
instructions
is
what
I'm
thinking
in,
even
if
you're,
like
beta
or
pre-beta
or
whatever
early
stage
we
are
at
it's
still,
I
think
would
benefit
greatly
from
having
that
kind
of
documentation.
So,
anyhow,
I'll
follow
up
with
folks
on
the
public
channel
and
start
to
put
something
together
and
folks
can
share
whatever
they
have
on
the
channel
like
let's
go
from
there
thanks.
I
I
don't
know
if
under
resource
is
the
right
way
to
look
at
it,
but
you
know
you
got
a
few
priorities
going
on,
but
then
also
just
checking
in
on
the
stories
that
we
need
to
write
around
getting
stuff
ready.
Do
it
do
we
feel
like
those
should
be
added
to
the
0.1
milestone
as
well
like
once
they're
created.
I
just
want
to
have
kind
of
an
open
discussion
and
see
how
people
are
feeling
about
the
0.1
and
there's
anything,
maybe
we're
missing,
or
we
should
be
doing
on
top
of
what
we've
already
planned
out.
B
Yeah,
so
the
currently
it
says,
github
tells
me
it's.
The
milestone
is
62
complete.
There
is
15
stories
open
in
the
milestone.
I
know
for
a
fact
that
I'm
missing
at
least
a
couple.
I
think
the
space
manifest
endpoints
are
still
missing
on
those
stories
and
the
reason
is,
I
think,
those
are
quite
complex.
Endpoints
they're
not
like
they
know,
there's
no
like
one-to-one.
B
It's
not
just
one
called
on
one
resource.
It's
it's
more
complex
than
that
plus
yeah.
These
stories
about
documentation
could
probably
fit
in
there,
which
means.
Maybe
there
is
another.
I
don't
know
five
stories
to
add.
You
know
ten,
I
don't
configure,
but
it
feels
like
we
are
at
least
halfway
through.
B
So
it's
not
that
bad
cool.
There
are
relatively
small
stories
but,
like
I
have
I'm
a
bit
nervous
with,
like
writing
a
gazillion
stories
up
front
and
then
letting
them
sit
for
a
long
time.
I
like
to
write
them
as
I
go,
but
that
also
means
that
the
milestone
never
looks
like
it's
it's.
No,
it's
not
very
realistic
until
I'm
done,
but
I
think
most
stories
are
there.
So
I
don't
think,
there's
many
other
stories.
I
I
need
to
add
at
least
for
the
authentication
stuff.
I
I
I
G
G
So
we
are
writing
them
and
we're
kind
of
liking
them
because
they're
exercising
the
deployment,
the
wiring
all
that
kind
of
stuff,
they
can
catch
nasty
things.
They
have
called
nice
things
for
us
in
the
past,
and
people
are
in
the
in
the
other
time
zone
are
not
very,
not
quite
fun
about
them
like
we.
G
G
G
I
Okay,
is
it
good?
Are
we
gonna
talk
about
it
like?
When
do
we
get
to
talk
about
it?
I
mean
this
is
our
30
minutes
at
the
moment
to
talk
about
it,
I
mean
for
the
most
part,
so
you
know
I
don't
know.
If
anybody
on
has
strong
opinions
or
wants
to
talk
through
it
or
we
want
to
get
to
the
next
topic
and
we
can
come
back
to
it.
You
know
I'm
open.
I
just
I
want
to
make
sure
we're
having
the
conversation.
B
D
E
A
D
E
E
D
J
J
J
From
my
point
of
view,
we
should
be
testing
against
the
real
thing.
The
test
environment
has
some
limitations
that
are
have
hidden
problems
in
the
past
and
probably
the
workflow
would
be
when
you
start
creating
a
story.
Work
on
a
feature
you
start
with
an
entrant
or
integration
or
whatever
you
want
to
call
it
test,
see
it
failing
and
then
go
back
to
the
implementation.
J
B
This
is
basically
the
way
we've
been
used
to
to
work.
I
guess
on
on
the
previous
projects
as
well.
Well,
like
I
think
that
my
problem
with
the
integration
test
is
that,
if
you
think
of
the
system
as
a
composition
of
smaller
components
to
me,
the
only
boundaries
that
make
sense
to
tests
are
either
the
boundaries
on
the
individual,
smaller
components
or
the
whole
system
as
a
whole.
B
Considering
the
user
interface
is
the
boundary.
If
you
see
what
I
mean
like,
but
if
you
just,
I
don't
see
the
point
in
testing
a
subset
of
the
components
because,
like
if
I'm
testing
the
handler,
plus
the
repository
plus
a
little
bit
of
kubernetes,
then
I
might
as
well
test
the
whole
thing
you
know,
but
I
can
test
the
handler.
B
I
can
test
the
handler
by
itself
mocking
the
repositories
mocking
everything
and
I
can
test
the
repository.
Maybe
we
test
them
for
for
speed
instead
of
a
rear
repository,
but
like
arbitrary
composition
of
components.
Don't
help
me
in
coverage
and
usually
they're
hard
because,
like
you,
have
combinatory
explosion
of
power
across
those
components
and
it's
very
hard
to
cover
all
cases
through
them,
so
that's
usually
I
never
use
them.
So
I
never
write.
What's
called
integration
or
integrated
tests?
B
B
So
that's,
but
I
see
I
see
that
many
people
use
them
for
driving
stuff
for
test
drive
and,
like
I
don't
want
people
to
feel
like
they.
You
know
they
have
to
test
drive
via
entrance,
because
it's
of
course
not
feasible
and
also
if
people
are
not
confident
at
driving
test
driving
with
mocks,
then
there
must
be
a
reason
right.
So
I
don't
know
how
we
get
out
of
this
but
like.
If
it
were
me,
I
would
just
get
rid
of
the
integration
like
they
just
they
don't
fit
in
our
testing
model.
B
A
A
The
contract
is
the
the
controller
and
the
kubernetes
api
and
less
of
these
collaborators
so
like,
I
think
if
we
can
like
at
least
say
that,
like
it's
fine
to
keep
those
imp
tests
as
like
what
how
we
test
drive
the
controller
stuff
that
that
would
be
good
just.
I
just
wanted
to
add
that
to
make
sure
we're
all
thinking
about
this.
The
same
way.
B
Yeah,
I
mean
we've,
I
think
in
irene,
we've
done
without
them
and
use
different
techniques,
but
I
can
see
the
pros
of
just
testing
them,
because
they're
kind
of
coupled
with
how
kubernetes
works
like
the
whole
reconciliation
loop,
is
that
I
mean
technically
you're
implementing
an
interface.
You
should
be
able
to
do
without
amp
test,
but
if
you
do
with,
if
you
do
it
with
m
test,
I
can
see
how
it's
easier
for
the
api.
I
think
we
have
fewer
reasons
to
use
them.
B
Also
like
going
back
to
amp
test,
like
m
test,
was
designed
exactly
for
the
use
case
you've
mentioned,
which
is
testing
these
controllers.
It
was
not
designed
for
testing
what
we
are
testing
them
like
the
way
we
are
using
m
test
for
the
api.
That's
not
the
use
case
of
any
test
right,
which
is
why
we're
suddenly
finding
ourselves
lacking
things.
Oh,
the
hooks
are
not
there.
Oh
the
the
controls
are
not
there.
B
Stuff
is
not,
let
me
add
more
stuff,
and
suddenly
you
have
this
like
frankenstein,
which
I'm
not
really
happy
with
for
controllers.
I
think
they're
much.
They
make
a
lot
more
sense
because
it's
like
okay,
the
controller
is
basically
you
know,
reading
and
writing
from
hcd
via
the
api,
but
more
and
like
you
want
to
test
that
the
reads
and
writes
from
ncd
are
correct.
B
The
events
that
get
triggered
from
those
reads
and
rights
are
correct.
Then
I
think
that's
much.
That
makes
a
lot
more
sense,
because
that's
what
they
were
m
test
was
born
to
do.
I
think
that's,
which
is
why
you
get
it
for
free.
When
you
generate
a
controller
with.
Why
is
it
called
that
generator
thing?
B
Even
if
we
did
it
without
m
test,
like
it's,
two
different
issues
like
one
is
m
test
is
inadequate
but,
like
let's
say
we
decided.
Okay,
let's
get
rid
of
m
test.
Let's
do
the
same
integration
tests
with
a
real
kubernetes
api
and
we
have
some
of
those
in
irini
I'd
still.
I
would
still
not
like
them
because
they
are
integrated,
because
I
don't
like
to
test
the
handler
and
the
repository
in
one
test.
B
I
test
the
ender
with
a
fake
repository
and
I
test
the
repository
with
a
real
api,
and
then
I
don't
need
to
test
them
together,
because
the
end
to
ends
already
test
that
right.
So
that's
a
the
my
issue
is
with
the
integrated
test.
Mostly
amp
test,
I
think,
is
a
kind
of
separate
issue
which
cannot
agree
on
because,
like
it's
been
just
not
very
comfortable
to
use,
also
the
hitting
the
handlers
with
the
via
the
server
http
interface.
B
So
these
are
like
at
least
three
separate
symptoms
of
the
make
those
tests.
I
just
don't
like
them.
Every
time
I
see
one
I'm
like
oh,
this
is,
I
feel,
like
the
value
of
this
thing.
It
doesn't
pay
for
itself,
it's
so
many
lines
of
code,
not
necessarily
worth
it.
I
see
the
value
in
test
driving
but
like
from
a
testing
perspective,
given
I
don't
use
those
for
test
driving
it's
hard
for
me
to
see
them.
E
And
the
thing
exploded
just
when
we
noticed
that
the
the
fakes
were
wrong
in
the
handlers
to
do
with
error
processing.
So
then
we
added
a
lot
of
stuff
in
there
to
tie
the
two
together
quickly.
I
mean
you
could
put
the
same
tests
in
the
end
or
the
acceptance
test.
But
if
you're
doing
something
like
an
app
which
requires
k-pac
to
go
and
process
a
build,
you
got
to
wait
a
minute
for
it
to
do
it.
E
So
the
tests
are
incredibly
slow
and
you
don't
want
to
go
and
do
four
different
error
cases
on
that.
But
maybe
that
was
just
a
mistake
and
we
should
just
be
careful
with
the
the
fakes
and
the
handlers
and
check
they
do
actually
reflect
what
comes
back
from
the
repositories
and
then
those
tests
can
go
yeah.
B
There's
always
a
risk
with
marks,
but
like
also
there's
no
way
to
prevent
developers
from
writing
the
wrong
test,
like
it's
just
a
sim
you've
just
written
the
wrong.
You
just
wrote
the
wrong
test,
mocking
the
thing
wrong
is
another
way
of
writing
the
wrong
test
or
the
wrong
search.
You
know
doing
the
wrong.
E
E
I
E
A
Yeah,
I
don't,
I
don't
think
we
need
a
hard
blocker
on
matt,
I
think
maybe
posing
like.
I
think
we
should
plan
on
discussing
this
next
week
at
our
at
our
sink
meeting
again
like
just
like
carve
that
out
and
then
maybe
the
slack
combo
is
still
good
just
for
folks
who
aren't
here
to
like
like
if
we
frame
it
like
these
three
types
of
tests,
end-to-end
unit
and
and
the
imp
test
integration
and
like
what
do
you
like
and
dislike
about
them.
A
F
E
B
B
What
that
was
our
first,
so
our
first
feeling
was
like
we
shouldn't
put
them
just
because
it's
gonna
make
the
it's
just
gonna
lead
to
so
many
more
tests
and
and
the
problem
is,
it's
gonna
get
slow.
I
guess
that's
a
problem,
but
like
maybe
it's
fine
like
maybe
we
should
worry
when
they
do
get
too
slow.
If
you
see
what
I
mean
like,
I
don't
know
how
many
endpoints
we
need
to
we
want
to
test
and
how
many
errors
we
want
to
test.
B
You
don't,
and
maybe
because
the
thing
is
to
me,
the
unit
is
just
as
good
as
the
integration
like
from
that
confidence
point
of
view.
If
I
can't,
if
I
don't
test
it
in
the
in
the
end
to
end,
I'm
might
I'm
happy
with
just
testing
it
in
the
unit
and
then
I'm
testing
an
f
right
so
like
that
af
is
the
same
if
even
in
the
the
I'm
exercising
in
the
unit
and
I'm
exercising
it
in
the
end
to
end.
So
it's
not
like
the.
B
B
So
even
if
we
just
tested
positives
in
the
end
to
ends
and
just
tested,
the
negatives
in
the
units
would
be
fine
it.
I
don't
think
the
integration
gives
us
more
confidence.
Yes,
that
there
is
that
mocking
problem,
but
again
just
need
to
keep
an
eye
out
for
marx.
Just
make
sure
that
the
marks
don't
lie.
J
B
Let's
say
we
one
day
decide:
okay,
we're
going
to
rewrite
this
thing
from
scratch.
Like
literally,
we
delete
the
repository
and
we
rewrite
it
from
scratch,
just
by
leaning
on
the
end-to-end
tests,
then,
if
it
would
be
nice
if
the
entrance
has
actually
covered
the
api
well,
well
enough
that
we
would
be
able
to
do
that
or
like
if,
let's
say
someone
comes
with
an
alternative
implementation,
it
would
be
nice
to
just
point
the
test
at
that
implementation
and
say:
okay,
this
implementation
actually
behaves
recent
reasonably
well.
It
passes
the
test.
B
So
I
agree
that
those
errors
are
part
of
the
behavior
of
the
api,
it's
nice
to
pinpoint
them
with
the
api.
I
think
it's
just
a
trade-off
with
cost
if
they
were
cheap.
I'd
be
super
happy
to
just
have
them
there.
It's
just
they're,
not
cheap,
like
especially
if
you
have
repeating
the
setup
at
every
test.
Maybe
we
can
get
clever
with
that.
I
don't
know
but
like
if.
B
To
push
an
app
for
every
test,
then
it's
like
successful
push
failed
push
because
of
error.
One
error:
two
out
of
three
or
four
we're
pushing
five
ups:
every
up
take
to
takes
two
minutes
to
push
that's
easily
15
minutes
for
for
for
the
cf
push
test
and
multiply
that
for
10
or
15
end
points,
and
suddenly
we
have
a
test
with
it.
I
mean
my
mind
goes.
K
B
Yeah
katz
uses
the
cli,
so
I
think
we
are.
We
have
an
edge
because
we
don't
like
the
cli
tests
that
we've
discussed
are
even
a
different
thing.
I
think,
just
by
exercising
the
api
instead
of
the
cli,
we
make
things
slightly
faster
and
slightly
more
robust,
but
yeah
there
is
a
risk
that
we
get
into
cuts
territory.
B
G
One
thing
that
we
have
recently
discussed
is
like
what
happens
if
we
have
a
long
cliff
cluster,
as
we
did
in
concourse,
because
like
these
days,
we
have
to
deploy
cleanly
every
time,
which
is
probably
at
least
half
of
the
time
spent
running
these
tests.
So
we
could
experiment
with
that.
I
don't
know
how
that
will
play
with
actions,
but
maybe
we
can
think
in
this
direction
to
make
them
cheaper.
E
E
E
B
B
I
think
once
we
start
feeling
the
pain
we
can
get
creative
and
you
know,
maybe
there
is
setups
that
we
can
share
between
tests
carefully,
not
to
avoid
false
negatives
or
whatever
and
saving
on
you
know,
setup
by
pre-deploying
their
cluster,
maybe
creating
a
new
namespace
every
time
like
a
new
top
name
space
or
something
so
that
there's
still
good
isolation
between
different
runs
stuff.
Like
that,
I'm
able.
B
H
B
A
B
B
Would
there
be
like
the
democracy,
the
diplomacy
failure?
Oh
like?
Can
we
do
it
and
chat
like
that?
Is
it
would
it
be
extremely
polarizing
or
not?
If
not,
I
think
we
should
just
do
it
and
then
I
guess
I
think
the
proposal
is
the
best
way,
the
best
place
where
to
have
the
conversation
just
because
it's
we
can
chat
we're
like
we
can
comment
on
the
thing
itself,
instead
of
doing
on
slack
or
somewhere
else.
E
E
B
A
Individually,
yeah,
I
want
to
go
back
to
the
first
thing.
You
said,
though
about
would
it
be
tragic
in
a
diplomacy
breakdown?
If
we
did
this
like,
I,
I
think
one
thing
that
helped
that
would
be.
I
know
you
don't
want
to
discuss
on
slack,
but
just
to
like
broadcast
the
intent
of
the
proposal.
It's
like
hey
we're
going
to
be
writing
a
proposal
that
says
these
like
three
things
and
that
might
at
least
like
forewarn
some
people,
so
they're
not
caught
off
guard
or
anything.
A
I
think
I
think
part
of
the
issue
is
just
like.
The
proposals
are
big
and
like
it's,
it's
not
inaccurate
to
say
that
there's
like
a
lot
of
effort
and
thought
put
into
them
so
like
when,
when
you
see
a
big
one
come
and
you
don't
have
any
prior
context
or
aware
of
it,
then
it
feels
like
more
of
like
this
is
a
decision
and
less
of
a
discussion,
and
I
think,
even
though
it
should
be
a
discussion,
it's
not
always
clear.
So
I
think
maybe
just
like
a
quick
slack
thing,
saying
hey!
B
Yeah,
I
guess
there
is
some
inertia
as
well
like
you
write
a
proposal
and
if
that's
the
starting
point
for
the
conversation,
then
you
can
get
just
you
can
get
just
so
far
from
it.
You
can't
delete
the
whole
thing
and
rewrite
it
right
right.
So
by
writing
what
my
what
what
I'm
scared
of
is?
Okay,
if
I
write
a
proposal,
it's
kind
of
a
way
of
basically,
you
know
putting
a
heavy
weight
on
my
opinion
and
then
it's
on
you
to
shift
the
thing
towards
you
and
not
the
other
way
around.
B
I
don't
want
that
to
happen,
but
like
at
the
same
time,
I
feel
like
we're
a
bit
paralyzed.
Now
we're
like
yeah
no
proposal
is
happening,
nothing
is
being
in
the
meantime.
People
make
prs,
some
people
run
the
integration
tests
and
not
the
end-to-ends.
Some
people
write
the
entrance
and
not
the
integration.
So
it's
like
we
are.
We
keep
diverging
and
like
the
more
we
wait,
the
most
the
more
reconciliation
will
be
needed
to
get
to.
I
I
I
don't
know.
I
mean
to
me
that
feels
like
the
the
first
step
is
like:
let's,
let's
figure
out
the
integration
test,
let's
have
a
conversation
specifically
around
what
we
want
to
do
with
this
strategically
and
then
you
know
move
on
to
the
next
one.
After
that
I
don't
know
if
that
sounds
a
bad
idea,.
B
D
It
might
be
good
in
a
proposal
to
just
apart
from
describing
the
end
state.
We
want
maybe
describe
the
steps
of
how
we're
going
to
get
there,
because,
I
think
that's
you
know,
there's
not
like
if,
if
we're
saying,
okay
we're
going
to
scrap
these
integration
tests,
that
represents
a
lot
of
work
and
a
lot
of
other
work's
gonna
happen
while
that
works
going
on
so
like
what
is
what
does
that
mean
in
the
interim
like?
Are
we
deprecating
those
things.
E
D
B
D
B
B
A
I'm
going
to
call
time
real,
quick,
I
guess
to
summarize
maybe
what
I'm
hearing
is
like
we
do
a
like.
I
feel,
like
the
proposal
might
even
delay
this
even
more.
But
what,
if
we
just
like
said
like?
Let's
try
it
like
a
two-week
experiment
of
end-to-end,
only
or
something,
and
then
we
can.
We
can
discuss
that.
How
that
felt.
A
A
K
A
B
Think
there's
yeah,
maybe
over
here
we've
spent
so
many
days
just
back
filling
in
end
to
ends
yeah,
so
we're
kind
of
already
there
with
the
end
to
end
like
because
we
are
convinced
of
their
value
and
we
are
just
introducing
them
whenever
we
don't
find
them,
which
means
even
the
simplest
story.
We
end
up
spending
days,
writing
a
robust
end-to-end
for
them,
so
we're
kind
of
already
there
with
the
end
to
ends.
B
A
B
So,
just
to
say
that
we're
gonna
do
this
tomorrow,
I'm
supposed
to
do
it
with
bedrock,
but
I
haven't
coordinated
with
them
at
all
yet
because
last
week
I
wasn't
that
linux
programming
course
and
he's
off
today.
I'm
I'm
learning
so
I
might
just
not
have
have
might
have
like
zero
chances
of
preparing
this
with
him.
So
I
might
just
do
it
by
myself.
Maybe
I
don't
know
I'm
going.
I've
started
making
slides
and
I
have
all
tomorrow
to
finish
them.
B
I
guess
I'm
gonna
post
the
version
I
have
now
on
the
channel
so
that
maybe
you
can
give
me
some
feedback
overnight
and
tomorrow
I
come
back
to
it
and
because
I
I'm
I'm
put,
I'm
probably
lacking
lots
of
context
on
the
bits
we
haven't
worked
on
on
over
here.
So
even
in
terms
of
like
maybe
ideas
we
have
for
the
roadmap
in
the
future.
B
Yeah
also
in
terms
of
topics
like
I've,
I
have
a
basically
very
brief
history
of
previous
attempts
of
putting
cf
on
kate's.
Then
I
have
the
vision,
some
some
words
about
the
vision
taken
from
the
from
the
vision
document
that
we
had
the
beginning,
then
some
architectures
explaining
basically
how
we're
going
to
do
it
this
time
and
then
talk
about
the
future.
B
B
I
can
just
democf
push.
I
can
just
show
cf
push
like
log
again,
showing
the
integration
with
the
cli
and
pushing
would
be
nice.
So
if
I
manage
to
prepare
it,
I'm
going
to
sneak
in
a
demo
as
well-
and
hopefully
it's
not
supposed
to
last
too
long
right,
because
I
think
we've
talked
about
half
an
hour
more
or
less
plus
questions
etc.
So.
E
B
C
Right
the
board
doesn't
have
I
I
don't
think
expectations
beyond
what
I've
said,
which
is
just
that
you
all
are
going
to
give
a
demo
and
there'll
be
a
q,
a
you
know,
opportunity
after
that.
So
you
know
that
that
all
sounds
very
good.
Obviously,
as
thorough
as
you
can
be
is
great,
but
I
wouldn't
worry
too
much
about
it
in
the
time
you
know
if
it
takes
15
minutes
or
45
minutes.
That's
fine.