►
From YouTube: GitOps Principles Committee - March 29, 2021
Description
Meeting notes: https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit#heading=h.lfuaf62iclbk
A
Okay,
hello:
everyone
welcome
to
a
a
short,
hopefully
short
series
of
get
ops
principles.
Discussions
with
the
github's
working
group.
It
doesn't
have
to
be
any
more
formal
than
that
monday
march,
29th
1
to
2
p.m.
Pacific.
I
guess
I
can't
cover
every
time
zone
but
hi
everybody,
so
I
wanted
to
just
I
by
the
way,
thank
you
all
for
being
patient
on
last
week
it
turned
out
to
be
quite
a
hectic
day.
I'm
glad
this
worked
out
and
thanks
brace
for
taking
the
reins
there.
A
B
B
Whatever
that
is
so
at
a
high
level,
I
guess
what
what
I
think
is
probably
the
the
most
central
is
probably
the
the
principles
themselves
right.
The
four
principles-
and
I
I
want
to
kind
of
gauge
the
what
people
think
about
the
four
that
we
have,
which
are
principle
of
declarative
configuration
principle
of
immutable,
configuration
versions,
principle
of
continuous
state
reconciliation
and
the
principle
of
operations
through
declarations,
those
are
kind
of
the
four
ones
we
have
there
and
there's
a
short
paragraph
for
each
of
them.
B
B
A
Well,
no,
I
was
going
to
use
the
same
one,
but
actually
we
can
we
can
just
do
it.
That's
right.
We
can
do
a
new
one
here,
I'll
open
it
now.
No,
that's
fine.
I've
got
it.
I
just
somehow
was
not
able
to
find
the
old
one.
I
don't
know
okay,
so
let
me
go
ahead
and
paste
it
I'll
make
you
all
or
everyone
can
should
be
able
to
to.
A
A
C
A
B
B
D
B
B
So
question
on
the
general
kind
of
question
is:
is
there
anything
here
that
people
find
controversial
or
would
not
be,
but
like?
Is
there
anything
at
the
high
level?
Do
those
things
kind
of
reflect
our
collective
understanding
of
what
github
says?
There's
been
some
variation
from
kind
of
previous
work
from
the
discussion
on
the
github
issue,
it
seems
like
we
broadly
have
a
consensus.
There
might
be
some
stuff,
that's
missing,
but
there's
a
consensus
that
those
are
kind
of
capturing
something
important
and
valuable.
F
B
Yeah,
so
I
think
that's,
I
think,
that's
just
like
very
awkward
wording.
So
I
think
if
we,
if
we
can
find
a
better
word,
a
better
way
of
expressing
that
that
sounds
really
good,
so
essentially
just
immutable
versions
of
an
entire
configuration
set
for
a
piece
of
software,
so
that
would
include
yeah.
F
F
A
But
I
don't
believe
that
that's
what
we
all
actually
have
agreed
upon
right,
brace,
we
haven't
agreed.
We
we've
said
elsewhere
that
this
could
be
a
a
system
or
a
basically
a
a
subsystem
right
so
and
it
could
be
very
granular,
it
doesn't
have
to
be
all
things.
That's
that's
a
happy
path,
but
not
a
realistic
one,
especially
if
you're
stepping,
if
you're,
stepping
toward
good
ops
right.
B
B
Do
you
think
that
the
the
detailing
text
below
that
header
captures
the
idea
correctly
and
clearly
I
I
I
that
that
would
be
my
kind
of
my
question
before
we
start
on
the
principle
of
immutable
configuration
version
trying
to
find
a
better
way
of
expressing
that.
Are
we
all
in
agreement
with
what
what
that
is
based.
F
F
Sorry
so
so
we
call
systems
that
store
desired
state
in
this
way,
state
stores.
So
when,
when
you're
talking
about
a
state
store,
people
are
going
to
have
very
different
interpretations
of
what
that
means,
and
and
you're
now
introducing
a
label
yeah
to
something
that
may
or
may
not
make
sense.
So
for
me
that
that
is
an
item
that
should
be
taken
out
of
the
principles
and
then
added
back
incrementally,
once
you
have
consensus
of
the
definition
and
the
use
of
the
word
state
source.
C
C
About
desired
state,
so
is
configuration
analogous
to
desired
state.
Then
we
talk
about
state
store.
Is
configuration
analogous
to
state
store?
So
I'm
guessing?
That's
where
where
there
might
be
some
ambiguity
yeah,
so
I
would
say
we
probably
have
to
align
the
header
of
the
principle.
I
do
think
it's
it's
supposed
to
be
there.
I
I
do
think
immutable,
conf,
immutable
and
version
versioning
of
state
is
definitely
something
that
we
have
agreed
upon,
but
I
think
it's
just
a
matter
of
semantics
right.
This
configuration
state
or
not.
A
That's
that's
correct,
and
so
far
in
the
pr
there
is
the
beginnings
of
a
glossary
to
try
to
aid
in
this.
But
the
idea
was
fully
that,
if
there's,
if
there
is
not
a
consensus
on
what
these
glossary
terms
should
be
used
for
or
how
are
the
definitions
and
we'll
we'll
work
on
them
or
we'll
strip
them
down,
at
least
for
this
phase
to
something
that
is
agreeable,
that
makes
sense,
I
I
agree.
State
source
does
sound
in
itself.
A
It
may
be,
you
know
perhaps
like
I
would
almost
want
to
say
anyway
it
may
be
it.
It
does
call
to
mind
other
things
that
are
not
what
we're
talking
about.
You
know
like
any
database,
for
example,
or
whatever
I
know
we
clarify
that
it
must
be.
There
must
be
immutable
versions,
but
maybe
the
words,
maybe
the
wording.
C
Would
a
simplification
or
saying
the
principles
of
immutable
state
or
of
aversion,
an
immutable
state
be
an
appropriate
change,
and
then
we
only
talk
about
the
state
and
remove
the
state
story.
So
the
principle
of
versionable
and
immutable
state
desired
state
is
stored
in
a
way
that
supports
versioning,
immutability
and
retains
a
complete
version
history
period
and
we
remove
the
where
it's
supposed
to
be
stored,
because
that
is
actually
not
a
component
of
the
principle.
So.
B
So
yeah,
so
I
think
so
you're
right.
So
I
think,
like
I
introduced
the
the
idea
of
state
store
and
I'm
wondering
how
do
we
handle
this
right?
So
I
introduced
the
idea
of
state
store
because
in
order
to
do
githubs,
I
think
the
way
we
want
to
to
have
a
really
safe
way
of
doing
it.
That's
repeatable
and
reliable,
like
you,
you
need
to
put
certain
constraints
on
the
capability
or
not
really
constrain
like
minimum
requirements
on
the
capability
of
the
system.
That's
going
to
be
storing
that
state.
B
C
No-
and
I
agree
with
that,
but
what
I'm
saying
is:
isn't
that
a
more
of
a
subject
like
implementation,
rather
than
than
definition
like
we?
Yes,
so
that's!
Basically,
what
I'm
saying
I
think
how
it
is
actually
implemented
should
be
out
of
the
principle,
and
the
principle
should
only
talk
about
the
fact
that
it
should
be
immutable.
It
should
be
versionable
and
it
should
be
historically
capable
whatever
that
means
you
know,
it
should
keep
a
log
of
history,
how
it's
implemented,
whether
it's
implement
like
what?
What
mechanism
you're
going.
A
A
C
B
B
C
B
A
A
E
E
C
There
is
one
thing
that
worries
me
and
that
there
is
not
a
continuum
in
terms
of
concept,
so
we
first
talk
about
declarative
configuration
and
then
we
talk
about
immutable
version
desired
state.
So
are
we
talking
about
the
same
thing
or
is
configuration
understand,
desired
states,
something
different?
So
I
guess
that's
something
we
should
talk
about
so.
B
So
this
is,
I
think
this
is
one
of
the
things
that
you
know.
There's
a
lot
of.
There
are
a
lot
of
concepts
in
this
that
get
quite
involved,
which
is
why
I
ended
up
right
because
scott
and
I
ended
up
writing
so
much
beyond
just
those
four
principles
right
to
kind
of
flesh
out
some
of
these
ideas,
and
you
can
see
you
can
see
a
definition
of
like
an
attempt
at
defining
what
we
mean
by
desired
state
at
the
bottom
of
the
page.
B
The
aggregate
of
all
configuration
data
for
a
system
from
its
desired
state
and
the
idea
is
that
the
desired
state
is
sufficient
to
recreate
the
system,
so
that
a
new
instance
of
the
system
is
behaviorally
indistinguishable.
Right
that
tried
to
do
a
a
functional
definition
of
what
desired
state
is
in
that
it
is
sufficient
to
perform
certain
set
of
actions.
A
But
we
weren't
settled
on
this.
This
is
really
good
that
you're
we're
all
digging
into
this
together.
Yeah
configuration
was
the
best
stand-in
once
we
started
writing
desired
state
all
over
the
place,
an
actual
state
it
it
started
to
seem
excessively
wordy,
but
I
I'm
agreeing
with
you
all.
First
of
all,.
B
Do
you
think
so?
So
I
think
one
of
the
concerns.
One
of
the
reasons
we
ended
up
using
configuration
as
well
is
desired.
State
is
very
much
something
that
that
we
on
the
on
the
kind
of
on
the
github's
working
group.
We
all
kind
of
know
what
that
means,
but
external
people
who
might
come
into
this.
Do
you
think
that
terminology
is
going
to
be
clear
enough
for
them
or
do
we
need
to
do?
We
need
to
describe
what
the
desired
state
is
before
we
start
using
it,
as
in
our
definitions,.
A
Yeah
yeah,
so
so
here's
the
here's,
the
rub,
one,
what
I
was
hoping
for.
I
think
this
is
something
we
hope
many
of
us
would
would
like.
I
think
is,
but
let's
see
what
you
all
think
is
to
have
ver
a
some.
This
is
purely
a
summary
that
will
then
link
to
more,
like
canonically,
important
notes
for
each
of
these
four
principles,
and
the
idea,
though,
was
that
we
would
have
one
very
short,
easy
to
remember
way
of
describing
the
principle
that
anyone
could
just
say.
A
Oh
you
mean
the
principal
declarative
configuration
or
the
principal
declared
a
blah
blah
blah
blah
versionable.
You
know
immutable
versions,
blah
blah
blah
and
then
to
have
really
one
or
two
sentences
at
most
below
each
of
those
as
a
as
a
very
short
summary,
so
someone
coming
upon
this
for
the
first
time
can
can
read
through
and
start
to
piece
together.
A
Oh,
at
least
I
understand
what
they're
saying
but
tell
me
more
and
in
order
to
fulfill
this
principle
or
at
least
to
see
kind
of
to
what
degree
a
a
tool
or
or
or
the
maturity
ladder
of
a
of
a
company
of
a
company
or
whatever,
is
implementing
these
principles.
You
would
then
have
to
go
into
the
notes
to
really
understand
the
the
more
the
important
parts.
So
what
I
was
hoping
that
we
could
do
is
well
what
do
you
all
think
about
that
as
a
goal.
C
I
I
do
agree
with
the
goal.
I
don't
think
it's
necessarily
contradictory
to
using
desired
state
as
as
a
as
a
as
a
as
a
kind
of
like
overarching,
term
and
and
moshe's
comment.
If
you
ask
me,
I
think
it
might
be
solved
by
adding
a
couple
of
words
to
that
initial
sentence.
Right,
like
the
principle
of
the
declarative
desired
state,
a
system
managed
by
get
ups
must
have
its
aggregate
configuration
parenthesis
desired
state,
you
know,
like
add
a
couple
of
words.
Yeah.
D
C
Express
the
clarity
you
know
what
I'm
saying
just
a
couple
of
additional
words
that
hint
that
desired
state
is
the
aggregate
configuration
if
necessary,
but
I
think
users
of
this
pattern
are
are
going
to
have
to
familiarize
with
the
concept
sooner
than
later,
so
the
sooner
that
they
grasp
or
you
know
they
grok.
What
the
start
state
is
all
about.
A
It
could
be
as
granular
granular,
as
I
don't
know,
just
your
configurations
for
ingress
or
just
one
application,
and
usually
it
probably
will
start
that
way
for
a
lot
of
people,
especially
migrating
things
over
or
testing
things
out,
they're
on
a
path
to
get
ups
at
that
point,
and
they
are
you
if
they
follow
these
principles,
they'll
be
using
get
up
still,
they
don't
have
to
necessarily
have
everything
in
their
life.
You
know,
including
what
they're
going
to
eat.
A
For
you
know
breakfast
tomorrow
morning
you
know
what
I
mean
like
in
in
get
you
know
it's
it's
going
to
be.
Hopefully
we
can
use
the
the
ideas
of
progressive
delivery,
you
know
and
think
about
and
think
about
use
usership
from
a
spectrum
level
there.
You
know
what
I
mean.
So
perhaps
what
do
you
think
about
this,
perhaps
with
a
smaller
version
of
perhaps
a
smaller
initial
version
of
this
could
include
some
glossary
items
so
that
it's
all
one
thing
like,
for
instance,
someone
could
print
it
out.
You
know
what
do
you
think.
B
B
C
E
C
A
That's
right:
we
need
a
secret
hand,
signal
yeah,
the
little
g
or
whatever
anyway
can.
I
can
I
play
devil's
advocate
here
for
a
moment,
I'm
not
I'm
not
trying
to
work
against
the
goal
by
doing
so,
I
just
want
to
be
sure
about
this
one
thing
in
terms
of
style,
because
right
now
we're
just
talking
about
style
right.
A
One
of
the
nice
things
about
a
glossary
below
is
that,
while
I
said
it's
great,
I
would
like
to
be
able
to
print
this
out
on
a
poster.
It
would
also
be
nice
to
even
when
you
print
it
out
on
a
poster,
have
the
id
the
the
the
words
that
have
special
meaning
underlined.
You
know
or
or
dotted
line.
You
know
what
I'm
saying
like.
B
Be
fair,
actually,
we
use
the
desired
state
in
this
in
the
very
initial
introduction
right.
So
I
I
think
we
could
keep
the
principle
pretty
lean
by
moving
that
declaration
up
up
above
the
first
principle,
so
that
the
first
principle
is
very
digestible
while
still
introducing
the
idea
earlier,
so
that
once
we
get
to
the
first
principle,
we
kind
of
know
what
we're
talking
about.
So
I
mean
I'm
going
to
put
it
here
for
now,
but
that's
right.
B
We
can
do
some
editing
around
that,
so
that
that
keeps
the
first
principle
very
short
terth,
and
then
we
can
talk
about
it.
Just
above,
and
I
think
that
seems
like
the
best
of
both
world.
We
have
an
inline
definition
that
that
doesn't
that's
that
doesn't
front
load
the
first
principle,
either,
while
still
providing
the
context.
A
B
A
A
B
Yeah,
I
think
that
captures
the
three
core
things
right.
It
captures
the
idea
that
this
this
thing
is
versioned
captures
what
is
versioned
and
it
captures
the
idea
that
versions
can't
be
changed.
I
think
that
there's
a
kind
of
there's
a
lot.
I
think
this
is
extremely
dense
in
terms
of
kind
of
meaning,
but
it
this
captures
those
three
things
at
a
first
reading.
I
think,
if
you're
coming
into
this
as
having
not
kind
of
had
the
discussions
this
group
has
had,
this
might
not
all
kind
of
fit
in.
C
F
It
might
be
an
ideal
state
or
it
actually
might
not
be
an
ideal
state.
You
might
want
your
reconciliation
gated
by
governance
gates.
It
might
be
gated
by
tests
that
are
running
it
could
be
gated
by
deployment
policies.
That's
that
you
can
only
make
a
change
during
this
hour,
so
I
think
whether
the
fact
I
think
you
should
split
the
fact
that
we
are
doing
state
reconciliation
from
when
that
state
reconciliation
happens.
I
think
that
when.
F
B
So
I
I
I
will
I
will.
I
will
set
myself
up
as
strongly
disagreeing
not
in
that
you,
you
shouldn't,
make
a
decision
about
when
the
state
should
change,
but
that
the
commit
you
make
should
mean.
Should
the
semantics
of
making
a
change
to
the
desired
state
should
mean.
I
want
the
state,
the
state
to
change
now.
That
is
my.
I
now
change
my
intent
for
this
moment
in
time.
B
I
I
I
think
I
absolutely
agree
with
you
that
I
think
in
real
systems
and
in
real
kind
of
governance
models,
you
need
githubs
to
be
able
to
support
complex
governance
models,
but
that
doesn't
mean
you're
going
to
be
reconciling
state
asynchronously
from
the
change
in
the
desired
state.
I
really
think
that
the
desired
state
change
should
have
a
semantic
meaning
of
I
intend
my
system
to
reflect
this
as
soon
as
possible,
rather
than
I
want
to
do
this
something
in
the
future.
B
So
this
is
where
the
the
pull
request
model
comes
in
right,
like
you
have
a
you,
have
another
way
of
proposing
a
set
of
changes
and
validating
that
set
of
changes
before
it
gets
applied
to
your
to
your
main
branch.
Oh
sorry,
I'm
hiding
the
camera
before
he
gets
applied
to
your
main
branch,
but
once
it
gets
applied
to
your
main
branch,
that
application
has
the
meaning
of
immediate
immediacy,
and
that
is
continuous.
There's
a
continuous
loop.
That's
going
on
that
reconcile
those
two
things.
F
F
A
A
A
B
So
the
operational
issue
here-
and
this
is
this-
is
one
of
the
things.
This
is
why
I,
I
think
we
we
both.
We
both
agree,
what
we're
talking
about
and
what
what
I
think
is
really
important
from
an
operations.
Point
of
view
is
that
what
you
have
in
your
gate,
repository
at
the
head
of
your
main
branch,
is
what
should
be
there
in
your
system
right
now,
when
you
see
it,
and
that
should
always
be
true
now
the
system
might
drift,
because
you
know
we're
in
the
real
world,
but.
B
Go
into
your
main
branch,
read
a
configuration
and
then
not
have
the
system
like
the
intended.
The
intended
in
intended
state
of
this
should
be.
What's
in
your
that
main
branch
it
shouldn't
be.
I
intend
my
system
to
be
like
that
at
some
point
in
the
future,
because
then
you're
not
able
as
an
operator
to
go
in
and
make
that
comparison
right
and
even
the
tools
are
not
able
to
make
that
comparison.
B
F
C
F
F
F
It
is
the
desired
state
and
there's
a
reconciliation
loop
and
there
there
is
an
open
issue
or
an
open
unsolved
problem
of
how
do
I
take
my
actual
running
state
and
and
reflect
that
back
into
git,
so
that,
as
an
operator,
I
know
that
this
this
desired
state
was
actually
unsuccessful,
or
this
state
hasn't
actually
been
applied
yet
or
there's
no
drift
that's
occurred.
So
I
think
that's
a
distinct
problem,
but
your
intention
is
always
going
to
be
intention.
It's
never
going
to
be
effect,
and
this
right.
B
That's
that's
what
I
mean
right
like
if
you
have,
if
you
allow,
for,
if,
if
you
allow
for
your
the
you
know
the
head
of
your
main
branch,
to
not
reflect
your
intention
right
now,
then
you
you
have
problems
right.
You
have
problem
because
you
don't
you
can't
make
decisions
about
what
your
intentions
are
so
you're,
not
even
able
to
distinguish
between
a
system
that
meets
your
intentions
and
one
that
does
not.
You
lose
that
link.
Sorry.
A
H
No,
no,
no,
no
problem.
I
think
this
is
an
important
conversation
and
I
think
these
there's
two
distinct
things.
So
I
I'm
gonna
sound
like
I'm
gonna,
I'm
speaking
from
both
sides
of
my
mouth,
so
bear
with
me.
So
there
is
so
there
is
the
the
fact
that,
where
I
make
a
change,
I
make
a
pr
it
gets
merged
right.
H
H
However
yeah,
however
comma
there's
the
other
side
of
it
right
where
it's
like.
Well,
if
there
is
a
change
like
if
someone
did
a
cube,
ctl
patch
right
of
a
deployment,
I'm
gonna
use
a
simple
example
that
fundamentally
changes
the
behavior
of
the
application.
I
want
it
to
be
automatically
and
continuously
monitored
and
changed
back
to
what
my
desired
state
is.
So
I
think
we
need
to
define
what
we're
talking
about.
You
know
delivering
a
change
versus
observing.
H
What's
you
know
what
what's
going
on
and
and
reconciling
that
in
in
in
the
cluster?
So
I
think
if
we
define
what
we're
talking
about
number
three
it'll
be
maybe
a
lot
easier
to
come
up
with
a
definition,
because
there's
there's
two
scenarios,
though
right
so
I'm
essentially
so
I'm
leaning
towards
what
bryce
is
bryce
is
saying
and
agreeing
with
bryce
is
saying,
but
I
do,
but
I
do
hear
what
moshi
is
saying
that
you
know
when,
when
I
make
a
change
in
my
ci
system,
you
know
how
that
gets
delivered.
B
It's
worth,
I
think,
it's
worth
probably
stepping
back
and
like
having
a
look
at
what
we,
what
I,
what
I
intended
to
exclude
when
we
were
writing
that
with
scott
and
the
idea
here
is
to
deliberately
and
explicitly
exclude
event
driven.
You
know
traditional
see,
event
driven
git
pipelines
right.
That's
that's
what
we
wanted
to
exclude
explicitly
exclude
from
our
definition
of
githubs.
B
We
we
should
be
exp
because
a
lot
of
people,
I
think,
are
saying
we
do
githubs
and
what
they
really
mean
is
we
have
jenkins
that
pays
attention
to
a
gate
repository
and
when
the
gate
repository
changes.
Jenkins
runs
a
bunch
of
code
to
move
up
to
move
our
systems
to
whatever's
in
git
that
isn't
githubs
right
that
that
that
loses
a
really
important
feedback
mechanism.
B
So
I
think
that's
that's.
What
I'm
trying
to
capture
with
the
principle
three
is
that
I
want
to
exclude
event
driven
and
be
very
deliberate
about
being
reconciliation
driven,
and
I
think
that
I-
and
I
think
everybody
here
agrees
with
that-
those
ideas,
so
maybe
there's
a
better
way
of
describing
this
about
being
reconciliation-driven.
F
A
B
C
Just
a
comment
because
I
have
my
hand
raised
as
well:
I'm
gonna,
I
think
the
objective
here
is
to
remove
as
much
as
so.
Basically
I
think
what
we're
the
exercise
that
we're
trying
to
do
here
is
reduce
to
the
lead
to
the
to
the
common
denominators
of
agreement
right.
So
my
I
I
vote
for
any
word
that
is
controversial,
which
is
a
get
rid
of
it.
You
move
it
elsewhere,
so
I
would
reduce
it
to
its
minimum
possible
form
of
agreement
and
I
think
state
reconciliation.
C
A
Okay,
I'm
going
to
call
on
myself
because
I
had
my
hand
raised
before
the
last
several
people-
that's
totally
okay,
I
and
I'm
gonna
do
my
best
to
do
this,
just
to
help
moderate
not
to
try
to
strong-arm
anything,
but
I'm
also
participating
a
bit
and
I'll
keep
mine
under
a
minute.
I
promise
what
I'm
hearing
is
so
far.
I
haven't
heard
one
person
have
a
concern
about
cont
the
word
continuous
in
itself
at
first
I
at
first
it
sounded
that
way.
A
G
G
A
I'm
almost
done
with
my
one
minute
I
will
that
was.
That
was
a
question
about
whether
that
would
help,
but
it
sounds
like
it
is
in
fact
controversial.
I'm
not
going
to
debate
it
now.
How
about
we
just
put
that
in
the
notes
for
ourselves
and
move
on.
So
everyone
seems
to
agree
that
this
last
paragraph
should
be
in
the
notes
right.
A
E
A
I
mean
I
I
I
definitely
don't
feel
like
it's
quite
enough
to
to
differentiate
it
from
normal
ci,
but
so,
if,
if
there
is
a
concern
about
continuous,
then
I
mean
we
can
remove
that,
but
I
I
definitely
want
to
sidebar.
That
is
something
to
loop
back
to,
because
just
personally,
because
I
believe
that
basically,
this
is
the
part
that
I
agree
with
of
what
you
said
breeze.
A
E
And
I
I
think
the
the
original
the
title
here
kind
of
suggests
more
of
a
I.
I
agree
that
if
you,
if
you,
if
you
commit
something
in
to
get
and
then
something
triggers
that
and
and
and
and
makes
that
the
current
state
of
the
system,
I
agree
that
if
someone
does
anything
manually,
it
should
correct
itself,
because
that
is
what
we're
trying
to
do
with
get
ups
right.
E
C
I'll
show
that
just
just
a
quick
comment
for
me,
I
just
to
make
sure
that
that
I'm
clear
I
actually
do
agree
with
brits.
I
do
think
it
should
be
continuous
and
I
think
it
should
be
automated,
but
I
think
the
exercise
that
we're
going
through
the
purpose
of
this
meeting
is
not
to
get
to
the
level
of
detail
where
we
are
absolutely
certain
that
the
principles
are
like
reflections
of
the
ideal
scenario
of
what
we're
going
for
right.
We
are
trying
to
identify
the
the
minimum
viable
product
right,
like
the
the
the
mvp
representation.
F
F
B
A
B
So
yeah,
I
think
I
think
I
get
where
you're
coming
from.
Actually
it's
a
case
of,
it's
not
instantaneous,
I
think,
there's
a
difference
between
continuous
and
loops,
which
I
for
me
are
kind
of
similar
ideas
to
instantaneous,
and
I
I
would
absolutely
agree
that
nothing
can
be
instantaneous
and
there's
going
to
be
lag
in
that
loop.
B
So
I
I
agree
right
and
I
I
also
agree
that
the
idea
immediately
implies
simultaneous
you
know
and-
and
that's
that's
not
physically
possible
right.
These
are
distributed
system.
We're
talking
about.
That's,
never
going
to
be
immediate.
We
can't
do
that,
so
I
think
being
more
subtle
about.
It
is
probably
warranted,
although,
like
I
I
I
see
where
you're
coming
from
I'm
starting
to
understand,
where
you're
coming
from
actually
and
why
that's
a
problem?
Why
you,
you
think,
does
that
that
doesn't
capture
the
idea
correctly.
B
So
so
the
question
is:
if
we,
how
can
we
capture
the
the
kind
of
the
reconciliation
loop
without
implying
immediacy
or
simultaneous
action,
and
so
I
think
whether
we
you
know
principle
of
state,
reconciliation
or
state
reconciliation
loop
is
fine.
I
don't
have
a
very
strong
opinion
about
that,
but,
like
I,
I
definitely
want
to
capture
the
essence
of
what
we're
talking
about
in
the
description
and
kind
of
the
short
summary
afterwards.
B
A
F
Understand
no,
so
it's
not
my
definition,
so
this
is
in
in
systems
theory
when
you
have
a
reconciliation,
loop
and
a
ped
loop
and
all
of
these
types
of
loops,
they're,
very
specific
in
meaning
to
in
distributed
systems,
and
the
loop
always
has
a
feedback
mechanism
into
it.
If
it
doesn't
it's
an
open
loop
and
if.
F
F
But
a
closed
loop
and
an
open
loop
in
systems
theory
are
very,
very
specific
and
almost
all
get
ups.
Implementations
are
not
closed,
loops
or
open
loops
because
a
closed
loop.
It
means
that
you
have
feedback
back
into
the
system,
which
means
that
you
can
see
on
your
get
head
whether
that
change
has
been
applied
or
not,
and
more
often
than
not.
You
cannot
see
whether
that
change
was
successful,
which
means
it's
an
open
loop
and
your
system
is
just
going
to
reapply
that
change
reapply
that
change.
We
apply
that
change.
F
A
F
A
E
C
B
B
A
A
A
One
thing
we
did
was
we
moved
that
last
sentence
into
notes
below,
and
that
was
fantastic.
Unfortunately,
we
don't
have
time
to
get
into
principle
four
and
respect
everyone's
time,
so,
but
we
we
should
do
this
weekly
and
in
the
end
there
will
be
a
pull
request
for
this
too.
So
even
people
who
couldn't
be
on
this
call
like,
for
instance,
if
you're
watching
from
home
this
video,
the
spirited
debate,
you
did
not
miss
the
boat.
You
can
still
comment
on
the
pull
request.
A
B
A
A
B
So
what
I
I
I
like
recurring
meetings,
one
of
the
issues
is
some
of
the
people
might
be
in
different
time
zones
and
not
able
to
participate
at
this
particular
time.
If
it
turns
out
that
next
week,
at
the
same
time
is
perfect
for
everybody,
then
it
would
probably
just
end
up
recurring,
but
I
think
it
might
be
a
little
bit
better
to
just
double
check
that
we
don't
have
people
who
just
can't
attend
this
time
and
would
be
excluded
out
of
it.
A
That
would
be
great
and
and
also
mosh.
Well,
I
understand
what
you're
saying
there
was
also
from.
There
was
also
from
someone
else
a
note
to
please,
if
possible,
not
do
it
on
a
on
the
sabbath,
so
so
to
not
exclude
people
from
specific
religious
backgrounds.
So
if
anyone
has
anything
like
that,
we
can,
we
can
also
try
to
narrow
down
the
time
options.