►
From YouTube: GitOps Working Group - February 11, 2021
Description
Notes: https://docs.google.com/document/d/1hxifmCdOV5_FbKloDJRWZQHq0ge-trXJKF-BgV4wHVk/edit#heading=h.w91ueqcmi7nz. For more info see https://github.com/gitops-working-group/gitops-working-group
A
C
C
C
C
There
are
lots
of
notes,
so
just
to
give
you
an
idea,
there's
lots
of
hidden
comments
in
there,
but
I've
omitted
them
from
the
pr
that
we
have
right
now,
just
because
they're
in
bullet
point
form
rather
than
actual
they're,
not
very
clear.
Unless
you
have
a
lot
of
context
so
yeah
it
is.
We've
set
up
the
four
principle,
as
described:
we've
actually
refined
them
quite
a
bit.
C
We've
also
done
some
work
on
actually
digging
into
some
of
the
implications
of
these
fairly
pithy
and
short
statements.
So
this
is
kind
of
a
very
short,
very
digestible
statement,
but
there
are
lots
of
implications
around
that
and
we've
gone
into
it
for
the
declarative,
configuration
which
is
quite
a
lot
of
kind
of
additional
notes.
C
We
also
have
we've
also
had
some
comments
already
from
nate,
so
thank
you.
Nate
I've
actually
moved
the
pr
from
my
own
personal
repository
to
move
it
to
the
shared
repository
so
that
other
people
can
it's
more
discoverable,
but
I've
I've
tried
to
take
into
account
some
of
your
comments
already.
If
you
have,
if
you
want
to
move
them
across
or
if
you
have
a
want
to
have
another
read
to
see
whether
I've
resolved
some
of
the
issues
you've
raised.
That
would
be
fantastic.
C
So
essentially
it's
now
on
a
on
a
in
a
place
as
a
request
for
comment
really
on
what
we
have
already
so
there's
a
pr
there
on
the
github's
working
group.
It's
probably
the
ideal
place
for
us
to
start
discussing
what
we
have
and
grow
it
from
here.
As
I
mentioned
earlier,
there
are
lots
of
kind
of
hidden
notes
in
there.
I
intend
to
turn
those
into
actual
written
paragraph
in
the
matter
in
the
next
few
days.
C
A
You
got
it
dan
and
I
and
I
apologize
for
not
getting
the
agenda
on
the
notes
earlier,
but
it
is
there
now.
I
think
it
was
technically
my
job.
So
thank
you
for
doing.
Well
there
you
know
all
volunteer
organizations
right
so
with
with
regards
to
the
get
ops
principles
again,
that
is
a
key
output
of
the
working
group.
So
we
would
love
to
have
folks
who
are
interested
in
git,
ops
and
in
the
community
participate
in
the
formation
of
that
document.
A
So
if
you
are
interested
what
I,
what
we
would
ask
is
maybe
on
the
agenda,
it
looks
like
scott
you,
maybe
so
maybe
on
the
on
the
notes.
For
today
we
can.
We
can
add
in
folks
who
would
be
interested
in
joining
the
committee.
So
let
me
put
a
sec
a
section
into
the
notes.
Again,
the
notes
are
linked
to
in
the
the
chat.
A
And
then
the
other
thing
that
you
should
do
is
what
we
use
for
communications
is
where
we
are
using
the
cncf
slack,
and
so
I
know
everyone
is
sensitive
about
putting
their
contact
information
in
a
google
notes
sheet.
So
put
your
name
there,
but
also
please
join
the
cncf
good
ops
working
group
chat
on
slack
and
then
we
can
give
specific
feedback.
We'll
also
share
the
link
to
the
working
document
so
that
people
can
participate.
D
With
that
we're
ready
to
move
on,
I
think
to
our
next
topic.
I
obviously
encourage
people
to
get
into
the
manifest
the
principles
document
and
can
leave
notes
and
comments
and
keep
the
discussion
there
and
then
the
next
item
on
the
agenda
is
update
on
the
status
of
the
get
ops
working
group
as
part
of
the
cncf.
I
think
cornelia.
Do
you
have
the
update
on
this?
I.
F
Do
yep
so
a
number
of
things.
One
is
just
a
a
bit
of
info
in
case
anybody
missed
it,
but
the
get
ups
working
group
has
been
accepted
as
a
santa
sandbox
project
in
the
cncf
again
to
yes,
thank
you
for
those
who
helped
make
it
happen
just
to
remind
everyone
and
for
the
record
the
reason
that
this,
while
this
might
sound
a
little
bit
odd
to
some
at
first
first
blush.
F
The
reason
for
putting
it
in
as
a
sandbox
project
is
that
these
the
work
of
the
get
ops
working
group
will
live
beyond.
Perhaps
even
the
get
ops
working
group
itself.
So
it's
not
unusual
for
a
working
group
within
a
cig
to
be
launched
to
focus
in
on
a
particular
area
and
that's
what
we're
doing
here
with
get
ops,
but
it
may
come
a
time
where
we
say
okay,
well,
we're
our
job
is
done.
F
F
So
that's
a
good
thing
now
from
more
from
an
administrate
administrative
perspective.
There
are
a
number
of
things
that
we
want
to
do.
Some
of
the
things
that
I've
spoken
with
the
the
leaders
of
the
app
delivery
sig,
who
have
been
very,
very
helpful
and
they
are
kind
of
our
parent
sig-
is
that
it
was
highly
recommended
from
them
not
to
stand
up
as
separate
an
independent
mailing
list
for
the
get
ops
working
group.
F
They
have
not
done
that
for
other
working
groups,
and
so
I
I
say
that
I
would
suggest
that
we
stick
with
that
recommendation
to
start,
and
if
we
come
up
with
a
desperate
need
to
create
a
mailing
list,
we
can
always
go
back
and
re-assess
that
what
they
recommended
instead
is
to
use
slack,
and
we
already
have
that
slack
channel
but
to
use
the
slack
channel
as
the
working
group
specific
channel.
Then,
when
there
are
things
that
we
want
the
broader
app
delivery
sig
to
know
about,
and
we
can
certainly
use
that
delivery.
F
Sig,
for
you
know
some
stuff
sparingly,
but
that
was
the
recommendation
from
them
and
unless
there
are
objections
I
say
we
give
it
a
shot
and
so
make
slack
our
our
our
primary
way
and
then,
of
course,
things
like
the
pr's
and
and
those
types
of
things
in
the
in
the
git
repo
repository.
So
we
can
certainly
use
it
as
well
yeah
any
objections.
B
B
B
B
B
Anyone
that's
in
slack
or
contributing
to
slack
and
answering
questions.
Often
you
end
up
answering
them
over
and
over
and
over
again
and
github
discussions
is
sort
of
like
stack
overflow.
It's
basically
essentially
github
stack
overflow,
so
so
the
playbook
would
basically
say
hey
if
there's
a
question,
let's
check
to
make
sure
that
there's
already
either
an
issue
or
or
a
github
discussion
for
this,
and
if
it's
something
that
is
asked
more
than
once,
even
then,
let's
let's
go
ahead
and
consolidate
that
and
get
a
discussion.
Something
like
that.
B
Yes,
I
did,
and-
and
I
enabled
the
discussions
there
was
a
prior
issue
before
it
was
moved
to
the
github's
working
group
org,
and
so
we
ended
up
doing
you
know
enabling
that
per
the
earlier
request-
and
you
know
I'll,
just
yeah
I'll
volunteer
to
to
set
that
up.
I
won't
volunteer
to
to
address
all
of
the
discussion
issues
every
time
and
that's
something
that
needs
to
be,
as
you
should
right
exactly.
B
F
More
things,
one
of
the
things
that
we
need
to
do
to
get
into
the
cncf
calendar
which
we
want
to
do
is
that
we
need
to
decide
on
a
regular
monthly
cadence,
not
choose
a
date
from
one
to
the
next.
So
we
need
to
choose
something
that
we
can
put
into
the
calendar
like
the
first
monday
or
the
third
thursday,
or
something
like
that.
So
that's
something
that
we
need
to
do
and
get
we
can
get
that
into
the
calendar,
and
we
can.
F
A
F
The
other
thing
is
that
we
need
to
go
through
a
process
of
electing
co-chairs,
which
is
something
that
we
should
do
on
the
slack
channel,
and
probably
this
is
something
that
also
falls
into
the
the
category
of
being
published
to
the
sig
mailing
list
as
well.
The
sig
app
delivery
mailing
list.
So
that's
something
that
we
need
to
take
on
is
the
election
of
co-chairs,
and
is
that.
F
G
F
D
B
B
They
can
accept
feedback
from
other
people,
but
that's
a
decision
made
by
the
current
the
the
current
folks
listed
in
the
I
think.
Currently
it
says
the
oversight
committee,
but
when
we
simplify
that
it
may
that
may
change
and
just
be
maintainers,
but
that's
how
it
stands
now.
Does
that
make
sense?
Okay,.
B
B
Yeah
it
it
it's
consensus
really,
so
it
anything
anything
like
that
is.
It
follows:
there's
the
governance
doc,
the
current
governance
stock
in
the
repo
figured
out
working
group
repo.
So
if
you
want
to
see
the
actual
details,
but
just
a
quick
summary
is
that
the
the
goal
is
for
there
to
be
full
consensus
through
discussion,
it
can
be
public,
it
doesn't
have
to
be.
The
decisions
will
be
made
public
for
sure,
but
it
sounds
like
the
intention
is
for
this
to
this
is
a
multi-uh
organization
project.
B
D
F
Yeah,
I
think
we
should
and
so
yeah
it
is
to
me
like
the
best
place
to
do
it
is
to
make
a
call
out
on
the
mailing
list
and
in
the
slack
channel
for
nominations
and
maybe
do
a
I'm
looking
at
you,
scott.
Maybe
you
can
help
us
or
others
can
chime
in
do
like
a
one
week
period
where
we
take
nominations,
and
then
you
know
a
one
week
period
for
voting,
and
I
would
I
would
I
prefer.
F
I
really
like
the
fact
that,
as
you
said,
scott
open
and
transparent
everyone
votes,
but
there's
binding
votes
and
non-binding
votes,
and
I
think
that
finding
votes
come
from
the
current
maintainers
and
the
non-binding
votes
come
from.
Anyone
who
wants
to
speak
up
and
I
and
if
we
have
some
kind
type
of
a
you
know
contention.
Then
we
can
deal
with
it,
but
I
don't
anticipate
that
we
will.
D
F
D
Okay
sounds
good
all
right.
Thank
you,
cornelia
for
the
updates.
The
next
is
the
website
update.
So
there
is
a
plan
to
do
a
formation
of
a
website
committee.
So
this
is
another
spot
in
the
notes.
I
think
we
should
ask
for
volunteers.
I
don't
know
daniel
if
we
had
an
owner
for
the
website.
I
think
I
suggested
it.
So
maybe
it's
my
thing
to
talk
about
unless
somebody
else
feels
we
have
a
to
do,
but
we
don't
have
an
owner.
I
believe
so
I'll
I'll
throw
my
name
on
that
one.
D
Basically,
I
think
what
we
discussed
is
putting
down
some
information
architecture
first
for
what
should
be
in
the
website
and
how
it
should
be
structured-
and
this
actually
goes
in
part
to
some
of
the
mission
of
gitop's
working
group
and
what
we
want
to
do
so,
if
you're
interested
in
this,
please
put
your
name
down.
I
think
we'll
do
under
the.
If
you're
interested
in
joining
the
principles
put
your
name
here
I'll
do
a
section
just
beneath
that.
That's
if
you're
interested
in
the
website
committee.
D
Put
your
name
there
and
then
just
just.
However,
I
should
contact
you
and
then
I'll.
Organize
kind
of
a
committee
discussion
and
and
circulate
with
the
group
stuff
done
in
committee,
of
course,
is
always
going
to
be
brought
to
the
group
for
approval.
So
as
far
as
participation
goes,
it's
not
like
you
know
it's
going
to
be
it's
going
to
be.
D
Oh,
this
committee
went
and
decided
now
it's
decided
like
it's
going
to
go.
You
know
they're
going
to
work
on
it
and
then
they're
going
to
present
it
to
the
community,
get
their
feedback
before
moving
forward.
I
don't
know,
there's
a
whole
well,
actually,
just
just
in
terms
of
some
of
the
ideas
we
were
talking
about,
trying
to
keep
it
fairly
simple
in
some
ways
where
we
want
to
have
you
know
here
are
the
here
are
the
principles
that
we're
following
this
is
similar
to
kind
of
the
ad?
D
H
A
D
Yeah
12
factor
we
talked
about
having
maybe
reference
architectures
that
people
can
use
what
we're
thinking
is
there.
There
are
a
lot
of
people
who
are
willing
to
work
on
githubs,
there's
a
lot
of
interest
in
this
area
and
really
a
lot
of
growth.
So
I
think
we
should.
We
should
architect
it
in
such
a
way
that
allows
for
a
lot
of
participation,
a
lot
of
additional
things
to
come
in
from
the
community
that
people
can
can
use
and
leverage.
D
D
Before
we
move
on.
There
was
a
question
in
the
comments:
what
are
the
requirements
for
co-chairs
and
is
it
suitable
new
people
to?
Is
it
suitable
for
new
people
to
this
working
group?
I
don't
think
we
have
a
hard
requirement
in
terms
of
like
you
know.
My
general
expectation
would
be
that
if
you're
a
co-chair,
you're
gonna
be
willing
to
dedicate
time
to
this
you're
gonna
be
invested
in
get
ops,
you're
gonna
care
about
it.
You're
gonna
be
good
at
working
with
the
community.
D
D
A
Yeah,
I
I
think
that
that's
largely
correct.
I
think
that
you
know
there's
a
certain
amount
of
time.
That's
going
to
have
to
be
committed
to
making
sure
that
the
this
becomes
and
stays
an
active
community
where,
as
git
ops
grows,
people
can
go
and
answer
questions
and
whatever
you
know,
needs
to
be
done
to
facilitate
that.
A
So
it's
not
a
definitely
not
a
passive
role,
so
you
know
there's
going
to
be
some
commitment,
and
so,
if
there's
you
know
a
product
that
a
company
that
someone's
working
for
is
directly
in
the
space
or
if
there's
you
know
someone's
maintainer
on
a
or
a
contributor
to
another
open
source
software
project,
if
they're
not
working
in
the
space
but
just
some
sort
of
demonstrated,
you
know
interest
in
seeing
gitops
move
forward.
I
think
is
probably
probably
pretty
helpful.
F
Yep
yeah,
yeah
and
sorry
I
was
I
muted-
to
go,
get
some
tea,
so
you
caught
me
when
I
was
downstairs
getting
tea,
but
yeah
I
mean,
I
think
it's
the
time
commitment
and
I
do
think
that
experience.
I
think
that
experience
is
something
that
folks
will
find
valuable,
because
we
want
the
co-chairs
to
have
the
domain
knowledge.
I
mean
there's
sometimes
this
idea
that
facilitators
need
there's
even
an
idea
that
facilitators
are
best
when
they
don't
have
the
domain
knowledge.
I
think
what
we
are
looking
for
in
in
co-chairs.
F
Somebody
actually
is
invested
in
the
domain
and
that's
a
fairly
vague
statement,
but
because
there's
different
ways
to
be
invested.
But
if
the
fact
everybody
that's
here
right
now
ever
anybody
who's
gonna
expressed
interest,
has
a
vested
interest
in
get-offs
and
has
some
experience
so
yeah.
That's
all
I
would
say.
D
I
I
just
noticed
that
I
am
so
far
the
only
person
on
the
website
committee,
so
I
look
forward
to
doing
whatever
the
hell
I
want
and
not
having
to
deal
with
any
any
talk
back
about
it
from
anybody.
No
just
kidding.
Please
please
go
sign
up
and
we
need
help
next
item
on
the
list
is
discussion
on
how
principles
will
be
translated
into
actions
in
the
future.
This
one
doesn't
have
a
name
on
it
is
somebody
want
to
claim
it.
A
Yeah
sure
I'll
talk
to
it,
it
was
something
that
was
mentioned
at
the
last
at
the.
The
last
meeting
was
just
a
discussion
of
what
that
what
comes
next
after
the
principles
are
defined
and
agreed
to,
and
I
think
something
that
that
a
lot
of
folks
have
discussed-
and
it's
certainly
been
discussed
amongst
ourselves-
is
what
are
the
actions
that
comes
out
come
out
of
the
principles
that
specifically
describe
the
use?
A
Cases
describe
not
just
use
cases
but
case
studies,
so
the
actions
are
the
principles
put
into
practice
right,
and
so
that's
what
I
think
the
goal
is
after
the
principles
are
defined,
and
I
know
that
there's
there's
some
some
people
who
have
thoughts
around
this.
But
again
we
don't
want
git
ops
to
be
something
that
is
abstract.
We
want
it
to
be
very
understandable
in
terms
of
how
it
can
be
put
into
practice
in
the
real
world,
so
these
use
cases
should
probably
then
have
reference
implementations
attached
to
it,
and
those
reference
implementations
should
use.
A
D
This
is
a
basic
pattern
I
could
follow
and
I
can
adapt
and
do
what
I
need
to
and
people
can
add
on
to
them,
and
that
could
be
a
great
collaboration
space
and
there's
a
lot
of
incentive
for
people
to
come
in
and
say:
oh,
you
know
what
we
really
want
to
do.
We
really
want
people
to
be
doing
git
ups
with
our
tools,
so
we're
going
to
give
you
a
reference
implementation
that
you
could
use
and
I
think
it
could
spur
a
lot
of.
C
Activity
that
note
around
kind
of
the
application
of
githubs
there's
already
a
fair
bit
of
thought
in
there.
It's
just
commented
out
right
now
and
there
are
several
files
that
I've
already
that
are
just
not
in
the
pr
at
this
moment,
they're
in
another
repository
that
go
into
this
kind
of
stuff,
because
we
I
think
patterns
were
have
been
talked
about
already,
and
we
have
a
couple
of
directions
for
patents
that
are
pretty
clear
and
well
defined.
C
So
I
think
once
the
principles
are
kind
of
done
and
agreed
on,
and
we
can
kind
of
merge
that
commit
merge
that
pr,
then
I
think
it'll
be
a
really
good
time
to
kind
of
split
that
up,
so
it
should
be
either
the
next
meeting
or
the
meeting
after
that
that
we
can
say
hey,
let's,
let's
grab
some
use
cases
and
actually
define
some
some
clear
use
cases
and
some
clear
patterns.
I
think.
B
I
think
we're
good
to
move
on.
Okay,
just
just
a
quick,
a
quick
thanks,
breese
for
saying
that
yeah,
please,
in
that
pr
that
we're
looking
for
feedback
on
well
we'll
be
we'll
be
looking
for
feedback
on
we'll
be
looking
for
feedback
on.
Actually,
it
looks
like
that's
my
next.
That's
my
next
link
that
we
will
be
looking
for
feedback
on.
There
are
specifically
look
at
the
readme.
That's
just
what
I
wanted
to
mention
on
for
brees's
contribution
to
that
conversation.
B
B
Yeah,
I
I
just
realized-
I
just
kind
of
interrupted
myself
so
inception
for
the
win.
Okay,
so
yes,
there's
a
couple
a
couple
of
things.
The
first
thing
I
want
to
mention
actually
also
can
someone
please
take
some
notes
under
this,
so
yeah
I'll.
Do
it
yeah,
I'm
gonna,
take
notes
on
myself,
okay,
just
avoiding
future
inception
here,
thanks
dan
yeah,
so
the
very
first
thing
I
wanted
to
mention
is
that
breese.
B
The
question
for
me
is
the
very
first
question
I
have
is:
how
do
we
reconcile
that
right
now
amongst
ourselves
like
do
we
want,
because,
essentially,
a
pr
in
the
main
repo
is
asking
for
feedback?
That's
essentially
what
a
pr
is
so
should
we
close
it
for
now
and
then
just
reopen
it
when
we
know
we
want
feedback.
A
C
Yeah
you're
me
you're,
muted,
bruce
as
a
kind
of
halfway.
I
suggest
we
could
turn
it
into
a
draft
to
make
it
clear
that
this
is
not
supposed
to
be
merged,
but
so
we
can
do
kind
of
so
that
the
the
what
what
we're
going
to
end
up
calling
the
principles
committee
can
do
their
work
in
public
so
to
speak.
Would
that
be
a
good
alternative?
Or
do
you
just
still
want
to
just
close
the
pr,
and
we
can
reopen
one
later.
D
Yeah
it's
it's
kind
of
the
cat's
out
of
the
bag
in
a
way
since
it's
sitting
there.
So
I
think
I
think
there
was
just
some
hesitance
of
like
well.
Let's
try
to
let's
try
to
strengthen
a
little
bit.
You
know
and
make
sure
that
we
kind
of
have
consensus
among
like
the
maintainers
before
we
put
it
out
to
the
community
for
feedback,
but
it's
out
now
so
you
know
whatever.
C
And,
and
as
I
said,
this
is
just
a
kind
of
a
restricted
sample
of
some
work.
That's
been
done
in
other
repositories
anyway,
so
this
is
kind
of
just
the
work
on
there.
That's
actually
ready
to
to
be
to
have
another
pair
of
eyeballs.
There
is
more
that
will
end
up
in
here
in
the
future.
It's
just
that
this
is
what
we
have
that's
ready
to
review
now.
So
I
thought
that's.
Why
apologies
I
I
was
ill
last
week
and
and
missed
the
discussion
around
that.
B
B
Excuse
me,
one
that
was
actually
the
first
one
right,
so
it
sounds
like
our
our
our
consensus
was
was
turn
it
into
a
draft
yeah.
We
we
also
in
addition
in
that
pr
made
a
giant
warning
at
the
very
top,
with
a
warning
sign
and
everything
in
like
header,
like
h1.
That
says
this
is
a
work
in
progress,
so
hopefully
anyone
who
looks
at
that,
even
if
they
don't
notice
that
a
draft
means
a
draft,
will
see
that.
So
that's
good.
Okay.
B
So
then,
in
that
case,
I
want
to
clarify
to
everyone
what
we're
what
we
would
be
looking
for
feedback
for.
It's
not
the
highest
agenda
at
this
moment,
because
it's
in
draft
form,
but
if
you're,
if
you
want
to
look
that
sounds
like
that's,
that's
fine!
The
there
are
several
things.
One
is
the
main
thing
to
look
for
for
feedback
for
is
in
the
principles
document.
B
That's
the
the
currently
what's
called
the
principles
document.
That's
the
main
thing
you'll
see
in
the
diff
that
the
readme
was
also
updated
to
summarize
the
principles
and
then
link
to
the
full
document
and
just
to
be
clear
what
the
idea
was
there
in
case
it's
confusing
to
anyone
who's
thinking
about
this
is
that
we
want
a
short
form
of
this
to
be
able
to
put
in
various
places
where
the
long
form
would
just
be
too
long,
while
at
the
same
time
there
will
be.
B
The
idea
is
to
have
bullet
points
beneath
each
one
of
these.
These
principles
has
just
a
one
sentence:
description
that
are
also
important
to
tell
people
that
that
they
are
actually
implementing
the
get
ops
principles
into
what
degree
or
whatever
those
are
val.
They
are
critical
to
the
principle,
but
they
just
can't
all
be
added
everywhere
and
a
similar
example
would
be
12
factor
right,
as
was
mentioned
before,
or
something
like
simver
spec.
B
You
know
there
you
can
summarize
the
the
10
items
on
their
own
but
to
to
really
know
that
you're
following
simver,
you
have
to
have
it
encapsulated
in
the
document
so
that
that's
what
we
were
shooting
for.
So
thanks
for
for
that,
the
second
question
was
just
circling
back
to
the
name,
there's
already
an
open
issue
for
this
that
that
that
was
added-
and
it
was
discussed
already
several
times
in
several
past
in
past
meetings.
B
Should
I
don't
know
that
we
need
to
define
it
now,
but
if
you
could
comment
just
to
keep
this
meeting
shorter
or
my
part
of
it
shorter?
If
you
could
comment
on
that
issue,
or
maybe
we
can
even
open
the
discussion
topic
as
we
were
just
talking
about
with
cornelia,
perhaps
that's
the
way
to
go
if
we
want
to
have
more
discussion,
but
either
way,
what's
in
a
name
right,
should
it
be?
B
Should
it
be
principles
as
it
was
in
the
beginning
manifesto,
almost
everyone
seemed
very
lukewarm
on
you
know
it's
a
good
summary,
but
but
it
just
seems
like
it's
a
fairly
loaded
term,
and
I
just
wanted
to
note.
I
just
wanted
to
summarize
the
discussion
so
far
that
someone
had
mentioned
pillars
as
well
and
principles
primarily
to
make
clear
that
these
are
not
criteria
they're,
not
hard
criteria.
C
And
that
should
be
made
explicitly
clear
in
the
pr
in
the
document
itself.
I
think
that's,
let's
draw
now
explicitly
that
this
is
not
a
specification
necessarily,
but
that
we
can
work
on
a
specification
as
part
of
this,
but
that
this,
what
we're
doing
right
now
is
not,
and
there's
there's
prior
art
for
specification
around
githubs
as
well,
that
can
be
brought
in,
but
that
this
is
not
about.
This
is
more
about
kind
of
the
direction
and
the
reason
we're
going
in
that
direction
rather
than
concrete
specifications.
B
B
Fyi,
it's
just
a
quick
fyi
that
was
carried
over
from
the
last
meeting
because
we
ran
out
of
time.
So
these
other
things
below
are
all
just
carried
over
from
the
last
meeting,
or
at
least
I
believe
they
are.
I
don't
know
about
this:
the
cornelius-
maybe
it's
not
that's
new
and
dan's,
maybe
that's
new,
but
anyway.
In
short,
if
anyone
has
this
was
announced
by
the
way,
but
if
anyone
has
a
local
repo
that
was
before
this
change,
you'll
have
to
you'll
find
out
soon
enough.
B
If
you
try
to
make
a
pr
or
whatever,
but
but
you'll
also
see
that
the
code
is
not
the
same
now,
but
because
things
have
changes
have
been
made
since
then,
but
essentially
there
was
git
history
by
committers
from
various
organizations
in
the
very
initial
just
temporary
location
for
this
repo
in
the
flux,
cv,
org
the
get
ups
working
group,
repo
and
the
flex
cd
work.
That
was
always
intended
to
be
temporary.
What
what
happened
was
it
was.
It
was
not
for
reasons
that
are
totally
legit.
B
It
was
not
initially
moved
the
the
repo
it
was
copied
over
and
the
history
of
all
those
committers
wasn't
there.
So
we
all
decided
yes,
let's
bring
that
history
in
and
none
of
the
content
changed
just
your
his
your
commits
are
there.
So
if
anyone
contributed
to
that
you'll
notice
that
your
name
is
on
there
as
committers,
but
what
that
means
is
practically
speaking.
You'll
have
to
do
a
you'll
have
to
make
sure
to
add
this
remote
and
do
like
a
pull
or
a
reset
hard
yeah.
D
B
B
One
thing
we
really
ultimately
need
a
a
series
part
of
I
think
the
get
ops
working
group.
We
ultimately
probably
need
a
series
on
on
git
in
the
concept
in
the
context
of
git
ups,
because
there
are
a
lot
of
neat
little
tricks
and
important
things
to
note.
For
example,
if
we
had
started
with
an
empty
commit
in
both
repos
this,
wouldn't
that
would
not
have
been
a
problem.
B
We'd
still
have
to
re-write
history,
but
it
would
make
updating
that
for
users
who
have
existing
code
locally
to
to
do
that
without
fussing.
But
what
we'll
do
is
if
anybody
has
a
question
just
reach
out,
and
we
can
send
some
commands
to
help
you,
your
local
or
just
delete
and
reclone
okay,
perfect.
Yes,.
D
C
No
currently,
there
are
two
reviews
required
for
to
actually
to
actually
merge
a
pr,
rather
than
just
the
one.
So
two
commit
two
committee:
two
maintenance
are
required
to
approve
any
pr
which
means
that
if
a
maintenance
puts
together
a
pr,
then
that
requires
three
maintenance
to
get
that
pr
merged.
B
B
Well,
there
are,
there
are
some
options
that
we'll
look
into
that.
I
think
there
are
some
fun
options
about
requiring
certain
certain
things
for
for
people
with
push
access
or
not.
So
I
can
look
into
that.
I
don't
think
I
don't
think
that's
an
option,
but
I'll
just
double
check
all
right.
Yeah
all
right
talking
about
github,
specific
configurations
here,
I'll
just
double
check
that
one.
D
E
I
J
C
B
D
Can
we
actually
just
open
it?
Let's
open
it
as
an
item
for
discussion,
because
not
all
the
maintainers
are
here:
let's
open
it
and
make
sure
that
there's
discussion
there
right,
I'm
not
super
worried
about
it,
but
just
by
way
of
setting
a
good
consensus
building
process,
I
think
we
should
put
it
into
an
official
issue
and
then
have
people
discuss
first
yeah.
A
I
Just
a
single
maintainer
to
get
started.
No
that
was
yeah.
I
know
what
you
said
so
one
maintainer
to
sign
off
and
a
reviewer
and
yeah
honestly.
If,
if
the
reviewer,
it
doesn't
have
to
be
two
because
of
the
if
the
reviewer's,
a
maintainer,
they
can
just
merge,
I
mean
that's,
you
know
getting
things
started
with
oci
run
time:
image
spec
the
stuff
we
did
around
serverless
messaging,
that's
sort
of
how
we
started.
I
D
B
J
D
D
F
For
example,
having
you
know,
the
get-ups
working
group
represented
at
cdf
events
vice
versa.
Things
like
that,
and
so
this
is
one
thing
that
we
as
a
group
should
do,
is
decide
how
what
types
of
activities
we
want
to
do
to
support
each
other,
because
git
ops
is
obviously
something
that's
of
interest
to
the
cdf
as
well,
so
we're
in
the
cncf,
but
we
want
to
partner
with
the
cdf,
and
the
cncf
is
very,
you
know,
obviously
open
and
encourages
that
type
of
collaboration.
C
F
F
D
Let's
see
next
discussion
was
from
me,
so
sponsoring
orgs
I
wanted
to
as
we
get
as
we
approach.
This
get
ops
principles
document
I'd
like
to
think
about
having
companies
make
official
commitments
on
those
as
like
something
they
can
sign
their
name
to,
and,
and
you
know
we
launched
the
adopts
working
group,
we
were
able
to
say:
oh
we've
got
these
five
companies.
Basically
we're
saying
we
think
git
ups
is
important.
D
D
B
B
The
idea
is
that
it
will
be
a
persistent
set
of
of
foundational
principles
and
and
guides
and
things
even
things
like
certifications
or
whatever
else
comes
down
the
pipeline
that
relates
to
git
ops.
My
question,
ultimately
my
suggestion
and
I'm
looking
for
feedback
is:
could
we
I
think
I'm
looking
at
you
cornelia,
but
also
anyone
on
the
call
too?
Would
it
make
more
sense
to
rename
the
project
something
like
get
ups
initiative?
F
I
was
just
gonna
say
I
think
that
makes
all
the
sense
in
the
world
because
it
kind
of
it
it
it
and
un
confuses
the
whole
thing
about
wait,
a
minute,
a
working
group,
what
working
groups
or
sandbox
projects
like
no
it's
it's,
it's
actually
a
problem
of
naming
it's
not
a
problem
in
concept,
it's
a
problem
of
naming
and
so
you're
addressing
the
you're
you're
saying:
okay.
Well,
let's
solve
the
problem
instead
of
explaining
around
the
problem,
which
is
to
to
name
the
project
appropriately.
D
I
I
don't
I
don't
have
an
opposing
view,
but
I
just
historically
speaking
working
group
actually
is
how
cncf
sandbox
projects
that
I've
been
involved
with,
that
weren't
attached
to
sort
of
an
implementation
have
been
approached
in
the
sort
of
the
cloud.
So
the
serverless
event
management
stuff.
That
just
became
a
bunch
of
different
things,
was
initially
a
working
group
and
exactly
like
you
just
said
dan.
I
B
D
C
To
the
floor,
a
final
note
just
really
quickly
that
there's
been
some
questions
in
the
document.
So
I
think
the
two
streams
of
the
principles
and
the
website
are
gonna
be
offline
and
organization
will
be
asynchronous.
On
slack,
there's
already
a
github
principles,
slack
channel
in
the
cncf
I'd
expect
we're
going
to
get
a
another
one
for
the
website,
and
then
we
can
work
and
coordinate
through
those.
K
Moshi,
yes
hi
everyone,
so
I
have
an
initial
comment.
So
one
of
the
the
get
ops
principles
that
I've
always
subscribed
to
is
everything
in
git
and
not
just
code
and
we've
been
talking
a
lot
about
get
up
discussions
and-
and
these
don't
seem
to
have
a
place
in
a
get
ops
working
group
and
then
I'd
go
so
far
as
to
say
issues.
Don't
have
a
place
in
the
get
ops
working
group.
K
A
A
Well,
there's
it
depends
how
far
you
want
to
take
it,
but
I
think
if,
if
you
put
the
output
into
git
right-
and
so
maybe
what
we
can
do-
is
copy
and
paste
the
notes
at
the
end,
every
meeting
and
that
becomes
a
a
a
sub
dot
md
file,
as
opposed
to
living
on
forever
in
in
google
docs.
Maybe
we
do
the
same
thing
with
a
discussion
when
it's
closed.
A
C
The
context
is
great,
but
I
think
the
decisions
is
what
needs
to
be
versioned,
and
so
we
can
transact
between
decisions,
but
there's
a
a
gap
for
human
process
in
between
that
doesn't
necessarily
yeah,
christendom,
single
source
of
truth
that
doesn't
necessarily
need
to
to
be
in
git
per
se.
I
I
don't
yeah.
K
B
This
is
this:
is
my
two
cents.
Could
I
make
a
suggestion
about
about
an
action
item
for
your
two
cents
rather
than
I
I
do
have
thoughts
and
I,
but
but
rather
than
I
know,
we're
over
meeting
time.
Could
you
add
your
thoughts
into
the
existing
principles.pr,
because
that's
really
where
the
get
ops
principles
are
defined,
and
I
think
at
this
point
you're
you're
sort
of
saying
how
far
should
we
take
the
principal?
B
Should
we
take
it
to
everything
that
we
do
and
so
on,
and
I
feel
like
if
that
requires
its
own
dedicated
discussion,
then
we
can
use
discussions
for
that.
I
know
you're
asking:
should
we
use
discussions
but
right
now,
that's
what
we
have
so
until
what
you're
suggesting
is
proposing
a
change.
So
github
discussions
are
already
set
up
on
the
repo
for
you.
A
B
Ultimately,
you're
right
daniel
and
what
I
was
going
to
say
is
ultimately
what
most
the
example
most
you've
suggested
is
that
you
know
say:
you've
got
a
pr
and
you've
got
comments
on
the
pr
do
because
of
vendor
locket
github
decided
in
its
early
architecture,
not
to
use
get
notes
for
that.
So
so
those
comments
are
not
stored
in
any
way
they're
stored
only
in
github
proprietary
service.
Any
of
this
stuff,
not
just
discussions
but
pr's
issues.
B
None
of
that
is
actually
pure
get
you
don't
get
any
of
that
unless
it's
commit
comments.
So
the
fact
that
you
wanted
to
discuss
it
here
in
zoom,
I
think,
is
also
a
little
bit
telling
too
you
didn't
discuss
it
in
a
given,
for
example,
you
know
it's
not
anyway
I'll
save
the
rest
of
mine
for
for
for
for
replying
to
your
discussion.
If
you
want
to
open
one.