►
From YouTube: GitOps Principles Committee - May 5, 2021
Description
Meeting notes: https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit#heading=h.tqxwlrlh1y2w
A
Okay,
we
are
now
recording
welcome
everyone
to
the
may
5th
weekly
principles
committee
of
the
adopts
working
group
1900
gmt
every
week
from
now
on,
I'm
scott
rigby
nice
to
meet
you,
I
just
dropped
in.
I
am
just
now
dropping
in
the
lane.
I'll
do
the
notes,
if
folks
can
help,
fill
out
the
attendees
list
and
we
have
an
agenda.
A
B
C
C
A
Not
at
all
thanks,
leonardo
and
also,
I
should
note
that
that
has
changed
to
for
reese
and
anyone
else
watching
the
recording
and
the
other
three
people
in
the
call
too
yeah.
So
please
yeah
just
do
what
leonardo
said:
there's
the
the
working
group,
monthly
principles
committee
and
github's
come
committee.
It's
also
the
same
outline
now,
that's
in
the
meetings
dot
md
file
in
the
root
of
the
gaps
working
group
repo.
There
is
a
pr
open
that
I
just
opened
to
update
our
meetings
for
this
week.
A
I
must
say
that
I'm
tempted
to
suggest
moving
that
off,
so
we
don't
have
to
do
a
pr
for
every
single
every
single
meeting,
but
for
now
people
start
to
like
it.
We
can
always
revisit
okay,
so
the
first
topic
is
sticking
to
plan
the
the
goal
is
to
briefs
or
I
will
open
the
hack
mddoc
want
me
to
do
that
brace.
A
C
C
C
C
D
I'm
happy
to
not
skip
bands
because
we're
small
either
way,
but
but
I
think
we
perhaps
need
to
discuss
principle
number
five
and
whether
this
is
part
of
principle
number,
four
or
not.
Is
that
of
governance
through
get,
and
I
think
probably
a
good
example
of
this
is:
does
is
a
heroku
style
model
of
deployment
considered
git
ops
and
if
I'm
pushing
straight
to
master
without
a
pull
request
and
any
type
of
merged
blocking
test
enabled?
A
A
B
Purpose:
yeah
yeah,
I
mean
like,
if
we're
just
gonna,
add
it
to
the
agenda
and
we'll
get
to
that
anyway.
I
think
that
there's
a
discussion
to
be
had
around
governance
through
git,
and
I
think
that
that's
something
that
you
and
I
scott
spent,
spend
a
lot
of
time.
Actually
thinking
about
like
this,
what
is
the
scope
of
githubs
right
and
where
do
we
stop?
Where
does
that
scope
stop?
So
I
think
that's
something
that
it's
not
the
like
we'll
get
to
that
we'll
get
to
the
discussion.
C
Just
a
very
quick
comment
that,
in
terms
of
scope
of
get
ups
and
implementation
versus
principles,
I
think
the
principles
should
be
too
agnostic.
We
always
talk
about
state
as
just
as
a
concept,
so
anything
that
talks
about
get
or
pull
requests
or
anything
even
like
pull
request
is
not
even
tool.
Agnostic,
it's
provider,
agnostic,
it's
github!
C
A
A
Maybe
you
can
raise
it
again
or
we
can
think
about
it.
Okay,
welcome
cornelia,
sorry
to
be
late!
Oh
good!
I'm
surprised
anyone
can
make
it
even
close
to
on
time
this
week,
nin's
very
insane
week.
Okay,
so
I'm
gonna
drop.
The
I'm
gonna
drop
the
link
to
the
notes
again
here
for
for
a
few
folks
that
just
joined
and
that's
for
this
week.
A
A
One
note
that
it
is
that
the
last
week
I'm
just
going
to
skip
to
sorry,
let
me
blow
this
up
a
little
bit.
Is
that
better
yep?
Thank
you.
Okay,
last
week
we
had
an
action
item
that
this
was
that
wording
viewpoints
were
to
be
added
to
github
discussions
for
a
asynchronous
discussion
for
asynchronous
communication,
as
we
work
towards
broad
consensus,
not
unanimous,
unanimous,
specifically
for
the
first
pre-release
of
the
revised
principles.
A
So
we
can't
discuss
it
now
that
we're
not
prevented
from
discussing
it.
We
really
should
so
if
anyone
has
any
thoughts
to
start.
This
is
what
we
said
we
were
going
to
leave
off
with
is
to
be
discussed
in
principle.
Four,
let
me
blow
this
up
a
little
bit
is
that
good,
yeah,
it's
readable.
Okay,
this
was
the
items.
These
were
the
items
to
be
discussed,
I'll,
read
it
out
loud
to
human,
slash
machines
and
desired
state.
B
B
I
mean
people
who
operate
on
systems
and
to
system
operators
right
systems
who
operate
on
systems
and
that
both
of
those
should
act
in
the
same
way,
and
I
I
I
think
that's
that
can
be
very
well
handled
in
the
explanatory
notes
and
they
don't
necessarily
need
to
make
that
distinction
in
the
principle.
But
that's
that's
their
intended.
F
F
A
A
B
C
A
What
I
was
about
to
write
down
is
the
other
open
discussion
items
that
I'm
aware
of
and
if
someone
disagrees
with
them,
please
let
me
know:
I'm
just
going
to
go
ahead
and
take
the
liberty
to
write
them
down,
because
I
believe
I
think
we
all
know
what
they
are.
Did
you
have
more
to
say
leonardo
there
or.
C
No,
that
was
that
was
just
my
question
and
if,
if
that,
if
that
was
actually
the
intent,
I
think
we
want
to
keep
the
principle
to
the
absolute
indispensable
to
understand
the
underlying
concept
and
nothing
else
and
anything
that
has
to
do
with
edge
cases,
use
cases,
implementation,
specific
tools
and
otherwise
should
as
much
as
it
may
might
provide
further
clarity
should
not
be
in
the
principle
but
elsewhere.
That's
what
I
would
summarize
my
decision
criteria
to
to
be.
G
Yes,
so
I'm
I'm
stepping
back,
I
think
one,
I'm
popping
the
stack.
If
you
will
the
this
this
conversation
around
when
brace
was
talking
about
it.
I
was
totally
with
you
brees.
Is
that
this?
The
principle
four
which
says
okay?
The
only
way
to
do
operations
is
by
following
these
principles,
and
that
applies
to
humans
and
machines
alike.
G
Awesome
totally
on
board
with
that,
and
then
robert.
You
said
something
about
machine
and
human
readable
and
to
me
the
readability
is
orthogonal
from
what,
from
the
point
that
bruce
was
making
in.
In
fact
it's
it's
almost
at
a
little
different
level
of
granularity,
and
so
I
also
don't
see.
Maybe
the
human
readable
thing
is
in
in
the
more
detailed
notes,
but
I
don't
see
it
in
the
short
description
either.
So
I
just
wanted
to
make
the
point
that
we
were
talking
about
humans
and
machines,
but
in
two
different
axes.
If
you
will.
G
G
E
E
Yeah
yeah
right,
but
but
I
also
mean
that
the
the
fourth
principle
takes
in
one
two
and
three,
so
all
of
these
things
are
kind
of
implied
by
by
going
through
those
principles.
You
know
it's
machines,
your
agents
should
read
and
we're
trying
to
continue
continuous
state
reconciliation.
Everything
like
that
is,
you
know,
paved
the
way
for
principle.
Four,
which
says
these
three
principles
are
the
only
things.
Those
are
the
ways
you
intentionally
should
change
the
system
which
by
then
I
mean
all
of
these
things
are
implied
through
those
principles.
E
E
B
Okay,
cool
thanks,
reese
yeah,
I
think,
like
the
so
I
I'll
I'll
back
cornelia
with
in
my
intent
when
I
said
this,
like
readability,
relatability,
that's
an
observation,
but
it
doesn't
that
doesn't
necessarily
something
being
read
and
read
and
writes
by
machines,
and
humans
doesn't
imply
that
you
must
operate
on
it
by
machine
human.
That's
not
the
logical
set
is
distinct.
However,
I
think,
as
as
robert
said,
they're
like
that
is
implicit
right.
It's
it's
a
implicit
versus
explicit
thing.
B
I
think
it's
absolutely
implicit
that
machines
and
humans
should
operate
in
the
same
way,
because
we
don't
really
make
a
distinction
anywhere
else.
It's
like
we
say
about
operating,
so
that
doesn't
that
that
includes
all
operations
and
like
I
I
think
it's
it's
and
it's
it's
fine
to
not
include
it
in
the
short
text.
I
I
I
want
to
make
a
kind
of
a
general
point
about
the
explanatory
note.
B
So
it's
open
to
extension,
but
not
modifications.
So
it's
kind
of
adding
discussions
about
what
happens.
In
what
circumstances
can
you
break
glass?
In
what
circumstances
can
you
should
you?
What
is
what's
the
level
of
pragmatism
that
you
want
to
apply
to
this,
like?
I
think
those
the
explanatory
notes
can
kind
of
like
slowly
build
into
a
corpus
of
github's
knowledge,
rather
than
be
seen
as
a
kind
of
a
fixed
document.
The
way
the
principles
were
sorry
that
was
quite
long-winded,
but.
A
I
I'm
just
taking
a
note
on
that.
Greece,
thank
you
and
no
one
had
their
hand
raised
after
that,
but
still
it
wasn't
too
long
with
it.
It
was
actually
two
minutes
perfect.
I'm
just
making
a
quick
note
that
principal's
notes
could
you
know
simply
refer
to
in
under
what
under
what
circumstances
right.
B
Yeah
yeah
and
then
specifically,
I
think
there
are
like.
I
think,
that
the
case
of
break
glass
right.
How
do
you
operate
in
an
emergency
and
that
that
comes
up
in
pretty
much
all
discussions?
I've
had
with
kind
of
in-depth
discussion
of
githubs
is
what
happens
when
something
goes
wrong
right
and
there's
also
the
aspect
of
there's
a
lower
turtle.
B
I
keep
using
that
term,
but
it
it's
the
idea
that
at
some
level
of
the
stack
you
can't
bootstrap
githubs
with
githubs
right,
so
it's
possible
to
to
kind
of
self-host
githubs
so
that
you
set
up
a
cluster
manually.
Then
you
from
that
cluster
or
from
that
system
set
up
another
system
that
does
the
gitoff's
management
and
then
you
kind
of
substitute
the
first
system
by
getting
this
managed
system.
B
But
nobody
does
that,
and,
and
nor
should
you
right,
there's
going
to
be
a
lower
layer
level
where
you're
manually
sending
stuff
imperatively
somewhere,
and
I
I
think,
like
that-
that's
worth
discussing
to
make
sure
that,
like
there's
an
understanding
that,
at
some
level
it
doesn't
matter
kind
of
how
sophisticated
your
approach
is.
Some
there's
some
layer
at
which
you
can't
apply
the
approach,
because
you
need
to
set
up
the
system
that
does
get
ups
right
and
so
having
a
discussion.
A
And
when
we
get
to
that
discussion,
I
would
just
propose
that
that's
a
another
good,
a
very
good
use
for
the
notes,
and
I
think
we
should
also
keep
the
notes,
not
short,
but
but
you
know
not
keep
not
have
hundreds
of
them,
but
just
simply
the
things
that
were
brought
up.
That
people
feel
are
very
important,
but
they
weren't
important
they're,
not
critical
enough
to
to
reduce
the
general
understandability
of
the
one
line
of
the
principle.
A
Nor
do
they
need
to
be
repeated
in
the
one
paragraph
explanation
that
they
they're
they're
satisfied:
they're
satisfactory
for
the
notes
so
and
and
by
the
way
we
might
want
to
suggest
that
we
have
conditions
like
that.
These
not
be
footnotes.
You
know,
they're,
not.
Eight
point
font
way
down
at
the
bottom
of
something,
but
but
but
very,
very
clearly
and
prominently
displayed
with
the
other
principles
in
the
principles
document.
That
would
be
my
suggest
proposal
anyway.
B
Yeah,
I
can
totally
see
that
the
document
itself
having
you
know
if,
if
somebody
wants
to
propose
a
note-
and
we
have
a
under
the
principles
we
have.
You
know
explanatory
note,
note
one
title
of
the
note
and
then
the
link
to
that
note
or
the
note
in
in
embodied
there
to
kind
of
go
through
that.
That
particular
item
I
mean
we've
kind
of
very
quickly
talked
about
three.
Now
I
can
identify
three
things
right,
like
instantaneity
get
bootstrapping
and
breaking
glass.
B
So
I
think
those
are
like
worthy
topics
of
kind
of
discussion
and
there
are
a
bunch
more
and-
and
we
can
certainly
mine,
some
of
the
previous
discussion
and
documents
around
githubs,
because
they
they,
I
think,
we
scott
and
scott-
and
I
spent
quite
a
bit
of
time
in
studies
called
media
thinking
about
you
know
what
does
that
actually
mean?
What
does
the
principles?
How
do
those
principles
actually
apply
and
what
are
the
the
pragmatic,
the
real
world
consequences?
So
there's
a
fair
amount
of
of
prior
art
that
we
can
reuse
here.
E
I
think
we
probably
could
write
entire
books
on
the
subjects
around
these
things,
which
I
I
just
read
the
little
book
of
ikigai,
which
have
five
pillars
or
whatever
it
is,
and
it's
an
entire
book.
So
you
know,
but
coming
back
again,
it's
these
kind
of
short
principles
or
short
like
these
are
the
these
are
the
pillars,
and
it's
the
same
thing
here.
E
If
we
keep
this
short
and
and
like
shortened
to
the
points,
we
can
then
obviously
riff
on
that
and
and
talk
about
a
lot
of
things
surrounding
these
principles.
That
might
not
be
directly
clear,
but
we
can't
put
everything
into
these
and
then
it
would
be
entire
articles
per
principle
and
that
won't
work.
G
F
H
H
E
A
Great
sorry,
I
was
just
replying
to
to
someone
who
wanted
to
join
this
meeting
that
was
confused
about
the
google
doc.
I
think
we
might
need
to
put
an
outline
at
the
top,
as
opposed
to
relying
on
google
sal
line,
and
if
so
that
would
be
my
mistake,
because
I
I
did
reorganize
it.
So
sorry,
sorry
about
that
to
interrupt.
If
I
did
did
you
have
more
to
say
on
that
robert
or
was
that
a
natural,
okay,
great
okay,.
A
I
might
I
wasn't
counting
the
minutes
on
that
one,
but
it
seemed
it
seemed
pretty.
Okay
all
right.
Well
then,
in
that
case
just
going
back
to
the
agenda,
if
no
one
has
an
objection
to
the
way
to
the
short
memorable
version
of
number
four,
then
I
think
we
should
just
say
again.
These
are
these
are
a
work
in
progress.
We
are
talking
about
the
pre-release
of
these,
not
a
final,
even
a
full
release
of
these.
So
it
sounds
like
we're
good.
A
I
I
believe
can
can
people
catch
or
can
we
catch
up
here
on
the
items
to
be
discussed,
I
wrote
maybe
some
under
maybe
two
extensive
notes
on
to
be
discussed
for
all
the
principles,
just
what
we
adults
just
said,
and
if
someone
thinks
that
that
should
be
different,
please
say
so
or
just
go
ahead
and
edit
it
or
also,
please
say
so.
If
you
do
edit
it
I'm
pointing
out
the
fact
because
I
did-
and
there
are
three
other
discussion
items
I
think
number
four
it
looks
like
we
have.
A
E
A
I
think,
actually
I
I
that
does
trigger
my
memory.
I
believe
you're
right
and
the
suggestion
was
we
had
discussed
so
many
different
ways
to
describe
number
four
and
at
the
very
end
it
seemed
that,
through
these
principles
was
something
that
everyone
seemed
to
be
generally
on
board
with
like
wow
you're
right.
We
don't
really
have
to
summarize
the
principles
again
after
we've
just
said
them
and
they
are
numb
in
order.
So,
okay
for
now,
I'm
going
to
cross
that
out.
A
And
we,
I
believe,
the
then
the
next
item
on
the
list,
if
we
want
I'm
not
sure
which
should
go
in
order,
but
the
next
item
on
the
list,
I
believe,
is
to
circle
back
to
moshe's
point
that
was
brought
up
in
well.
I
guess
discussed
for
two
full
weeks.
Pretty
much,
however,
also
taken
into
github
discussion
and-
and
there
have
been
some
various
viewpoints
expressed.
A
Moshe
do
you
do
you
want
to
do
that
or
before
you
do?
I
just
want
to
ask
if
you
are
in
theory,
fundamentally
opposed
to
the
idea
of
making
that
those
points
that
you
made
in
the
the
notes
of
principle
three,
and
I'm
only
asking
that,
because
I
believe
that
we
already
have
broad
consensus
that
that
is
not
only
appropriate
but
a
good
idea.
B
B
I
think
the
the
core
here
is
that
this
is
not
a
batch
process
and
the
best
way
of
describing
that
is
through
continuous,
and
I
don't
know
whether,
like
I,
the
word
is
just
a
word
I
I'm
not
but
like
we
need
to
be.
I
think
one
thing
that
we
need
to
capture
somehow
is
that
this
is
not
a
batch
process.
This
is
a
loop
that
con
that
continuously
checks
the
state
versus
the
desired
state.
B
That's
how
you
would
describe
it
if
you
were
speaking
voice
right,
viva
must
say
you
you
describe
it
like
that.
I
yeah,
so
I
I
don't.
I
don't.
I
don't
know
whether
the
the
generally
understood
meaning
of
the
phrase
as
it
stands
actually
excludes
and
implies
what
you
think
it
implies.
Moshe,
I'm
I'm
not
convinced.
That's
a
general
perception
I
I
would.
B
A
C
No,
I
was
being
okay,
so
just
a
very,
very
quick
comment.
I,
like,
I
think
it's
important
to
have
continuous.
I
think
it
is
a
continuous
process
and
being
a
continuous
process,
we're
also
kind
of
working
with
industry
standard
terminology.
So
we
have
continuous
integration,
we
have
continuous
delivery,
we
have
continuous
deployment
and
we
have
continued
state
reconciliation.
C
So
I
think,
from
that
point
of
view,
there
is
already
a
certain
understanding
in
the
ecosystem
of
what
this
would
mean
and
it
represents
a
progression
from
existing
terminology
that
uses
the
word
continues.
So
I
would
vote
for
continues
to
remain,
albeit
perhaps
not
scientifically
accurate
to
the
molecular
degree
yeah.
I
yield.
D
So
so
part
of
my
part
of
my
concern
with
continuous
is
the
industry's
abuse
of
the
term
and
the
resulting
fallout,
and
if
you
look
at,
for
example,
continuous
integration,
what
what
most
people
think
continuous
integration
and
what
was
meant
by
the
the
also
continuous
integration
is
very
different.
So
continuous
integration
isn't
running
a
build
continuously.
D
Continuous
integration
is
merging
of
feature
branches,
each
master
continuously
on
a
daily
basis,
and
and
and
and
again
that
that
that
pull
got,
got
abused
on
continuous
delivery
and
continuous
delivery
doesn't
mean.
I
can
I'm
deploying
all
the
time
and
continuously
delivering
my
code
into
production.
It
means
I'm
in
a
continuous
state
of
deliverability
and
and
and
again
with
continuous
integration.
D
It's
not
continuous
integration,
it's
it's
continuous
integration,
integratability
and
continuous,
deliverability,
and
and-
and
I
think
that
that
abuse
has
has
has
caused
so
many
problems
and
and
if
we
jump
on
the
continuous
chain
train
again
we're
just
going
to
be
explaining.
No,
we
don't
mean
continuous,
like
that,
a
year
or
two
down
the
line
and
have
to
clarify
this
definition
of
continuous
to
me.
D
No,
we
don't
actually
mean
that
we
mean
this
and
and-
and
I
think
that
that's
kind
of
where
the
problem
was
with
continuous,
comes
in
and
and
in
terms
of
a
proposal
for
changing
it.
I
think
the
principle
of
state
reconciliation
loops
is
a
far
better
description
of
what
we're
trying
to
achieve
and
it's
a
loop
and
whether
that
loop
happens
in
a
second
or
that
loop
happens
in
the
day.
It's
a
loop
and
and
that
loop
can
speed
up
and
it
can
speed
down
and
and
that
that
loop
in
theory
can
stop.
D
I
Why
didn't
you
put
in
continuous,
like
so
my
my
my
concern
being
that
kind
of
going
off
of
what
leo
said
since
it's
a
interesting
standard
I'll
be
a
wrong
one,
so
I'll?
I
think
I
agree
with
the
fact
that
the
terminology
may
be
wrong,
but
since
we
are,
if
we
remove
it,
are
we
losing
anything
by
removing
it
versus
what
we
gain
by
adding
it?
I
E
Yeah,
I
just
want
to
say
that
I
I
disagree
that
the
word
continues
is
wrong,
because
and-
and
I
I
actually
disagree-
that
the
word
continues
mean
instantly,
because
at
least
the
way
that
we
use
it
in
in
my
language
and
the
all
the
other
languages
that
I
know
there's
nothing.
That
links
continues
with
with
being
instant.
E
It
means
something
that
goes
over
time.
It's
it
is.
It
is
a
loop
so
when
you're
using
the
word
loop,
you're,
actually
more
or
less
implying
that
it
is
continuous,
so
so
removing
the
word
continuous,
all
right
sure,
but
then
I
would
say
that
that
would
be
the
principle
of
state
reconciliation,
not
putting
anything
other
in
there,
not
a
different
word
for
loop.
I
don't
feel
that
that
word
is
wrong
at
all
and
saying
that
something
you
know,
quoting
that
what
is
defined
as
the
definitions
are
there's
a
lot
of
definitions.
E
E
G
G
So
I
have
had
many
a
conversations
when
I've
suggested
continuous
delivery
and
they
say,
but
I
don't
want
every
code
change
to
go
to
production.
I
say
you
don't
have
to
and
so
they're
misinterpreting
what
continuous
delivery
means
by
the
way
I
for
me,
the
definition
of
continuous
means
you're,
just
it
just
means
you're,
never
done
so
continuous
to
me.
Equals
you're,
never
done,
and
so
I
have
also
by
the
way
emoji.
A
A
I
could
write
something
out
right
now,
but
I
don't
know
if
that
would
necessarily
satisfy
everyone
how
that
could
be
best
phrased
within
the
notes
section.
That
is
my
proposal
given
given
this.
Given
the
spirit
of
these
these
principles
and
what
I've
heard
from
most
of
the
people
most
of
the
time
it
doesn't
I'm
not
shutting
down
conversation.
We
can
still
do
this
as
long
as
new
points
are
made,
but
I
believe,
let
me
see
I
just
wanted
before
I
yield
my
time.
D
D
Component
but
but
there
we,
we
are
kind
of
breaking
principal
rules
of
principles
which
is
don't
contradict
yourself
and,
and
I
think
yeah
so
yeah.
So
I
I
think
we
can.
We
can
take
it
back
to
the
drawing
drawing
board
and
and
add
more
more
notes
and
definitions,
but
ultimately
we
always
going
to
be
contradicting
ourselves
because
we're
saying
on
that
on,
on
the
one
hand
we
don't
mean
instantly,
but
actually
the
definition
is
instantly.
D
So
it's
a
contradiction.
So
if
we
add
a
note,
we
accept
the
contradiction
that
that
con
that
continuous
might
have
a
dictionary
definition
of
instantly.
We
don't
actually
mean
instantly.
We
mean
that
it
happens
like
something
like
that.
More
more
succinctly
might
be
acceptable,
but
if
we
make
that
acknowledge.
D
B
So
two
things
so
number
one.
I
I
think
that
the
the
the
the
assumption,
like
the
our
unders,
like
the
collective
understanding
of
the
word
continuous
motion,
does
not
include
instantaneous
it
doesn't.
I
don't
think
anybody
here
would
hear
continuous
and
assume
instantaneous,
and
I
don't
think
that
the
dictionary
definition
of
that
does
support
the
instantaneous
either.
So
I
I
think
that's
definitely
that
that
is
not
included.
Instantaneous
is
not
included,
and
I
think
the
notes
that
we
will
have
will
be
very
explicit
about
this
right.
B
I
I
want
that
point
to
be
made
explicitly
in
the
notes.
What
I
would
suggest
is
actually
that
you,
you
you.
We
explicitly
published
the
first
draft
with
the
with
your
dissenting,
with,
like
literally
a
an
explicit
dissenting
opinion
about
the
word
continuous
I
I
would.
I
would
wouldn't
mind
having
that
in
our
first
draft
saying
here's
something
right:
here's
a
here's,
a
dissenting
opinion
about
principle,
three
in
our
first
draft.
A
A
Cool,
I
also
would
like
to
well
my
two
minutes
thing
isn't
up
yet,
but
I
would
also
like
to
ask
others
to
to
to
help,
I
believe
not
only
brees.
Did
you
say
that
you
and
I
had
discussed
for
quite
a
while-
the
break
glass
incident
management
exception
to
the
to
the
principle,
as
well
as
the
bootstrap
exception.
Those
might
be
two
that
you
could
potentially
work
on.
A
I
know
we've
already
done
it
in
longer
form
in
the
in
the
pr,
but
perhaps
work
on
in
the
short
form,
as
we
just
mentioned
for
mosha,
something
that
would
be
acceptable
in
the
notes
and
then
that
could
be
discussed
in
the
pr
too.
Well
with
that
with
that,
I
believe,
including
dissent
that
will
be
transparent.
A
We
have
general
consensus
on
these
four
principles.
There
is
one
more
point
of
discussion
and
that
was
not
covered
yet,
and
we
have
seven
minutes.
I
want
to
not
take
it
to
the
last
second,
I
like
to
give
ourselves
a
minute
or
two
at
the
end
to
discuss
when
our
next
meeting
is
and
or
I
know
we-
we
know
it
it's
weekly
now,
but
just
to
do
a
little
housekeeping,
so
so
for
the
next
six
minutes.
A
D
Cool
so
like
so
I
by
governance,
to
get
like
pull,
requests
and
merge
blocking
branch,
protection
or
kind
of
implementations
of
that
governance
process.
So
whatever
it's
called
in
whatever
system
it
is,
but
but
really
the
idea
that
you
can't
make
a
change
without
having
any
governance
process
in
place
and
whether
that's
a
pull
request,
whether
that's
something
else
that
isn't
a
pull
request
or
or
a
merge
blocking
test
or
whatever
it
is.
A
Okay,
I'm
going
to
raise
my
hand
in
lieu
of
anyone
else,
while,
while
folks
are
ingesting
that
I
just
put
up
the
the
discussion
item
up
here
moshe,
I
do
agree
with
you
on
so
many
things,
I'm
sorry
that
it
seems
like
we're
like
somehow
butting
heads
on
these
particular
ones.
I
think
personally,
that
this
is
that
this
is
a
good
point.
That
could
be
a
note
as
well
as
I
as
I
know
here
two
weeks
ago.
A
I
know
you
said
you
disagree
and-
and
we
can
have
that
discussion
here
and
and
have
other
points
of
view,
but
just
to
be
very
clear
on
what
my
disagreement
is.
I
think
the
prince,
as
stated
already,
the
principle
of
immutable
desired
state
versions
already
describes
this
in
the
in
the
one
paragraph
or
really
one
sentence
where
it
says
desired.
State
is
stored
in
a
way
that
supports
versioning,
immutability
of
versions
and
retains
a
complete
version.
A
History,
from
my
point
of
view,
since
auditability
is
one
of
the
benefits
and
auto
requirements
are
excuse
me,
the
auto
requirements
themselves,
I
believe,
are
an
implementation
detail
that
would
vary
by
tool
and
by
system,
and
so
from
my
point
of
view,
that
could
be
an
important
intention
to
note
in
a
note,
but
I
don't
think
it's
an
additional
principle
personally,
because
it's
so
closely
aligned
with
principle
two.
But
that
is
my
point
of
view.
Only
okay
believe
christian
was
next
and
then
chris
sanders
did
I
get
that
right.
I
I
think
so
so
real
real
quick,
so
I
don't
have.
I
still
need
to
ingest
it
a
little
bit
and
and
read
the
the
github
issue
more
in
depth,
but
I
was
kind
of
my
question
was:
how
is
this
different,
so
I
guess
kind
of
what
you
were
saying
scott.
I
wanted
to
see
how
is
this
different
than
you
know
how
it
separates
itself
from
the
other
principles,
because
I
do
believe
like
like
like
principle
one
and
then
I
guess
four
would
kind
of
cover
this.
I
So
I'm
trying
to
figure
out
I'm
still
trying
to
adjust
how
it
would
be
different.
So
that's
just
something
that's
not
entirely
clear
if
we
need
a
whole
nother
one
if
other
ones
cover
it.
Although
I
agree
with
with
with
the
the
general
idea
behind
it
right
like
that,
I
think
that's
what
separates
you
know,
get
offs
from
a
lot
of
other
practices
out.
There
is
the
governance
through
get
right
through
those
processes.
F
So
I
see
this
more
falling
under
best
practices
for
core
get-ups.
I
don't
see
that
we've
made
any
statement
at
all
about
what
the
ci
pipeline
looks.
Like
you
know,
a
person
could
literally
make
an
edit
to
yaml
files
in
their
git
repo.
That's
been
tracked
and
just
immediately
merge
it,
and
that
would
be
fine.
That's
that's
still
good
ops,
but
it
would
not
be
a
best
practice
right.
F
D
So
so
I
think
the
fact
that
you
have
the
aversion
or
an
order
trail
is
one
small
factor
of
governance
and
then,
when,
when
I
put
on
an
auditor's
hat-
and
I
look
at
a
process
and
say
how
did
this
change
get
into
production
like
the
fact
that
it
got
in-
and
I
can
see
who
put
it
in
and
when
they
put
it
in,
is
just
one
part
of
the
the
equation?
The
other
part
is
what
is
the
process
and
and
change,
control
process
and
governance
process
of
what
can
go
in?
How?
D
H
B
Okay,
thank
you,
greece,
yeah.
So
I'm
I'm
literally
writing
this.
Now.
I
think
it's
the
difference
between
practice
and
principle,
and
I
I
I
cannot
like
I.
I
would
emphasize
the
point
that
that
that
governance,
grc
right
governance,
risk
and
compliance
is
extremely
important
for
any
serious
github
application,
but
it's
very
context
dependent.
It's
not
a
universal
thing.
B
So,
for
example,
if
you're
a
two
person,
startup
team,
yeah
you're
going
to
operate
we're
using
githubs
by
committing
straight
to
your
master
branch,
if
you're
doing
a
personal
project
and
you're
operating
some
a
small
scale,
I
don't
know
you've
got
a
small
scale,
server
installation
to
water
your
plans
or
to
monitor
your
greenhouse
right
like
that's,
it's
it's
becomes
very
acceptable
to
commit
straight
to
master.
So
I
think
because
governance
is
context
dependent,
it's
not
a
universal
principle.
B
That
said,
I
think
governance
should
be
addressed
explicitly
in
kind
of
the
output
of
this
working
group.
Right,
like
that's,
that's
so
important
that
we
can't
let
we
can't
just
not
mention
anything
about
governance.
I
just
don't
know
whether
it
should
be
principle.
I
I
can
absolutely
see
that
being
kind
of
an
additional
piece
of
work
on
top
of
the
principles
that
we
explicitly
talk
about
both
practices
and
the
governance
and
how
the
principles
enable
governance
risk
and
compliance
in
an.
A
A
We
haven't
limited
them
at
this
point
we
haven't
had
the
need
to
do
that,
yet
I
would
recommend
starting
there
unless
they're,
unless
there
is
going
to
be
brought
a
lot
wider
consensus,
that
we
need
another
principle
that
we
that
we
begin
by,
adding
that
there
mosh.
Would
you
object
to
me
making
that
note
in
the
notes
section
for
the
moment?
D
A
A
We
we
in
fact
have
had
dissenses
so
far
about
that,
at
least
in
this
call,
but
that
doesn't
mean
that
further
principles
couldn't
be
added.
I
move
to
make
a
pre-release
again.
We
are
not
writing
a
scientific
paper.
Nor
are
we
building
a
heart
monitor.
We.
We
have
a
goal
and
we've
had
a
stated
goal
since
last
november
to
publish
a
version
of
what
we
would
have
been
calling
manifesto
we're
now
calling
principles
by
a
little
while
ago.
A
We
have
had
broad
consensus
on
these.
The
discussion
has
helped
to
clarify
and
refine
them,
but
I
move
to
make
a
first
pre-release
version
of
these
principles
published
by
the
get-offs
working
group
they're
the
refined
principles.
As
we
all
know,
there
have
been
principles
out
since
2018.
I
believe
so.
These
are
the
refined
principles
by
the
good
ops
working
group,
a
pre-release.
That
is
my
motion.
D
A
Okay,
great
so
in
that
case,
the
steps
that
priest-
and
I
said
we
would
do
initially
we're
going
to
bring
the
get
history
from
from
all
of
the
all
of
the
get
history.
From
that
pull
request,
we're
going
to
bring
that
into
a
new
pull
request.
The
idea
was
we're
going
to
do
that
in
a
new
repo
under
the
open,
get
ops
project
and
strip
out
everything
that
was
contentious
so
far
or
not
contentious,
sorry,
everything
that
did
not
reach
broad
consensus
and
what
we've
agreed
to
now
to
start
for.
A
The
first
excuse
me,
the
first
pre-release
version
that
we,
as
the
principals
committee,
will
all
sign
off
on
this
again.
As
you
said,
I
still
have
to
make
this,
because
this
is
a
condition,
as
you
said,
moshe
with
the
with
the
distance.
The
note
the
note
that
that's
important
and
the
co-authorship
will
be
everyone.
Who's
participated
in
these
principles
committee's
meetings
and
we
can,
before
that's
merged,
have
any
final
say
before
before
that's
merged
we'll
have
a
process
and
get
that
first
pre-release
version
out.
B
A
Great
great
sound
sounds
great,
okay,
so
we'll
do
that
and
we'll
make
this
clear
in
the
mailing
lists
that
that
this
pull
request
is
out
to
give
everyone
a
chance.
We
will
broadly
publicize
this,
and
then
we
will
get
a
version
out
there.
So
folks
can
think
that
the
get-offs
working
group
is
actually
doing
something.