►
From YouTube: CNCF SIG App Delivery 2020-12-02
Description
CNCF SIG App Delivery 2020-12-02
A
A
A
B
C
B
Give
people
about
five
minutes
to
join
in
here
we're
in
those
five
minutes.
I
have
the
meeting
dock
already
open.
So
please
add
yourself
to
to
the
meeting
doc
on
the
agenda.
Obviously
operator
working
group
provides
an
update
today,
so
I'll
pass
on
to
you
immediately
fluxim
that
pr
I
brought
it
up
yesterday
in
the
toc
meeting.
So
just
that
you
know
it's
I've
seen
the
issue
that
you
want
to
move
to
incubation,
but
the
official
call
to
do
the
to
start.
B
If
you
want
to
accelerate
things,
obviously
we
can
share
the
due
diligence
documents
that
we
have
been
using
in
the
past.
With
you
last
item.
That's
not
really
wrecked.
It's
just
red
because
usually
usually
that
is
right
here
obviously
is
work
on
the
github's
working
group.
I
think
you
also
have
cornelia
here,
that's
great
okay,
so
I
would
propose
we
keep
the
as
the
long.
The
last
one
will
be
most
likely
a
longer
discussions.
D
D
There
were
some
points
defined.
What
people
may
want
to
get
out
so
this
this
would
be
what
are
the
components
of
an
operator?
What
components
are
not
part
of
an
operator
and
best
practices
and
patterns,
and
the
first
defined
goal
of
the
operator
working
group
was
to
finish
the
definition
of
an
operator
and
therefore
we
created
a
white
paper.
E
F
F
And
when
we
start
talking
with
people,
we
got
some
interesting
topic
and
comments.
One
of
the
example
is
the
threat
model
and
that
we
will
take
with
ck
security
and
the
second
one
is
an
operator
outside
of
kubernetes,
as
we
are
cncf
working
group.
That
is
also
something
we
are
trying
to
think
about.
F
And
what
happened
in
the
last
few
weeks,
so
we
started
the
operator
white
paper
and
thomas
said:
lead
a
small
group
of
people,
I'm
one
of
them
and
we
try
to
get
consensus
inside
the
small
group
and
from
that
consensus
to
go
further
out.
We
talked
about
what
an
operator
is
and
we
try
to
define
some
base
wording
and
semantic
around
it.
F
D
D
D
D
D
We
will
discuss
this
in
the
next
weeks
and
we'll
give
you
an
information
when
this
happens,
but
we
also
might
want
to
think
about
operators
outside
of
the
queue
leave
this
world
and
that's
what
omar
said
before
there
could
be
operators
without
killer
communities
and
I
think,
as
a
cncf
project.
We
should
be
aware
of
this,
so
just
as
an
example
like
like
cf
engine
also
terraform
could
follow
the
operator
pattern,
but
we
will
discuss
this
in
the
last
talk
with
here.
D
And
last
but
not
least,
everyone
is
not
who
is
not
very
confident
writing
operators
or
knowing
what
an
operator
is
every
one
of
those
people
is
the
target
audience.
So
exactly
this
feedback
is
very
valuable
for
us,
so
this
was
the
state
from
our
working
group.
I
hope
you
enjoyed
it
and
it
was
short
enough
and
yes,
if
you
have
questions,
please
feel
free
to
ask.
B
Yeah,
I
think
we
discussed
this
before
so
this
has
been
a
long
time
in
the
making
or
better,
not
not
making.
So
it's
good
that
they'll
be
making
now
actual
progress
on
this
great
that
you're
involving
the
other
operator
projects
and
also
security.
I
think
that's,
that's
really
good
that
we
have
provided
the
audience
there
and
ensure
that
the
projects
are
are
well
covered
in
there.
Also
the
clear
focus
on
target
audience,
I
think,
is
helpful
and
again
yeah.
B
B
If
you
have,
especially,
if
you
have
to
project
somebody
from
the
project
either
from
the
individuals,
we
can
include
also
the
projects
working
on
operator
related
workflow
field,
while
we
presented
by
the
white
paper
and
also
that
you
talk
to
the
security
folks,
how
they
build
their
white
paper
and
copy
it
that's
great,
and
also
that
we
have
offline
collaboration,
obviously
same
as
thomas
being
from
europe.
We
highly
value
offline
collaboration
rather
than
2
am
in
the
morning
in.
G
B
B
It
would
be
one
more
before
holiday
season.
That
would
be
amazing,
because
some
people
can
comment
before
so
usually
after
new
holiday
season,
things
get
they
get
to
get
ranked
dragged
along,
and
especially
this
year.
Everybody
will
deserve
to
have
some
relaxation
time,
but
that's
good
good
to
see
that
progress
and
yeah
thanks
also
for
stepping
up
here
on
driving
this
forward.
C
B
C
Hey,
can
someone
give
me
a
thumbs
up?
That's
what
they
expect
to
see.
Okay,
great,
so
flux
has
entered
a
proposal
to
move
from
sandbox
to
incubation
in
cncf
and
we've
been
referred
to,
sig
app
delivery,
which
seems
appropriate,
and
so
this
presentation
is
really
about
making
a
gentle
case
for
you
all
to
endorse
this
move.
Ultimately,
so
I'm
going
to
give
a
bit
of
background
on
flux
and
where
it's
headed
and
then
I'll
try
and
press
my
suit
for
for
making
the
move
into
incubation.
C
C
So
flux
was
about
three
years
in
and
up
to
version
1.13
when
it
entered
the
sandbox,
which
was
a
bit
over
a
year
ago
at
towards
the
end
of
last
year.
Around
the
same
time
we're
entering
the
sandbox
we
we're
talking
to
the
argo
team
I
see
alex
is
here
since
argo
was
also
a
very
strongly
git
ops,
oriented
project.
What
argo
cd
is,
and
we
thought
maybe
we
could
merge
efforts.
C
So,
by
way
of
comparison,
flux,
v1
excuse
me
syncs
a
git
repository
into
the
local
cluster,
and
it
does
some
automation
with
regard
to
updating
yammels
in
git.
Are
you
making
commits
on
your
behalf
when
things
happen,
flux
v2
is
built
from
scratch
and
uses
things
like
the
custom
resources
so
that
it
is
more
sort
of
integrated
with
kubernetes,
specifically,
and
so
in
doing
so.
It
syncs
arbitrary
numbers
of
git
repositories
to
local
or
remote
clusters,
and
it
does
the
automation
thing
as
well.
C
So
it's
a
lot
more
flexible
and
part
of
the
flexibility
comes
from
being
based
on
what
we
call
git
ops
toolkit,
which
is
just
a
set
of
controllers
that
you
can
mix
and
match.
The
idea
is,
you
can
add
your
own
things
in
there
if
you
want
to
do
things
that
are
not
covered
by
flux
and
you
can
hook
it
into
other
systems
like
argo,
workflow
and
techton.
If
you
want
to
accomplish
things
that
are
sort
of
outside
the
scope
of
that,
you
can
do
with
just
writing
code.
C
So
this
is
this
illustrates
that
transition
flux,
v1
work.
This
is
20
20.,
so
flux,
v1
work
is
green
and
dark
purple.
So
towards
the
start,
that
was
pretty
much
all
that
was
happening
and
then
gitop's
toolkit
and
flux.
V2
is
yellow
and
all
the
other
colors
more
or
less,
and
you
can
see
there's
sort
of
transition
from
mostly
working
on
flux,
v1
to
working
more
on
flux,
v2
without
giving
up
v1
entirely.
C
All
right
so
that's
kind
of
where
flux
came
from
and
where
it's
heading,
let's
look
at
incubation,
so
this
is
these
are
the
criteria
as
set
out
by
the
toc
and
I've
just
picked
out
and
bold
the
the
things
that
are
relevant
here.
So
the
project
must
be
used
successfully
in
production
by
at
least
three
independent
end.
C
The
headline
with
respect
to
production
users
is
that
flux
was
alongside
helm
in
the
adopt
sector
of
the
cncf
technology
radar
for
continuous
delivery,
so
in
cncf's
own
words,
that
means
that
it
was
widely
adopted
and
fewer
or
none
of
the
respondents
recommended
against
using
it.
The
respondents
in
in
this
case
are
the
end
user
community
of
the
cncs.
So
that's
quite
an
endorsement.
I
think
the
people
that
fronted
up
and
put
themselves
in
you
know
read
me
as
production
users
tripled
more
or
less
or
just
about
tripled.
C
C
C
C
So,
going
back
to
the
incubation
criteria,
flux
is
used
successfully
in
production.
We've
got
about
77
about
77,
about
80
people
that
are
in
a
readme
that
have
volunteered
themselves
as
production
users
to
pick
out
a
few
control
plane,
ibm
and
reputing,
we're
all
pretty
big
users,
but
also
remember
the
technology
radar
where
flux
was
in
the
adopt
category,
which
I
think
I
will
repeat.
In
fact
I
think
that's
quite
a
an
endorsement
from
the
end
user
community
of
the
cncf.
C
We
have
a
healthy
number
of
committers.
I
mentioned
roughly
half
the
committees
are
from
outside,
we've
works,
although
it
was
a
historically
a
we've
worked
project
and
there's
about
13.
I
think
13
at
last
count
people
who
are
a
maintainer
of
one
or
more
of
the
sub
projects
and
there's
a
substantial,
ongoing
flow
of
commits.
C
This
is
subjective
and
it's
called
out
as
such
in
the
criteria,
but
there's
on
the
order
of
tens
of
prs
a
week
that
get
entered
posted
and
and
merged,
often
from
first-time
contributors
and
non-maintainers
and
clear
versioning
scheme
yeah.
Well,
we
were
at
1.13
when
we
entered
the
sandbox
now
we're
approaching
2.0
and
we
use
semver
so
we're
quite
concerned
with
backward
compatibility
and
so
on.
C
Yeah,
it's
kind
of
maybe
beta
level,
so
it's
not
out
of
1.0
or
I
guess
it
would
be
2.0
still
sort
of
going
through
the
zero
point.
Minor
versions
we're
pretty
close
to
feature
parity
across
the
board
with
flux
d1.
So
I
think
in
the
first
bit
of
next
year.
That's
when
we'll
start
thinking
about
as
a
ga
general
availability.
G
B
I
mean
it's
just
a
general
question
so
by
what
would
be
for
the
ideal
time
because
you're
switching
over
to
the
new
version,
which
is
currently
not
released,
but
a
waiting
version
for
we
we
too
might
be.
I
mean
they
do
the
literature's,
probably
something
that
happens
overnight,
obviously
anyway.
So
that's
why
I
was
asking.
B
It
might
mean
time
on
the
end
user
examples
that
you
brought
up
or
the
user
examples.
You
can
obviously
list
also
other
commercial
software
vendors
in
there.
I
know
that
you
have
end
users,
I
recommend
are
using
end
users
because
technically
the
doc
states
and
users.
There
are
obviously
some
examples
where
then
it's
up
to
the
qc
to
decide
whether
they
accept
somebody
as
end
users.
B
Yeah
ibm
would
fall
in
the
category
yeah
yeah
you,
you
have
those.
I
know,
I'm
just
making
the
point
that
it
might
be.
That
is
easier
for
that
process,
usually
yeah
and
obviously,
if
you
have
some
version,
two
that's
obviously
helpful,
as
currently
I
mentioned
before
so
having
them
on
on
v2
is
definitely
helpful
because
that's
the
latest
version
is,
it
was
bigger
cut
in
there
yeah
on
that
virtual
around
flagger.
B
The
from
the
due
diligence
point
of
view
we
have
to
think
of
how
we
going
to
evaluate
this.
This
is
obviously
happening.
More
than
projects
are
kind
of
merging
together
and
getting
closer
to
each
other,
and
we
had
this
situation
in
the
past
it
from
an
from
a
due
diligence
perspective.
It
just
complicates
things
sometimes
a
bit,
but
not
necessarily
too
much,
but
I'd
definitely
like
to
learn
more.
B
C
C
B
Yeah
and
what
I'll
definitely
do
again,
as
I
mentioned,
I'm
picking
the
tvc
because,
like
we
just
want
to
follow
the
official
procedure
here,
we
don't
want
to
slow
things
down,
but
still
keep
the
keep
the
proper
flow
of
things
here.
Yeah.
Thanks
for
the
update,
I'm
opening
up
to
quite
a
total
question
from
the
divider
audience
here.
G
G
B
B
Start
doing
things
that
that's
within
the
responsibility
of
the
toc
or
check
whether
there
are
any
opinions
from
the
toc
that
we
have
to
take
care
of
first.
But
if,
as
we
are
talking
about
this
right
now
and
as
we're
getting
off
this
call-
and
I'm
talking
to
you
to
michelle
who's,
our
tlc
liaison
to
help
us
push
this
push
this
forward
here.
And
that
was
a
broadcast.
Yesterday
with
the
tv.
G
B
Also
decide
that
they
also
want
to
have
a
due
diligence
by
another
working
group,
for
example
securities,
or
is
very
often
obvious
one
that
they
want
to
have
a
look
at
things
as
well,
but
we'll
stay
in
touch
with
you.
I
think
michael
and
cornela.
You
will
be
the
primary
points
of
contact.
So
if
you
need
anything
we'll
just
reach
out
to
you,.
B
And
because
usually
we
also
take
also,
on
the
the
chase
point
of
view,
it's
really
some
time
to
dive
into
this,
like
even
trying
out
solutions
working
with
them
playing
around
asking
questions
and
moving
things
forward,
but
don't
expect
it's
like,
I
think
now
it
used
to
be,
and
maybe
a
bit
more
of
a
painful
language.
The
process
in
the
past,
but
now
that
we've
standardized
more
of
the
due
diligence
work,
especially
here
issue
goes
mostly.
B
B
Be
good,
okay,
so
that's
the
whole
topic
around
the
unfortunately
might
also
have
at
some
point
there.
Obviously
there
was
the
it's
about
the
github's
working
group
that
you
announced
during
you
kubecon.
In
that
conversation
also
with
alexis
and
others,
I
started
that
first
charter
document.
I
think
that
still
needs
some
more
content
there.
There
were
also
some
comments
already
on
there,
so
like
more
semantics,
but
still
important
about
this.
This
topic
around
like
calling
it
a
manifesto
or
calling
it
something
else.
I
I
think
I
wanted
to
bring
up
this
topic
today
to
kind
of
mention
that
we
are
very
excited
that
there
is
a
work
group
that
has
been
proposed
and
I
would
love
to
know
more
about
it
again.
What
I've
read
online,
it's
a
great
move.
I
think
this
does
give
us
a
chance
to
actually
serve
different
customers
and
cube
and
cube
users
around
the
world
around
cutoffs
practices.
I
My
my
only
comment
on
that
would
be
that
it
would
be
great
if
we
could
make
it
a
little
more
vendor
neutral
and
a
little
more
technology
neutral
if
possible,
which
means
there
are
other
cncf
projects,
also
other
like
arco,
cd,
which
is
pretty
popular
out
there.
We
just
need
to
ensure
that
we
drive
this
from
more
from
a
practices
perspective
than
a
very
specific
technology
perspective,
so
I
just
want
to
bring
the
topic
up.
I
let
other
folks
chip
in,
if
needed,
alex
mukulika
john
in
the
arab
community.
G
And
so
I
I
would
love
to
jump
in
right
away
and
I
will
say
100
that
we
are
completely
with
you
on
the
neutrality.
Our
goal
here
is
not
to
make
this
a
technology
specification
or
anything
like
that.
It's
very
specific.
You
know
like
that.
It's
we
just
talked
about
flux,
but
it's
flux
and
nothing
else.
This
is
really
about
addressing
the
set
of
concepts.
G
Now,
this
isn't
specific
to
kubernetes
back
to
the
point
of
technology
neutral
and
vendor
neutral,
even
though
michael
earlier
talked
about
the
fact
that
flux
v2
is
from
an
implementation
perspective,
more
kubernetes,
but
what
we
want
to
do
with
the
getups
working
group
is
really
talk
about
the
concepts
talk
about
the
fact
that
it's
not
just
the
runtime
reconciliation
loops,
but
that
having
a
reconciliation
loop
around
delivery
that
enables
us
to
do
things
like
drift
detection
and
things
like
that.
Those
are
the
concepts
that
we're
aiming
for.
G
So
I
completely
you
know,
being
one
of
the
organizations
and
for
those
of
you
who
don't
know
me
see,
cornelia
davis,
cto
at
weave
works
being
one
of
the
the
organizations
that
kind
of
brought
this
to
the
the
working,
the
app
delivery,
sig
and
and
came
out
with
this.
This
concept
we
all
of
us
are
myself,
you
know:
we've
works
as
well
as
the
other
organizations
are
really
looking
at
this
being
a
conceptual
thing
and
serving
the
end
user
community.
It's
not
a
vendor.
It's
not
a!
I
ask
you
a
play.
I
G
Thank
you
100
and
I'm
thrilled
at
I
will
say
so.
I'm
sorry.
I
promise
I'll
zip
up
in
just
a
moment
when,
when
eloise
sent
out
the
note
and
said
here's
the
google
doc,
you
know,
register
your
interest.
I
was
just
so
overwhelmed
and
delighted
with
the
number
of
folks
and
to
hear
you
say
it
with
the
emphasis
that
you
did
that
you're
so
excited
about
this.
I
mean
we
thought
that
would
be
there
and
I
think
it
was
made
even
more
than
we
anticipated
so
thrilled
with
the
interest.
E
B
I
think
we
are
pretty
flexible
on
the
work
group.
I
think
with
this
chart.
The
document
still
needs
some
work
and
we
need
to
do
some
housekeeping
that
was
also
brought
up
yesterday
in
the
toc
call,
because
he
wanted
to
announce
it
during
kubecon.
We
were
okay,
let's
keep
it
under.
Currently
the
flux
ct
org.
B
I
brought
this
up
to
the
t
beforehand
and
there
yeah
okay.
It
takes
some
time
to
move
it
out
of
the.
I
think
this
this
would
just
make
it
definitely
more
neutral.
Alexis
mentioned
that
he'd
already
talked
to
to
the
cncf.
If
you
need
any
help
there,
please
let
us
know,
I
mean
technically,
you
can
create
a
separate
org
and
just
invites
the
the
cncf
that
most
projects
do,
that
they
have
full
control
over
them.
So
that
would
be
easy
easy
to
do.
B
I
think
it's
also
crucial
that
you
think
about
the
governance
model,
especially
as
it
comes
from
flux
and
weave.
I
know
you
want
to
have
it
open,
but
there's
like
other
projects.
I
was
thinking
that
are
interested
in
this
and
I
think
also
like
working
on
the
on
the
charter
topics
and
moving
the
things
forward.
J
Hi,
this
is
paul
morey
from
red
hat.
I
know
a
couple
of
you
already.
I
wanted
to
just
suggest
that
since
there's
an
intention
to
make
it
vendor
neutral,
knowing
that
it
can
take
a
little
while
to
get
like
github
repos
moved
around
and
stuff
like
that,
I
think
it
would
just
be
worth
putting
something-
maybe
a
couple
lines
in
the
readme
cornelia
to
articulate
what
you
just
said
around
neutrality.
I
took
a
look
at
the
repo
the
other
day
and
sort
of
had
some
questions
about
that.
B
I
think
it
can
be
done
done
easily
and
I'm
happy
to
support
on
this
if
needed,
creating
the
separate
org
you
have
to
check
in
with
alexis
where
this
is,
but
I
know
from
like
needing
project
from
the
cncf.
This
usually
goes
easy.
Orcs
are
sometimes
a
bit
different
and
then
it
kids
outside,
but
that
I
think,
would
definitely
be
helpful
and
also
was
it
a
collaboration
on
on
the
on
the
charter
and
again,
I'd
recommend.
B
H
H
I
think
it
would
make
sense,
given
the
nature
of
this
one,
for
it
to
be
under
app
delivery.
There
isn't
a
clear
reason
why
it
would
need
to
be
sort
of
shared
between
multiple
cigs
unless
I'm
missing
something,
in
which
case
it's
actually
fairly
easy.
Does
sig
app
delivery
have
its
own
repo.
At
this
point,.
H
G
Yeah,
so
I'd
love
to
I,
I
like
the
way
that
you
characterize
that,
and
I
do
want
to
pose
a
question
and
I'd
love,
especially
since
we
have
so
many
active
participants
today
to
get
some
other
thoughts
on
this
so
get.
Ups
is
something
that
we
often
talk
about
it
from
the
perspective
of
applying
the
git
ops
model
to
app
delivery,
but
the
getups
model
is
actually
far
more
generalizable
than
that.
It's
not
necessarily
just
for
app
delivery.
It
could
be
for
literally
anything
so
I'll
give
you
an
example.
G
They
you
know
we
run
we've
cloud
at
weedworks.
We
run
weavecloud
on
aws
and
one
of
the
things
that
we're
putting
in
place
one
of
the
things
that
amazon
recommends
if
you're
running
on
amazon
and
we
do
run
on
amazon-
is
that
you
have
alerting
setup
for
your
s3
buckets
so
that
if
the
permissions
are
inadvertently
or
intentionally
set
to
public,
you
have
to
have
an
alert
so
that
somebody,
it
doesn't
happen
inadvertently.
G
So
there
is
an
example
of
where
a
get
ops
pattern
works.
Really
well
is
that
you
can
specify.
This
is
the
way
I
want
my
permission
set
on
s3
and
it's
constantly
watching
that
and
and
you've
specified
that
in
a
git
repository
somewhere
and
you've
got
some
reconciler.
That
is
watching
those
permissions.
G
So
here's
a
case
where
it
isn't
so
much
about
the
app
delivery,
but
it's
around
configuration
operational
configuration
of
some
other
system,
and
so
I
haven't
been
super
worried
about
whether
we
do
this
under
app
delivery,
because
I
think
it's
a
reasonable
home
and
it
gives
us
kind
of
a
starting
point.
But
gitops
itself
is
not
constrained
to
just
application
delivery.
E
So
thoughts
everybody
is
using
githubs
for
clusters,
reconciliation,
they
have
started
using
githubs
for
lambdas
they've
started
using
githubs
for
aws
resources,
so
agreed,
but
I
think
since
so
many
vendors
and
companies
are
interested.
It
felt
like
app
delivery.
Sig
is
more
neutral
home
and
but
any
other
suggestion
is
fine.
Yeah.
G
H
F
B
B
Vendors
are:
are
interested
working
groups
have
kind
of
an
interesting
history.
Josh
correct
me
if
I'm
wrong,
but
if
you
look
at
some
of
the
ccf
documents,
they
are
still
stated
as
like
being
sponsored
by
a
tse
member.
Then
they
move
into
the
six.
So
there's
multiple
documentation
out
there.
How
do
they
actually
work
so
sick,
app
delivery?
Is
it
is
open
to
he's
obviously
open
to
supporting
this
as
well
to
create
the
charter
documents
with
a
lot
of
people
there.
We
can
help
you
setting
up
meetings
and
so
forth.
B
I
think
it
should
move
out
of
relax
repo
because
it
just
creates
a
lot
of
questions
or
like
an
imbalance
that
some
people
don't
feel
comfortable,
not
feel
comfortable
with
which
I
think
is
fair,
and
then
we
should
ensure
that
we
have
to
pretend
he
will
have
the
participation
of
this
there.
I
think
the
key
is
the
charter
document
and
also
these
existing
currently
in
multiple
places.
B
B
B
I
think
the
key
question
is:
do
you
see
this
as
something
that
will
go
through
the
process
of
a
typical
cncf
project?
Where
it's
like
right
now,
it's
sandbox,
then
we
move
it
to
incubation,
and
then
we
move
it
to
graduation.
Or
is
it
really
the
collaboration
around
the
concept
and
delivering
things?
That's
much
closer
to
work
that
a
working
group
usually
would
do.
H
G
G
G
B
Yeah,
maybe
that's
I
mean
we
have
some
discussion
points
still
around
that
working
group.
Let's
try
to
get
some
more
clarification
in
the
next
two
weeks,
because
we're
always
on
top
of
the
hour
here
and
then
journey
in
two
weeks
from
now
where
we
have
hopefully
more
more
clarification
on
those
topics.
B
The
good
thing
is,
we
have
the
charter
document
where
a
lot
of
people
declare
interest,
and
I
think
it
would
be
good
to
find
a
way
to
keep
these
people
in
the
loop.
I
think
you
have
like
created
quite
a
lot
of
interest,
which
is
good,
and
I
think
getting
the
money
for
call
is
definitely
helpful.
If
we
need
a
meeting,
that's
usually
something
that
cff
can
help
as
well
like
scheduling
a
meeting,
the
ccf
client
gets
fuller
and
fuller,
though
I
think
it's
definitely
doable
if
we
need
one
there.
I
G
B
Okay,
yeah,
that's
sweet!
That's,
I
think
continue
this
discussion.
Two
weeks
from
now
I
mean
it's
good
that
you
push
forward
and
move
things,
and
I
think
it's
normal.
Then
when
you
start
things
off
fresh
and
you
want
to
move
fast,
you
have
to
do
some
of
the
very
cleaner
work
later
on,
which
is
totally
fine.
Yeah
just
ensure
that
everybody
feels
comfortable
with
that
we're
actually
moving
in
the
good
thing
is,
there
is
there's
excitement
and
let's
work
on
this
and
put
it
on
the
agenda
for
next
time
as
well.