►
From YouTube: OCI Weekly Discussion - 2021-06-09
Description
Recording of the OCI weekly developer's call from 9 Jun 2021. Agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg?view#June-9-2021
B
Spec
is
editing
yeah,
so
the
first
one
here
is
image
spec
status,
so
this
is
basically
picking
up
conversations
and
I
think
this
ties
into
what
you
should
type
in
right
after
too.
I
think
this
is
all
kind
of
the
same
topic
so
feel
free
to
jump
in
nisha
with
the
specifics
as
we
go
about
six
weeks
ago
now,
maybe
eight
weeks,
I'm
losing
track
of
time.
B
We
had
a
couple
different
change
proposals
being
discussed
for
image
spec,
which
led
to
realization
that
the
image
spec
maintainers
the
list
was
stale
phil
and
chris
shameless
foundation.
Graciously
helped
fix
that
situation,
there's
still
a
bunch
of
pending
prs
and
votes
and
proposals
to
add
new
and
replace
inspect
maintainers
a
little
bit
more.
But
it's
been
about
four
weeks
since
the
last
change
to
any
of
those
happen.
So
I'm
going
to
revisit
this
topic.
D
And
so
I
think,
as
far
as
the
first
line
on
that
is
image,
spec
frozen
as
much
as
I
can
do
so
I'll
definitely
say
it
is
not
prison,
but
anybody
else
is
welcome
to
add
in
why
they
do
think
it
is
frozen.
I
think
I
think
to
your
other
question
of
like
how
to
handle
versioning
and
backwards
compat.
That's
that's
should
be
navigated.
D
D
B
Oh
no,
I
just
mean
that
those
can
stay
open
for
as
long
as
we
need
it
do.
We
think
we
have
enough
quorum
now
from
the
existing
changes
to
actually
push
some
of
these
things
forward.
Now
the
problem
last
time
was
just
there
wasn't
really
quorum
at
all
anyway
and
I
think,
there's
probably
quorum
now
of
people
responding
to
emails
and
stuff.
As
far
as
I
can
tell
one
person
stepped
down,
there
was
one
swap
and
then
one
email
address
got
corrected.
So
now,
there's
another
responsive,
maintainer.
D
B
D
F
F
F
There
seems
to
be,
there
seems
to
be
a
discontent
in
some
of
the
the
community
space
where
it
feels
like
you
end
up
mired
in
a
discussion
of
toxicity
when
things
are
brought
up,
as
opposed
to
as
opposed
to
everyone
actually
working
collectively
toward
a
good
understanding,
understanding
and
negotiated
end
goal.
We
seem
to
be
getting
no
my
way.
No,
my
way
is
what
I'm
kind
of
feeling
and
we're
not
we're
talking
across
purposes.
F
So
I
want.
I
just
wanted
to
draw
that.
I'm
not
kidding
when
I
say
this
is
happening
all
across
open
source
right
now.
I
think
covid19
has
put
us
to
the
edge
of
our
uncertainty
capabilities
and
every
last
nerve
is
frayed,
so
we're
seeing
this
in
every
community
I
work
across
so
just
recognize
it,
and
I
realize
they
did
my
video
recognize
it
pay
attention
to
it
and
then
try
to
avoid
it.
I
And
I
think
maybe
you
know
I'm
not
sure
how
much
is
worth
tossing
on
top
of
that,
but
I
I
think,
maybe
what
we're
experiencing
and
it's
what
we
kind
of
were
hashing
out.
You
know
six
weeks
ago,
trying
to
come
up
with
a
working
group
idea.
Is
that
the
oci
kind
of
reached
the
end
of
like
the
easy
stuff
like
like?
Oh
we're,
standardizing
things,
we
kind
of
all
our
tools
already
speak
these
languages,
these
apis
and
now
we're
kind
of
crossing
into
like
hey.
I
You
know
as
far
as
implementation,
but
I
think
sarah's
point
is
well
taken
that
that
it
almost
is
even
a
more
important
time
in
the
oci
than
ever
to
figure
out
how
to
work
together
on
things
we
can
do
collectively,
even
as
we
kind
of
figure
out
our
vendor
niche.
You
know,
as
far
as
where
we're
going
with
image,
signing
or
or
other
areas
that
you
know
have
very
you
know,
definitely
different
ideas
about
implementation,
so
I
think
that's
part
of
where
we
are
in
a
sense
in
the
oci.
G
D
D
But
to
sarah
to
your
point
also
it's
it.
It
is
something
that
I
feel
like
if
I'm
not
saying
it
to
other
people,
then
at
least
I'm
saying
it
to
myself
that
there's
always
this
like
push
to
remind
people
that
we're
all
we're
actually,
at
least
in
this
project,
sitting
on
the
same
side
of
the
table,
and
that
humans
very
naturally
will
make
an
us
versus
them,
and
thankfully
it's
not
the
first
time,
even
in
the
oci
that
we've
seen
this.
D
Even
you
know
me
when
I
was
working
at
red
hat,
red
hat
and
docker
had
a
lot
of
head-to-head
nonsense.
It
was
a
constant
thing
to
address
this
and
like
maintain
work
together
as
humans
that
were
working
towards
a
common
goal,
despite
whatever
was
going
on
there
and
some
of
the
personality
personalities
that
were
involved.
D
D
J
J
In
subsequent
discussion,
there
are
fundamental
issues
about
garbage
collection
and
reverse
links
that
are
complicated
and-
and
I
I
I
think
they
affect
all
of
the
proposals
that
change
the
way
that
links
work
in
the
registration.
Is
there
a
fundamental,
you
know,
there's
a
fundamental
changes
and
they
and
that
we
we
shouldn't
just
kind
of
it's
not
about
the
format,
it's
about
the
structure
and
what
was
possible
or
not
possible,
with
garbage
collection
and
circular
references
and
so
on.
J
I
think
this
is
so
I
don't
recommend
anyone
read
my
proposal,
that's
why
I
have
not
updated
it,
and
I
think
we've
made
some
progress
on
on
some
of
the
restrictions
that
garbage
collection
and
reverse
links
imply
for
the
overall
structure
of
it,
and
we've
made
some
other.
You
know
short-term
proposals
that
address
those,
but
it's
kind
of.
J
K
K
K
K
K
D
Is
yes,
I'm
interested?
I?
I
did
just
also
want
to
say
on
the
on
the
image
image,
spec
frozen
thing
and
like
topics
worth
pursuing,
and
this
almost
goes
into
the
the
proposals
and
working
groups
which
hopefully
might
segue
into
what
you're
saying.
Misha
is
in
the
past
when
we
were
either
getting
ready
for
a
1.0
release
or
otherwise
that
we
end
up
setting
up
out
of
band
times
to
either
effectively
do
grooming,
but
just
to
work
through
different
topics
and
otherwise
and
kind
of
leave.
This
leave.
D
This
call
for
big
topics
that
kind
of
bubble
up
and
not
easily
agreed
upon
kind
of.
In
that
same
vein,
would
would
folks
either
be
open
to
the
idea
of
setting
up
a
time
or
say
image,
spec
or
otherwise,
just
to
start
going
through
kind
of
grooming
and
kind
of
like
rekindling
the
fires
and
direction
of
that
project.
Almost
as
its
own
working
group.
D
Form
because
I
mean
like
some
of
these
topics,
even
just
now,
I'm
like
going
through
and
seeing
that
I
can
close
like
I
just
closed
out
actually
like
four
things,
just
because
they're
they're
stale
and
there
were
things
that
I'd
opened
up
and
otherwise,
but
just
like
that
kind
of,
like
getting
momentum,
sometimes
takes
a
little
bit
of
crowdsourcing.
It.
D
J
Sorry
I
might
explain
that
if
image
space
changes
need
changes
to
the
distribution
api,
then
they're
not
just
image-based
changes,
and
so
how
do
we
coordinate
those
across
different
things?
Because
I
think
that's
part
of
the
issue
with
these
changes.
They're
not
really
commissioned
by
changes
at
all
they're
global
changes
to
how
registries
work
and.
D
Some
of
those
very
much
should
be
tagged,
and
I
think
that
I
think,
that's
broadly
the
the
concern
when
folks
are
wondering
if
things
are
backwards
compatible
or
if
a
version
changes
enough
to
track
it.
So
there's
there's
a
good
cut
mark.
You
know
to
figure
that
part
out,
but
I'm
just
talking
about
even
kind
of
breathing
life
into
the
project
enough
to
where
that.
That's
that's
a
healthy
enough
conversation
so
folks
don't
feel
like
there's
hand
waviness
that
it's
going
to
be
breaking
changes
or
backwards
incompatible,
but
actually
a
very
familiar
conversation.
G
D
No,
not
necessarily
I'm
just
saying
in
in
these
kind
of
like
discussing
those
proposals
and
how
like
how
far
reaching
they
might
be,
is
kind
of
rekindling
life
and,
to
some
extent
we
have
now
a
few
conversations
like
you
know,
small
tweaks
to
the
image
spec
or
small
tweaks
to
the
distribution
spec
or
broad
reaching.
You
know,
working
group
type
things
basically
for
the
health
of
those
kinds
of
working
groups
or
even
comfort
with
knowing
that
a
small
change
is
not
going
to
have
cascading
effects
there.
D
D
H
M
M
There
was
lots
of
activity,
but
as
those
first
two
specs
kind
of
came
over
the
finish
line,
the
tob
hasn't
exactly
been
active
and
those
two
spec
groups
haven't
been
very
active,
just
the
third
spec
group,
so
we're
now
back
in
a
situation
where
folks
want
to
resurrect
the
image
spec
discussion-
and
that's
that's
rightly
going
to
take
time,
but
you
need
the
the
groups
to
be
active
again
so
that
folks
know
how
to
have
a
specification
discussion
so
that
things
don't
I
mean
justin's
example.
Right
now
is
a
pretty
scary
one.
M
D
G
G
G
G
You
know
what
are
what
are
the?
What
are
the
things
that
are
referencing
this
manifest,
but
there
seems
to
be
like
other
requirements
that
we're
not
we're
not
talking
about
or
we're
slightly
talking
about,
but
I
don't
have
a
good
handle
on
it.
So
I
thought
I'd
open
that
up
for
this,
like
just
for
consensus,
you
know-
and
I
know
it's
been
going
around
in
all
the
different
pr's,
but
that's
the
problem,
it's
all
going
on
in
different
pr's
and
I
don't
think
they're
like
really
talking
to
each
other.
So.
B
K
B
Difference
between
the
two
is
that
between
the
two
options,
without
not
talking
about
justin's,
is
that
this
one
aims
to
be
the
minimal
change
to
accomplish
those
requirements
and
kind
of
a
thought
experiment
to
see
if
we
can
do
it
without
a
new
schema
version
without
a
whole
new
version,
a
major
one
and
that's
what
we
need:
the
feedback
from
the
inspect
maintainers
and
the
distribution
spec
containers.
For
if
we
can't
do
this
without
bumping
them
major
version,
then
you
open
the
other
can
of
worms
of
okay.
B
And
I
think
that's
kind
of
the
big
one,
the
big
difference
in
direction,
if
I
could
put
it
simply
is,
can
we
do
this?
Get
that
refers
to
requirement
done
without
changing
major
versions?
Should
we
do
people
think
there's
usefulness
there,
or
should
we
bump
the
major
version
and
fix
up
everything?
At
the
same
time,.
G
G
What
it
doesn't
cover
is
the
ability
to
link
many
different
images
together
in
some
kind
of
like
you
know
something
that
says
that
oh
I'm
an
image,
but
I
need
in
order
for
me
to
run.
I
require
this
other
image,
so
it
doesn't
cover
a
dependency
graph.
I
guess,
if
you're
talking
about
a
high
level
application
that
has
many
different
images
working
with
it
does
that
summarize
I
mean.
Does
that
make
sense
to
folks.
H
G
My
feeling
is
that
this
change,
the
change
that
allows
the
the
merkle
tree
linking,
I
think,
that's
a
reasonable
change
to
make,
because
this
is
json
and
references
at
the
end
of
the
blob.
And
so,
if
a
client,
a
client
can,
you
know,
go
further
down
the
blob
only
if
it's
looking
for
a
reference
and
otherwise
will
not
touch
it.
G
O
E
L
E
A
I
I
think
it's
not
that
it's
we're
not
trying
to
mandate
any
garbage
collection.
I
think
we're
trying
to
recognize
that
the
specs
have
a
certain
amount
of
usage
and
a
certain
amount
of
functionality,
and
how
do
we
propose
changes
that
support
those
capabilities
and
make
it
realistic
for
the
services
and
the
products
and
the
projects
to
be
able
to
implement
that
in
a
way
that
can
be
achievable
like
this
is
the
the
canonical
the
catalog
api
problem
like
we
need
to
prove
out
that
these
things
work?
A
What
are
the
impacts
of
it,
and
is
it
actually
achievable,
which
is
kind
of
the
point
I
thought
was.
The
working
groups
is
there's
some
really
simple,
simple
changes.
You
know
we
could
talk
about
the
annotation.
One
has
always
been
the
simple
one
to
me
because
there's
no
real
expectations,
it's
a
communication
path
with
no
expectations
on
either
side
and
then
there's
this
stuff
with
the
references
which
is
a
reverse
index
as
brandon
was
just
talking
about
it.
A
Just
it
doesn't
get
much
more
impactful
to
the
various
specs
across
the
board
than
to
do
something
like
that.
So
I
think
that's
the
part
of
what
we're
trying
to
do
with
the
working
groups
is
to
figure
out
what
does
it
mean
to
do
this?
How
far
can
we
go?
How
far
do
we
need
to
go
and
then
validate
those
do
some
do
some
implementations
get
feedback
iterate
and
then
once
we
actually
have
solid
feedback
and
solid
confidence
in
it,
then
there's
a
pr
to
be
made
to
wherever
it
makes
sense.
K
So
I
think
I
think
the
point
is
that
there
are
multiple
options
for
garbage
collection.
Certain
registries
might
want
to
aggressively
garbage
collect.
Certain
registries
might
never
want
a
garbage
collect
and
there's
certainly
use
cases
for
both.
I
think,
if
the
sticking
point
is
how
is
garbage
collection
supposed
to
be
recommended,
like
I
don't
think
we?
P
D
G
G
D
D
H
O
I
think
there's
still
some
optionality
in
there,
because
any
registry
that
doesn't
implement
the
garbage
collection,
for
whatever
respect
we
have
is
going
to
look
at
something
like
that,
and
it's
going
to
see.
Okay,
I've
got
the
tag
point
to
this
index,
that's
pointing
to
this
manifest
and
then
this
other
thing
is
just
hanging
out
here.
That
has
nothing
because
it
doesn't
know
what
a
reference
is,
and
so
it's
just
going
to
delete
that
other
thing.
So
the
worst
case,
it's
just
going
to
get.
K
J
J
A
So
that
we
can
work
through
these
things
and
we
can
do
parallel
working
groups
if
we
can't
agree
on
one
way
to
do
reference
types,
then
there
could
be
parallel
groups,
and
I
think
the
point
is
is
that
this
is
something
that
just
needs
time
to
incubate
and
hopefully
done
in
you
know
collaborative
ways
so
that
it
can
work
across
registries,
because
that
is
the
point
that
we're
all
here
and
then
with
that,
then
we
can
decide.
You
know,
maybe
niches
diagrams
are
great
ways
to
kind
of
facilitate
the
comparisons.
B
A
B
D
I
think
it's
one
of
those
that
how
best
how
best
can
we
experiment
with
that
before
actually
pushing
it
out
there?
And
you
know
just
that's:
that's
the
part
where,
in
the
past,
we've
we've
leaned
very
heavily
on
some
aspect,
most
aspects
of
the
oci
being
in
kind
of
a
trailing
spec
of
what
folks
are
already
doing
in
the
wild
and
saying
actually,
here's
the
lessons
learned,
rather
than
designing
something
that
we
later
find
that
doesn't
work
well
in
production.
H
B
I'm
not
asking
for
a
you
know,
concrete
decision,
no
vote
or
anything
like
that.
Like
do,
we
think
there's
are
we
seeing
any
hard
blockers
at
this
stage
to
you
know,
stop
and
go
stop
doing
this.
It's
not
going
to
work
completely,
don't
even
bother
trying
or
go
put
in
the
work
to
do
more
validations
and
experiments
and
try
this
kind
of
thing.
H
Yeah
as
we
chatted
the
other
day,
I
think
we
need
some
test
cases
at
the
distribution
level
to
check
it
across
the
registries
and
find
out
some
hard
details
on
whether
you
know
your
your
reference
proposal.
Would
you
know,
and
some
more
test
case
definition.
Work
like
nisha
was
saying:
she's,
not
sure
if
this
covers
her
her
use
case,
so
I
think
we
need
a
little
more.
You
know
work
on
the
definition
of
the
use
case
and
then
some
work
on
the
debt.
H
You
know
on
the
definition
of
test
cases
at
the
distribution
just
for
experimentation
purposes
and
and
that's
probably
going
to
need
a
worker
going
to
make
sure
that
we've
tweaked
the
right
clients
and
we've
tweaked
the
right
servers
to
make
to
see
if
we
can
make
that
work
and
then
on
the
other
side,
you've
also
got
steve's
got
a
great.
You
know
his
own.
H
You
know
proposal
and
we
need
to
do
analysis
on
that
as
well
and
without
the
right
oci,
you
know
image,
maintainer
votes,
you
know
how
do
you
pick
one
or
the
other?
Well,
you
write
test
cases
and
you
get
together
as
a
group
and
say
which
one's
better
right.
I
think
it's
a
group
that
needs
to
be
done,
so
we
come
together.
B
H
H
O
H
What
is
the
scope?
There
would
be
one
scope
for
the
images
for
themselves,
the
containers,
whether
they
can
run
or
not
right
when
distributed
to
the
registry,
pushed
and
pulled
from
the
registry
and
run
on
that
machine
right,
that's
one
and,
and
then
across
multiple
versions
of
those
registries
and
multiple
versions
of
those
clients
right.
H
B
Yeah,
so
there
is,
I
do
have
a
basic
table.
I
tested
a
small
matrix
of
those
things
and
put
the
results
in
here.
I
didn't
get
any
other
requests
for
other
ones.
To
try.
Well
definitely
like
this
is
not
exhaustive,
but
I
it
exhausted
my
creativity
of
things
different
test,
matrix
matrices.
We
could
try
so
there's
some
due
diligence
down
here,
but
I
just
didn't
get
much
feedback
or
anything
on
other
stuff
to
go.
Try
in
terms
of
did
this
client
ignore
this
field
properly.
Did
this
registry
ignore
this
field
properly?
A
I
think
the
piece
that
we're
getting
overly
focused
on
is
some
text
in
a
json
document
and
thinking
that's
the
extent
of
it.
The
purpose
of
putting
the
text
in
the
json
document
is
to
provide
some
behavior
that
users
would
have
as
expectation
from
the
services
and
to
put
an
annotation
in
it's
just
passive.
It
goes
back
and
forth.
A
Some
registry
decides
to
index
that
great,
that's
great
value,
add,
but
I
think
we're
talking
about
something
like
references
well,
they're
useful,
if
there's
an
api
and
to
be
able
to
get
the
information
back
out,
that's
that's
something
that
needs
to
be
added.
There's
an
expectation
that,
if
that
api
is
there
that
they
can
get
the
data
out
and
if
a
registry
is
accepting
some
piece
of
content
that
has
this
passive
property
on
it,
that
is
on
a
version
that
may
or
may
not
be
supported
because
of
how
registry
implements
versioning.
A
What
does
that
mean?
So
if
we
start
pushing
something
in
that,
doesn't
have
a
tag,
let's
say
and
does
it
is
expected
to
stay
there?
Does
it
just
disappear?
I
think
that's
the
part
like
I.
I
don't
think
the
the
major
piece
to
this
is
the
elements
that
show
up
in
some
schema
or
another.
It's
the
behavior
that
we're
talking
about.
H
I
think
it's
also
important
to
point
out
steve
that
your
your
idea
was
talking
about.
You
know
a
new
type
right.
It
wasn't
an
oci
image
type
change,
it
was
a
it
was.
It
was
an
image
for
for
your
artifacts
right.
You
know
cia
artifacts
type,
which
would
in
fact
be
different.
So
therefore
no
backwards
compatible
issues
right.
O
But
I
guess
kind
of
trying
to
think
back
to
what
do
we
mean
by
backward
compatible
if
the
artifact
spec
was
to
try
to
push
the
registry
saw
the
registry
didn't
support
it
and
just
fell
back
and
said?
Well,
I
can't
work
without
registry,
so
I'm
just
going
to
fall
back
to
the
old
behavior,
not
pushing
artifact.
O
O
Yeah
and
that
that's
why
I'm
pushing
back
when
I
hear
that
it's
it's
not
backward
compatible
at
the
if
the
registry
server
doesn't
support
it,
because
it's
the
client
just
know
hey
that
registry
doesn't
support
it.
So
we
are
back
we're
compatible
by
just
not
pushing
the
artifact
out
there,
and
so,
even
though.
H
O
O
I
also
don't
even
consider
that
a
bug
if,
if
we
know
the
registry
may
not
handle
that
field
and
that
it's
just
not
going
to
do
anything
special
with
it,
then
we
can
use
as
part
of
the
spectrum.
So
that's
kind
of
when
we
look
at
the
the
data
field
that
we've
been
talking
about,
of
how
to
add
an
extra
data
field
into
the
manifest.
That's
relying
on
some
registries
just
don't
know
what
to
do
with
it,
but
it
doesn't
matter.
It's
just
extra
data
that
gets
ignored.
A
That
one's
a
little
bit
more
complicated
because
it
was
captured
as
a
reserved
element-
and
it
wasn't
scoped
very
well
so
that
one's
a
little
bit
more
nebulous
to
deal
with
it
does
have
the
ability
to
really
impact
services
with
an
expected
behavior
of
what's
used
today.
So
I
try
to
avoid
the
data
one
just
because
it's
wrapped
in
a
in
a
reserved
spot
and
ultimately
it
doesn't
fund
them
in
itself,
doesn't
solve
any
of
the
problems
we're
trying
to
solve
here.
A
A
A
A
A
E
I'm
biased
because
I
sent
the
pr,
but
I
think
the
data
pr
is
in
fact
an
example
of
something
that's
really
easy
to
merge
and
not
complicated
or
admired
in
in
technical
technicalities.
It's
like
in
my
opinion.
That
is
an
example
of
something
that
is
very
trivially
backwards,
compatible
and
is
an
easy
yes
for
me,
but
if
you're
saying
that
is
more
complex
than
something
else,
I
think
we
are
operating
under
different
models
of
how
it's
an.
H
H
A
It's
called
april
what
I
mean
by
complex
it's
complex,
because
it
was
a
reserved
field
and
now
we're
defining
that's
what
makes
it
complex.
The
actual
use
of
the
data
element
is
a
different
problem
in
that
it
it
can
bloat
registry
data
that
we're
caching
and
so
forth.
It's
nothing
it's
all
code.
What
am
I
you
know?
It
says
it's
just
code.
We
can
change
it,
it's
just
no
matter
when
and
where
and
how
and
why
should
we
change
it?
A
So,
I'm
just
saying
the
data
field
is
more
complex
because
it's
it
was
a
reserved
element
that
we're
trying
to
find
as
opposed
to,
and
even
if
we
approve
that
one,
it
still
doesn't
solve
the
problems.
We're
really
trying
to
it
doesn't
solve
the
bigger
problems.
What
we're
trying
to
do
here?
It
solves
a
piece
of
it.
B
So
maybe
I'm
confused
about
the
mental
model
of
what
happens
when
things
get
merged
and
the
versioning
and
everything
like
that,
like
a
version,
1.0
has
been
tagged
and
cut
on
that
spec
and
that's
immutable.
Now,
there's
a
shot
of
it
somewhere
floating
around
that's
immutable.
You
can't
make
a
change
to
that.
That's
version
one
stuff
can
get
merged
into
this
spec.
B
B
I
don't
know
if
that
answers
your
customer
question,
because
customers
don't
understand
the
specs
anyway,
if
most
people
here
rarely
do
myself
included,
but
I
think
like
that
would
be
like
if
you
implement
version
1.0
of
the
spec,
that
spec
cannot
change
on
you
that
is
frozen
in
time.
It's
defined
new
features
would
be
a
new
minor
version,
and
registries
would
implement
that
whenever
they
want
and
that's
an
easy.
J
Answer:
that's
not
really
how
I
work
today,
because
registries
don't
advertise
the
version
of
the
spec
they're
implementing
clients,
don't
look
it
up
before
they
talk
to
them!
Sure
it's
much
more
of
a
general!
You
push
and
pull
things
and
over
time,
and
you
wanted
to
con
the
things
that
you
used
to
do
to
continue,
working
and
and
so
on.
So
I'm
not
sure
that
that's
a
really
helpful
view
on
the.
D
D
To
some
extent
it
relies
on
even
the
thing:
that's
open
the
task,
that's
open
on
phil
of
like
this
kind
of
working
group
piece
that
we've
had
it
going
on
of,
like
here's
all
the
different
working
groups
that
are
going
and
here's
how
to
get
involved
in
them.
To
some
extent
it
relate
relate
relays
to
that,
but
now
that
we're
having
new
verbiage
around
that
there
there
are
and
have
been
existing.
You
know
groups
and
proposals
and
veins
of
thought
that
do
need
to
get
aggregated
up
into
that.
L
One
suggestion
that
came
from
some
of
our
discussion
about
kind
of
containers
in
hpc
is
that
it
would
be
really
nice
to
have
something
along
the
lines
of
like
an
rfc
document
for
a
lot
of
the
specs.
And
if
we
do
have
that
that
could
be
associated
with
working
groups
and
even
things
in
progress.
But
that
would
be
a
nice
place
where
you
can
put
diagrams
and
whatnot.
D
N
N
I
don't
think
the
kubecon
is
enough.
One
hour
at
kubecon
is
enough
time.
I
would
love
to
do
a
real
conference
for
oci
and
I
think
that
it
would
you
know
we
have
these
discussions
and
we
seem
like
we're
making
a
lot
of
great
progress
and
then
the
call
ends-
and
we
never
talk
about
it
again-
and
I
know
covet-
is
an
issue
and
all
that.
But
I,
if
anyone
can
help
me
I'd
love
to
help
organize
something
like
that,
maybe
in
the
winter
after
things
are
more
open
but
yeah.
D
N
N
D
D
There
you
go
okay,
so
yeah,
I
I
I
feel
folks
tensions
and
glad
that
folks
will
actually
bring
these
these
topics
up
to
conversation
points
so
for
the
sake
of
sounding
redundant.
We
are
all
here
to
be
on
the
same
side
of
the
table.
So
do
keep
that
in
mind
and
thankfully
we
all
do
hold
each
other
until
kind
of
the
code
of
participation.