►
From YouTube: GitOps Principles Committee - April 14, 2021
Description
Meeting notes: https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit#heading=h.7wmerton06if
B
B
A
C
C
C
C
C
B
C
Thanks,
leonardo,
yes,
and
also-
and
I
see
your
hand,
motion
but
just
real
quick
in
terms
of
like
rounding
out
the
housekeeping-
is
that
we
also
limited
responses
to
two
minutes
just
because
we
only
have
so
much
time,
but
you
can
keep
doing
it.
So
does
that
sound?
Okay
to
everybody,
okay,
cool,
all
right.
G
Yes,
so
I'm
still
in
very
strong
disagreement
about
continuous
continuous
implies
without
interruption,
or
it
actually
is
defined
as
without
interruption
and
using
change,
windows
and
change
freezes.
This
makes
almost
half
or
more
of
the
get
ups
market
obsolete
and
not
compatible
with
this
definition.
So
I
strongly
disagree
with
this.
The
principle
of
state
reconciliation,
yes,
but
not
continuous
state
reconciliation
that
that
is.
D
H
G
G
So
if
I
log
an
incident
onto
a
system,
none
of
the
github
systems
will
do
this
today,
but
you
should
stop
all
deployments
if,
if,
if
you
are
have
an
instant
and
only
allow
deployments
through
that
are
that
are
not
not
at
all
for
fixing
the
incident
so
continuous,
it
puts
a
lot
of
constraints
and
restrictions
on
the
definition
of
get
ops,
and
I
don't
think
it's
it's
applicable
here.
You
can
choose
to
make
your
your
get
up
system
continuous,
but
it
should
be
a
choice,
not
an
enforced
action.
D
I
I
J
I'm
I
I
work
very
much
with
enterprises
and
I'm
very
familiar
with
the
whole
concept
of
change
freezes.
It
happens
to
be
what
most
of
my
customers
deal
with,
and
I
definitely
feel
that
argo
cd
and
get
ops
falls
into
this
paradigm
because
you
would
apply
the
changes
that
would
be
continuously
enforced
during
this
change
freeze.
So
you
would,
you
know,
point
to
a
specific
branch.
J
You
do
a
commit
that
were
merged
to
a
branch
that
was
targeted
by
your
get
ops
tool,
but
that
change
occurs
during
the
freeze,
because,
ideally
there
won't
be
any
other
changes
that
occur
outside
of
that
freeze.
If
there
is,
that
would
be
a
a
break
in
the
desired
state
and
then
kind
of
go
against
the
principles
of
the
change.
Freeze,
no
other
means
should
occur,
it's
just
enforcing
it
on
a
consistent,
consistent
basis.
Thanks.
C
J
G
So
so
I
I
agree
that
that
is
probably
a
better
approach
for
freezing
and
change
windows,
but
it's
not
the
only
approach
so
I'll
go
see.
Cd
specifically
has
a
feature
that
will
allow
you
to
push
to
a
master
or
main
branch
outside
of
a
chat,
a
freeze
window
and
then
only
have
that
merge
commit
deploy
inside
the
change
window.
So
I
agree
it
should
be
handled
at
a
but
but
the
difference
is
should
this
be
handled
at
a
at
when
we
actually
make
the
merge
must
is
the
difference.
I
agree.
D
So
I'll
follow
striton
and
I'll
jump
back.
So
I
think
we're
not
here
saying
that
github
says
the
only
way
number
one
right.
I
think
it
is
a
way
and
it's
a
strongly
opinionated
way,
and
I
think
it's
okay
to
position
ourselves
in
saying.
Well,
actually
what
we
mean
is,
it
must
be
continuous
and
if
that
excludes
certain
modes
of
operation
for
argo
cd.
Well,
that's!
Okay!
Argo
cd
has
other
modes
of
operation.
D
This
github
doesn't
reject
a
tool
because
it
supports
multiple
modes
of
operations
that
that's
not
that's,
not
what
we
say
just
like,
for
example,
and
I
I've
made
the
point
before
git
itself
is
on-
will
only
comply
with
githubs.
If
it's
configured
in
a
very
particular
way
right,
you
need
protected
master
branch.
You
need
a
bunch
of
other
things.
You
need
access,
there's
a
whole
list
of
things
that
you
need
to
do
with
git
itself,
to
make
it
kind
of
get
ups
to
to
agree
with
the
git
those
principle.
So
that's
that's
number.
D
One
number
two
is
really.
I
think
that
I
second
the
point
that's
been
made
by.
I
think
it's
ben
about
the
idea
that
these
declarations
should
the
freeze
window
is
a
declaration
right,
you're
declaring
something,
and
I
will
follow
that
with
a
question.
If
you
change
your
main
branch,
whilst
there
is
a
freeze
active,
where
is
the
state
of
your
system
now
stored?
Do
you
lose
that
information
right
you've
got
a
freeze,
active
between,
say,
I
don't
know
nine
o'clock
in
the
morning
to
six
o'clock
at
night.
D
Somebody
makes
a
commit
to
maine
during
that
time.
What
is
the
desired
state
of
your
system?
At
that
point?
Is
it
the
head
of
maine?
No,
because
we've
got
to
freeze
on
so
I
think
it's
much
better
to
reconcile
those
and
and
maybe
have
an
explicit
note
about
change
change.
Freeze,
because
I
agree
it's
a
very
common
use
case
right
for
very
good
reasons
too.
D
It's
not
just
like
an
arbitrary
issue,
so
maybe
it's
worth
making
an
explicit
note
about
how
githubs
would
view
a
change
freeze
and
make
that
explicit,
say
the
way
we
envisage
a
change
freeze
occurring
within
github
is
to
prevent
between
certain
times
any
change
to
the
master
branch.
I
think
that
that
is
an
opinion
that
would
be-
and
I
think
I
think
you
mentioned
it
earlier-
moshe-
that
it's
a
like.
It
should
be
like
that
right,
that's
what
we'd
want
and
as
far
as
incidents
are
concerned,
I
I
will.
D
I
will
note
here
before
I
shut
up
for
for
everybody
else.
I
will
note
that
I've
personally
been
in
incident
critical
incident
response
right,
we've
taken
down,
I
mean
I
don't
know
whether
anybody
here
is
is
part
of
key
dot
io,
but
we've
had
a
bunch
of
serious
incidents,
weaveworks
that
we've
had
to
deal
with
both
for
ourselves
and
customers,
and
almost
all
of
our
operations
were
done
through
githubs.
That
means
the
incident
response
itself
took
the
form
of
a
commit
to
our
main
branch
that
the
incident
team
was
was
putting
together.
B
So
just
like,
I
think
I
agree
with
a
lot
of
what
rich
just
shared
and
my
opinion
is
that
the
once
once
you've
once
you
choose
to
freeze
deployments,
that
represents
your
current
state
right,
you're
saying
my
state
right
now.
As
far
as
my
system
is
concerned,
is
I
will
not
merge,
I
will
not
allow
for
merging
other
changes,
and
matter
of
fact
is.
I
think
there
is
a
there
is
a.
B
There
is
a
difference
between
the
integration
of
new
changes
in
the
deployment
of
the
changes.
When
you're
saying
I'm
going
to
freeze
my
process,
you're
saying
I'm
not
going
to
integrate
new
changes,
I'm
not
going
to
merge
new
code,
and
this
is
a
protection
that
you
would
establish
in
your
integration
process
in
your
integration
pipeline.
Where
does
that
live?
It
would
live
in
your
different
branches,
feature
branches
that
you're
you're
still
not
merging
and
you're
open
prs.
B
What
you're
saying
is
at
this
point,
I'm
not
going
to
integrate
any
more
changes
into
my,
but
the
fact
that
you
are
freezing
any
changes,
perhaps
is
even
outside
of
the
context
of
the
delivery
of
those
changes.
What
you're
saying
is
I
don't
want
to
allow
new
changes
to
go
in,
but
whatever
is
in
maine
should
be
continuously
reflected
in
the
state
of
my
target
system.
If
I
don't,
if
I
want
to
freeze,
I
establish
it
at
integration,
not
deployment.
B
If
it
got
to
maine,
it's
got
to
be
continuously
synchronized
and
the
state
of
freezing
merges,
for
instance,
if
it's
a
component
of
your
githubs
operated
platform,
it
should
also
be
declarative
and
it's
a
component.
It's
an
attribute
of
your
current
state
is
an
attribute
of
your
desired
state.
So
I
don't
think
it's
I
guess
the
bottom
line
is,
I
think
we
can
be
this
opinionated.
B
I
think
protecting
for
changes
happens
in
integration
and
not
delivery,
and
it
is
a
it
is
an
ideal
of
git
ups
and
I'm
not
going
to
say
ideal
because
it
sounds
idealistic.
It
is
the
pattern
that
we're
promoting
for
getups
to
be
continuously
synchronizing,
whatever
is
in
main
and
there's
alternative
integration
related
means
to
protect
that
from
happening.
If
there's
a
freeze,
that
was
it.
Thank
you.
C
Yes,
I
raised
my
hand,
but
I
waited
till
the
end.
Okay
yeah,
so
so,
just
in
short,
two
things.
One
is
I'm
concerned
that
we
may
be
taking
or
or
that
this
can
that
this
issue
that
is
raised,
maybe
taking
the
word
continuous,
the
dictionary
definition
of
continuous,
too
literally,
or
rather
taking
it
out
of
context
of
all
the
other
ways
that
this
is
used.
C
For
example,
do
you
also
would
this
also
essentially
say
that
the
the
entirety
of
continuous
delivery
is
just
is
an
incorrect
terminology
in
itself
and
that
we
should
differentiate
ourselves
100
from
anything
related
to
continuous
delivery,
because
it
uses
the
word
continuous?
I
would
propose
that
that
not
be
the
case.
My
the
the
only
other
thing
I
wanted
to
mention
in
this
context
is
that
I
had
initially
thought
you
know.
C
I
don't
know
if
this
might
be
agreeable,
but
I
initially
thought
that
when
I
describe
gitops
to
people,
I
almost
always
say
something
very
similar
to
this,
that
you
know
if
the
actual
and
desired
states
differ.
For
any
reason,
automated
actions
to
reconcile
them
are
initiated
right,
but
I
almost
always
append
that
with.
According
to
your
configured
rules-
and
I
didn't
recommend
saying
that
in
these
principles,
because
I
didn't
you
know-
trying
not
to
be
unnecessarily
detailed
but
but
mosh,
because
you
are
raising
the
one
raising
this
concern
or
this
this
question.
G
C
Can
there
there
is
some
part
of
the
system
that
is
continuous,
it
doesn't
necessarily
mean
it
has
to
a
specific
action
has
to
be
happening
continuously
for
continuous
reconciliation
to
happen.
It
should
just
simply
be
continuously
checking
continuously,
comparing
against
your
rules
and
and
in
the
desired
state,
but.
G
Yeah,
but
that's
not,
but
that's
not
what
the
principle
says:
the
principles
is
very
clear:
continuous
state
reconciliation
there's
a
continuous
loop
there.
So
that's
that's
point
one,
but
I
think
really.
The
bigger
picture
here
is
a
lot
of
what
everybody
is
saying
makes
a
whole
lot
of
sense,
and
I'm
definitely
agree
that
that
you
should
be
be
doing
this
type
of
declarative
state
in
git
and
and
blocking
mergers
based
on
a
fridge,
and
I
I
definitely
agree
with
that.
That
is
definitely
for
me.
G
It
should
have,
but
I
think
where
a
lot
of
this
is
missing.
The
point
is
we're
thinking
about
this.
As
get
ups
as
a
single
repository
on
my
single
repository,
I'm
going
to
always
apply
men
into
my
environment
and
I
and
I'm
going
to
prevent
everything
going
into
maine,
but
I
think
that
does
not
really
reflect
the
challenges
of
get
ups
today
when
you
want
to
scale
this.
So
how
do
I
handle
100,
git
repos,
and
how
do
I
handle
a
platform
team
that
is
now
responsible
for
getting
those
get
repos
into
production?
G
So
now
am
I
enforcing
my
change
control
policies
into
my
100
git
repos.
Where
am
I
enforcing
those
change,
control
policies
inside
the
system
and
and
and
deploying
it
out
at
that
level,
and
I
think
that
that
should
really
be
a
choice
it
shouldn't
be.
You
must
use,
you
must
use
an
integration
test
and
have
make
sure
that
that
integration
test
is
working
on
every
single
branch
and
nobody
is
actually
overriding
that
check.
That's
that's
a
very
difficult
to
ask
to
to
prevent
those
chicks
from
writing.
It's
definitely
ideal.
G
G
Gentle
time
reminder
motion
yeah,
I'm
moving
quickly
so
from
the
first
thing
is
that
if
you
are
always
deploying
from
maine
you
that
isn't
a
reflection
of
your
actual
state,
that's
a
reflection
of
your
desired
state,
so
that
deployment
can
fail.
And
today,
when
you
look
at
a
git
repository,
unless
you
have
a
pipeline,
that's
running
as
a
github
action,
you
will
not
know
it.
So
we're
not
reflecting
the
state
of
the
the
get
repository
back
into
the
git
repository
so
get.
G
Ops
today
is
a
open
loop
and
I
think
that's
one
of
the
the
unsolved
problems
and
it's
not
an
unsolved
problem.
There
are
ways
to
solve
it,
but
people
are
not
solving
it
that
that
I
can
commit
to
man,
and
I
actually
have
no
idea
unless
I
have
some
feedback
mechanism
that
I
built
externally.
That
says
that
I've
committed
to
maine,
but
that
that
deployment
actually
failed
or
that
deployment
hasn't
actually
gone
through,
because
there's
a
change
phrase,
and
only
once
that
transference
goes
through.
G
E
You
are
next,
so
I'm
just
kind
of
noodling
on
this,
this
idea
of
a
freeze
and
also
like
the
idea
of
a
roll
out
or
things
that
continuously
take
place.
So,
for
example,
if
I
have
as
my
desired
policy
that
when
we
make
a
change,
we
do
it
as
a
canary
release
and
that
canary
release
canary
releases
by
definition
are
going
to
take
some
period
of
time
right
and
what,
if
it
takes
24
hours
for
a
canary
release
to
occur
so
you'd
have
a
24-hour
period
during
which
a
canary
was
happening.
E
E
This
creates
problems,
and
so
you
know
what
you
end
up
usually
doing.
Is
you
kind
of
have
a
canary
that's
taking
place
once
it's
burned
through
you
kind
of
fast
forward
to
the
latest,
and
then
you
begin
the
canary
again,
and
that
way
you
know,
changes
might
stack
up.
So
I'm
wondering
if,
in
this
scenario,
that
is
essentially
a
floating
period
that
is
just
attached
to
the
release
process,
now
the
the
release
process
is
stated
within
git
and
it's
following
the
policy.
E
That's
that's
declared,
even
though
the
policy
declares
that
maybe
some
of
these
versions
will
be
skipped
in
the
deployment,
because
we'll
do
a
fast
forward
to
the
latest
version,
because
changes
are
just
happening
rapidly
enough.
I
it's
hard
for
me
to
think
about
that
process
and
not
think
that
it's
continuous
that
sounds
continuous,
even
though
we're
not
overstepping
changes.
Does
that
sound
like
a
dramatically
different
scenario
in
your
mind,
moshi
or
is
that?
Does
that
make
sense.
G
So
that
that
makes
sense-
and
for
me
I
don't
think
that
is
continuous,
because
you're
going
to
have,
must
you're
going
to
have
points
where
you
have
undeployed
head
releases.
So
I'm
gonna
go
from
one
and
then
weight
three
three
mains
and
then
go
to
the
fourth.
So
I'm
not
continuously
deploying
numbers,
two
three
and
four,
so
I'm
stacking
them
up
so
like
stacking
up
for
me
is
not
continuous.
G
Yes,
so
what
I'm
saying
is
continuous
means,
I
make
a
commit
to
domain
or
master,
and
my
expectation
is
that
that
thing
now
applies
in
production
and
then,
if
the
the
next
commit
to
master
happens,
that's
that
exact
same
thing,
overwrites.
What
I
just
did
and
applies
it
into
production
immediately
and,
like
you,
can't
have
these
gaps,
so
it
continues.
There's
no
gaps,
it's
defined
as
without
interruption
or
gaps.
G
C
Can
I
propose
that
we
move
this?
I
I'm.
I
think
that
we're
not
making
any
ground
here
please
to
everyone
on
the
call
tell
me
if
I'm
wrong,
but
I
believe
we're
not
making
any
ground
beyond
mosh
disagrees.
Let
me
just
please
tell
me
mosh
if
I'm
summarizing
correctly,
you
disagree
that
the
word
continuous
period,
whether
it's
industry,
standard
in
this
area
or
not
means
a
very
specific
thing
and
so
far
no
one
else
agrees
with
that.
E
D
Couple
of
things
that
dan
said
that
like
came
up-
and
I
took
some
notes
like
canary
so
the
the
the
state
of
your
your
your
system-
should
be
declared
canary
release
that
you're
describing
are
canary
releases
where
the
state
of
the
system
isn't
declared
anywhere.
That's
not
git
ops,
a
proper,
get
up
scenario,
release
the
agent
that
makes
decisions
about
how
traffic
is
rooted
would
make
a
commit
to
your
state
store
right
that
would
feed
back
into
your
state
store
it,
wouldn't
so,
let's
say
you're
moving.
D
You
know,
10
of
your
traffic
to
the
new
version
you
would
make
the
agent
would
make
a
commit
to
your
state,
store
and
say:
10
of
my
traffic
is
now
going.
It
wouldn't
affect
the
system
directly
you'd.
Let
the
reconcilers
reconcile
that
the
agent
would
observe
the
system
and
make
a
decision
to
move
that
to
20,
eventually
moving
all
the
traffic
to
your
new
version.
You
wouldn't
have
that
kind
of
hanging
state.
That's
actually
in
your
in
your
cluster.
In
this
case
right,
you
wouldn't
be
the
the
state
store,
wouldn't
be
the
cluster.
D
You
declare
the
process
of
doing
the
the
canary
release
and
in
this
way
you
can
do
any
number
of
canary
release
simultaneously,
because
at
any
point
in
time
you
know
exactly
how
much
of
your
traffic
is
going
where
and
why,
because
that's
all
declared
in
the
rules
right
so
and
like,
for
example,
flagger,
which
is
like
a
tool
that
does
continuous
release
right
now,
doesn't
do
that
right.
It
doesn't
do
that
it
takes
care
of
the
traffic
shaping
in
cluster
without
feeding
the
state
back
to
the
state
store.
D
I
don't
think
that's,
and
this
is
kind
of
the
second
point
I
want
to
make
right
like
we.
We
we
started
now
with
the
idea
that
github
is
a
set
of
kind
of
directional
ideals,
but
it's
pragmatic
we're
not
we're
not
trying
to
say
like
we're,
not
trying
to
draw
a
box
we're
trying
to
point
an
arrow
somewhere.
D
So
the
fact
that-
and
I
don't
think
flagger
should
work
differently
right.
Flagger
is
very
successful
at
doing
what
it
does,
for
example,
but
that
doesn't
mean
it's
it.
It
implements
all
the
principles
to
their
full
extent
and
I
don't
think
we
should
have
that
as
a
as
a
criteria
either
right
like
those
are
principles
that
can
be
implemented
and
pragmatically,
depending
on
your
use
case.
D
Is
a
hundred
percent
correct,
so
it's
perfectly
reasonable
to
have
the
platform
team
trigger
a
platform
freeze
in
the
middle
of
an
incident
right.
If
there's
a
platform
level
incident,
the
platform
team
can
switch
on
so
that
that
doesn't
mean
those
things
are
wrong.
It
just
means
that
if
we
can,
we
should
manage
those
changes
and
should
manage
all
of
this
in
a
declarative
way.
D
H
H
If
you
are
doing
things
after
something,
if
you're,
if
you're
doing
something
in
the
middle
of
that
cd
pipeline
you're
kind
of
injecting
some
sort
of
a
logic
or
a
change
into
what
the
middle,
the
in
the
middle
of
the
system,
which
may
may
be
an
anti-pattern
and
so
I've
been
trying
to
think
like
what
would
happen
if
we
do
remove
the
continuous
and
would
that?
Actually
I
I
worry
that,
then
we
start
to
kind
of
break
down
the
other
principles.
H
Because
now,
if
I've
declared
something,
how
do
I
know
whether
or
when
that
change
is
going
to
be
applied?
Have
I
truly
then
externalized
the
state
of
the
cluster
or
have
I
just
lined
up?
You
know
a
regular
cd
pipeline
in
the
front
of
the
cluster,
and
so
I
think
that
I'm
not
probably
at
this
point,
because
I've
waited
so
long
and
listened
by,
probably
not
saying
anything
unique
that
no
one
has
said
already
in
the
conversation.
H
But
I
just
think
it's
an
it's
an
important
way
to
think
about
it,
and
I
think
it
doesn't
invalidate
cd
pipeline
approaches
to
declaring
the
state
of
a
kubernetes
cluster
like
you.
Can
have
other
approaches
that,
are
you
know,
delivery
pipelines
into
the
cluster,
and
I
think
we
just
have
to
decide
like
is:
are
those
approaches
still
get
offs?
Are
we
still
prop
fully
externalizing
the
state
of
the
cluster
into
a
git
repo?
H
For
example,
we
should
like
hold
off
commits
from
being
merged
into
the
repo
if
we
do
have
a
production
incident,
because
otherwise,
like
that's,
that's
where
we
actually
would
make
the
the
freeze
versus
freezing
it
kind
of
in
the
middle
of
the
of
the
of
the
system,
so
yeah
just
kind
of
following
up
on
things.
I've
been
really
trying
to
approach
this
from
the
other
angle,
and
I
think
that
if
we,
my
my
opinion,
is
that
if
we
hold
a
continuous
out,
then
we
actually
lose
what
makes
get
ops
get
ups.
I
I
So
I
strongly
differentiate
between
analyzing
deciding
and
eventually
taking
an
action,
and
for
me
the
continuous
part
is
at
least
in
the
analyzing
and
deciding
kind
of
pillars
of
these
three
things,
and
then
the
decision
can
always
be
well
now.
The
desired
state
is
not
to
act,
but
that's
already
the
I
already
had
my
continuously
evaluating
and
deciding.
If
I
should
act,
part
done
and
then
the
decision
is
well.
I
I
Otherwise,
it's
an
out-of-band
management
and
I
think
that
out-of-band
management
will
be
implemented
in
every
system,
but
it's
more
for
emergencies,
for
breaking
the
glass
special
handling
whatever,
and
I
think
with
the
github
principles.
We
should
rather
focus
on
describing
the
99.99
of
normal
operations
and
not
the
extremely
seldom
case
of
emergency
operations.
I
C
G
What
for
me
is
the
essence
and
that
state
reconciliation
loop
is
something
that
runs
all
the
time.
But
what
happens
inside
that
loop
and
and
what
decisions
are
made,
that
we
will
never
ever
be
able
to
declare
the
entire
state
of
the
system
you
get.
It's
just
not
feasible,
it's
impossible,
because
it
by
by
the
mere
fact
that
you've
changed.
G
C
D
D
I'm
not
necessarily
strongly
opinionated,
even
though
I'm
the
one
who
put
it
there
in
the
first
place,
I'm
not
necessarily
strongly
opinionated.
What
I
really
want
to
do
is
try
and
separate
githubs
from
ciops
and
from
event
driven
operations.
If
that
makes
sense,
that
is
you
trigger
an
event.
Something
takes
an
action
and
then
you
stop
and
there's
no
you're,
not
you're,
not
checking
all
the
time
that
the
state
matches
what
you're
you've
defined
in
your
event
right.
So
the
ci
ops,
really
I
the
distinction
of
principle
4.
Is
this?
D
How
do
we
do
that
like?
How
would
we
phrase
it?
Let's,
let's
let's,
let's
for
the
sake
of
argument
right,
let's
remove
continuous,
because
it
seems
to
to
cause
issues
and-
and
I
kind
of
agree
about
the
simultaneity
right-
nothing
can
be
simultaneous
fundamentally,
so
it's
not
going
to
be
immediate.
I
don't
think
I
think
that's
to.
D
We
need
to
rip
immediacy
and
continue
like
and
the
loop
separately,
and
I
think
continuous
and
lube
kind
of
capture
the
similar
ideas
but
like
how
do
we
make
sure
that,
for
everybody,
who's
going
to
read
this?
This
is
a
clear
like
it's
a
really
clear
cut
between
githubs
and
ciops
right,
that's
the
first
one.
I
don't
know
how
to
do
that.
D
D
We
still
have
ui
that
pokes
a
database
for
things
that
should
be
declared
in
git
in
products
that
we've
said
we
sell
right,
and
so
it's
more
about
an
aspirational
direction,
not
necessarily
what
we
do
right
now
and-
and
I
will
be
the
first
one
to
to
point
out
the
many
many
flaws
in
the
software
I've
contributed
to
in
the
way
it
doesn't
meet.
Some
of
these
principles
right
and
the
the
last
bit
is.
D
I
think
it
would
be
incredibly
valuable
to
have
a
write-up
separately
from
this
of
github's
incident
management,
and
this
is
kind
of
an
open
invitation
to
try
and
write
something
about
github's
incident
management
as
a
blog
post,
or
something
like
that,
because
I
think
that
would
be
an
extremely
valuable
piece
of
content
for
the
community.
That's
it.
I'm
done.
J
C
D
So
maybe
one
thing
that
we
could
do
quickly
is
just
list
those
use
cases
because
they
sound
like
actually
every
single
use
case
we've
talked
about
so
far
has
proven
to
be
a
really
good
area
of
kind
of
a
case
study
for
people
to
understand,
githubs
and
to
understand
kind
of
what
we
mean.
So
I
mean
we
talked
about
code
freezes
and
the
github's
way
of
doing
code
freezes.
We
talked
about
incident
management
and
the
github
way
of
doing
that
and
github's
canary
releases.
D
So
maybe
we
should
just
capture
a
quick
list
of
those
things,
dump
it
in
an
issue
somewhere,
and
we
can
maybe
try
just
the
way.
We've
mentioned
incident
management
trying
to
have
flesh
out
those
use
cases
separately
in
terms
of
how
you
apply
the
principles
to
that
use
case.
Sorry,
I
spoke
out
of
that.
C
C
A
Yeah,
so
actually
I
was
about
to
say
something
I
think
you
scott
were
about
to
say
is
that
I
don't
think
we
have
a
consensus
on
three
and
I
think
we're
getting
closer,
but
I
guess
my
question
is:
is
how
do
we
because
it's
been?
I
think
I
think
three
weeks
now
since
we're
talking
about
principle,
three,
which
is
fine
like
if
we're
gonna
have
a
discussion.
If
we're
gonna
get
it
right,
let's
get
it
right,
but
I'm
thinking
about
in
terms
of
thai
boxing
at
least
a
discussion
right.
A
So
that
way
we
can
at
least
get
to
number
four
and
then
pick
up
number
three
next
time
and
as
long
as
it
takes,
but
I
don't
know
what
anyone
else's
ideas
is
behind
that
I
don't
know
where
you're
gonna
go
with
with
it
scott,
and
I
don't
know
what
leo's
gonna
say
so
I'll
I'll
yield.
My
time
there
just
a
suggestion.
B
Thank
you.
So
what
I
was
gonna
say
is
that,
first
of
all,
I
think
we
have.
I
think
we
have
to
come
up
with
a
mechanism
by
which
we
don't
get
a
hundred
percent
by
which
we
can
advance
without
expecting
a
hundred
percent
agreement,
because
I
think
we
might
just
circle
around
this
forever.
So
that's
kind
of
one
of
the
things
there's
there's
always
going
to
be
edge
cases
and
corner
cases
and
scenarios
that
might
fall
out
of
a
given
pattern
and
that's
fine.
B
You
know
what
I'm
saying:
there's
there's
commandments
and
then
there's
laws,
and
you
know
what
I'm
saying
that
there's
there's
a
difference.
One
is
an
ideal
and
the
other
one
is
kind
of
the
practical
application
of
that
self-defense
versus,
don't
kill.
You
know
what
I'm
saying
so
I
think
we
have
to
remain
at.
I
think
the
principles
are
more
along
the
lines
of
commandments
right.
These
are
ideals
that
we're
striving
for
and
then
also
keep
consciousness
and
mindfulness
of
the
fact
that
we're
really
trying
to
get
an
initial
version
out.
B
This
calls
are
not
about
ironing
out
every
possible
detail
in
every
possible
use
case.
Is
matter
of
that
fact
is
getting
this
exposed
at
us
at
a
given
version
at
a
given
state
to
even
a
broader
audience,
because,
as
we
expose
it
to
in
a
broader
audience,
we're
going
to
get
more
feedback
and
more
input
than
we're
actually
getting
in
these
calls.
So
I
would
advise
that
we
pick
something
that
the
majority
agrees
to.
We
define
that
as
the
the
baseline.
B
We
expose
it
to
a
wider
audience
and
allow
it
to
continue
to
evolve,
but
the
longer
that
we
keep
it
within
this
constrained
group.
We
might
be
doing
us
a
disservice,
so
I
I
would
suggest
we
very
much
keep
that
in
mind
and
try
to
kind
of
march
through
and
and
push
through
without
expecting
a
100
agreement.
That's
kind
of
my
two
cents.
G
I
think
it's
not
a
matter
of
100
agreement.
It's
I
think
it's
a
matter
of
consensus
and
consensus
means
that
we've
gone
through
all
of
the
options.
We've
explored
all
of
the
use
cases.
We've
gone
out
to
the
broader
audience
and
tried
to
gain
more
insight
and
and
try
build
that
consensus.
I
don't
think
you
can
do
a
majority
vote
and
say:
okay
and
most
people
agree
on
this.
Let's
just
move
on:
that's
not
called
consensus,
that's
called
majority
voting
and
so
like.
G
If
we
are
trying
to
build
consensus,
then
the
the
approach
would
be.
We
either
don't
release
number
three
or
we
release
it
in
a
version
that
we
have
consensus
on
and
then
we
bring
in
in
and
if,
if
people
don't
believe
that
we
have
consensus
on
removing
it
I.e,
it
must
be
in
then
we
don't
have
consensus
of
that
item
and
we
should
remove
it
and
say
this:
is
we
still?
G
We
still
are
working
on
this
working
through
the
use
cases
and
and
and
still
discussing
it
and
start
bringing
in
more
people
discuss
these
things
at
the
at
the
actual,
the
working
group
meeting
and
explore
it.
But
I
think
just
releasing
something
as
a
principle
as
a
baseline
version
without
consensus.
I
don't
agree
with
that.
I
C
G
C
My
suggestion
for
doing
this
was
in
order
to
help
us
move
ahead.
I
I
know
that
I
don't
want
to
get
into
any
sort
of
positional
argument
in
any
way
myself,
but
the
the
my
goal
was
to
to
see
if
we
could
remove
all
of
the
controversial
items
temporarily
and
still
come
down
to
the
core
of
what
of
what
these
principles
are.
Have
general
consensus
on
this
and
then
publish
an
initial
pre-release
version?
C
That
is,
and
that's
really
it
exactly
how
that's
done
we
didn't
get
down
to
the
votes
of
whether
one
person
could
filibuster
it
forever
or
or
or
all
the
various
I'm
not
saying
you're
doing
that,
but
I'm
saying
all
of
the
various
ways
in
which
rules
have
to
be
made
for
for
how
decisions
are
are
made.
We
didn't
we
haven't
gotten
to
that
point.
Yet
I
hope
we
don't
have
to
get
to
that
point.
D
So
I
mean
I've.
I've
got
my
around
my
hands
raised,
so
I'm
just
going
to
take
this.
I
I
I
think
moshe,
I
I
I
hope.
I'm
saying
that
right
I
might
not
be,
but
I
I
I
would
prefer
consensus
too,
maybe
dissenting,
even
though
I
think
you
and
I
started
disagreeing.
I
think
I
would
prefer
to
find
a
version
of
principle.
Three,
let's
take
out
the
stuff
right,
let's
take
out
stuff,
let's
trip
it
down
and
leave
something
that
we
we
kind
of.
D
We
have
consensus
on
some
stuff
that
we
can
agree
on
right
so
like
let
could
we
try
and
find
the
principle
of
state
reconciliation,
software
agents,
compare
systems
actual
takes
to
the
desired
state
if
the
actual
undesired
state
differ
for
any
reason,
actions
to
reconcile
them
initially.
Yeah,
for
example,
absolutely
right
christian
just
put
that
in
the
chat
right
now
I
I
would
prefer
to
go
with
a
like
a
limit
like
a
version
like
that,
which
I
think
everybody
on
this
call
would
kind
of
like
go
yeah.
That's
that's!
That's
cool
and
yeah!
G
So
if,
if
we
look
at
that
actual
definition,
software
agents
continuously
and
automatically
compare
a
system's
actual
state
to
its
desires
that
I
think
we
all
agree
on
that
and
and
if
the
desired
state
stiffer
for
any
reason,
automated
actions
reconcile
them
are
initiated,
and
I
agree
with
that
as
well,
so
we
can
initiate
access.
We
just
can't
complete
them.
So
from
my
perspective,
the
only
thing
we
need
to
do
here
is
remove
continuous
from
the
title.
You
can
keep
continuous
as
automatically
compare,
but
not
in
the
title.
D
A
B
Yeah,
I
I
guess
it
makes
me
uncomfortable
to
remove
it,
but
for
sake
of
0.1
and
and
kind
of
like
pushing
through
as
long
as
it
remains
a
component
in
the
actual
description
of
the
principle,
not
removing
the
continuously
after
software
agents.
Just
the
continuous
from
the
title
I
can,
I
can
temporarily
live
with
that
discomfort.
D
I
I
I'm
gonna
had
a
kind
of
somewhat
humorous
note
here
but,
like
I
think
everybody
on
this
call
actually
really
cares
about
all
the
very
kind
of
detail
and
fundamental
and
definitions
and
stuff.
That's
why
we're
on
this
score?
The
truth
is,
I
think,
a
lot
of
people
who
are
going
to
read
this
would
not
notice
the
difference,
if
that
in
in
kind
of
the
subtle
points
we're
discussing
that
they
would
never
figure,
they
never
realized.
That
was
there,
but
I
I
I'm
glad
I've,
I'm
glad.
C
B
It's
just
a
quick
thought
that
kind
of
resonates
with
what
bris
is
saying
this
is
this
is
not
a
speck
right.
This
is
not
a
and
a
speck
that
needs
to
be
followed
to
the
t
when
you're
implementing
a
gita
compliant
system.
This
is
something
different
right,
so
I
guess
to
resonate
or
echo
what
bris
is
saying.
This
is
not
something
that
somebody's
gonna
grab
to
determine
how
much
they
apply
to
the
standard
right.
This
is,
I
think,
more,
like
theoretical
in
in
sense,
so
yeah.
A
F
F
C
So
I
I
think
we're
we,
we
don't
have
a
consensus
and-
and
I
I
think
we
we
should-
we
should,
in
the
time
between
now
and
the
next
meeting
offline,
how
we're
going
to
make
the
best
use
of
the
meeting
the
next
meeting.
It
could
be
that
we
want
to
discuss
this
exact
topic
again
for
another
week.
It
could
be
that
we
want
to
move
on
to
another
topic
and
circle
back
to
this,
but
but
let's
do
that.
Does
anyone
have
any
other
like
housekeeping
related
things?
G
So
what
I
would
suggest
is
we
open
up
discussion
points
on
both
continuous
and
loops,
these
two
kind
of
separate
discussions
and
whatever
was
discussed
last
week.
We
can
dump
into
that
loops
discussion
and
I
think
we
we
should
be
moving
some
of
these
discussions
offline
for
longer
term
posterity
anyway,.
C
That's
that's
my
that's
my
personal
opinion.
I
could,
for
example,
say
I
take
issue
with
the
word
operation
and
I
could
not
budge
on
that
for
months.
If
I
wanted
to,
I
think
we
do
need
to
find
some
way
to
move
this
ahead.
I'm
not
saying
I
know
exactly
how
it
needs
to
be,
but
I
do
know
that
here
here
we
are
where
we
have
one
person.
C
Well,
we
have
a
voice
in
the
group
that
that
that
thinks
that
that
the
connotations
of
one
of
the
words
is
a
is
a
blocker
and
a
number
of
other
voices
on
the
call
that
believes
that
without
it
it
it
does
not
hold
the
foundational
principle
of
git
ups.
So
we
need
to
find
a
way
to
to
square
that
circle.
Somehow
we'll
we'll
we'll
make
some
suggestions
offline,
let's
discuss
it
and
then
make
sure
that
our
next
meeting
is
really
pretty.
We
can
move
ahead
in
some
way.