►
From YouTube: OCI Weekly Discussion - 2021-07-21
Description
Recording of the OCI weekly developer's call from 21 Jul 2021; agenda/notes here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#July-21-2021
B
B
Work
next
steps,
and
even
even
like,
following
up
on
kind
of
the
email
thread
that
I
think
I'm
almost
declaring
email
bankruptcy.
I've
got
like
so
many
things
in
my
inbox,
like
all
the
oci
stuff,
goes
to
my
personal
inbox.
So
I
keep
like
oh
yeah
I'll
leave
that
in
there
because
I'll
get
back
to
it,
and
then
I
never
do
but
still
next
steps.
B
I
basically
I
was
I'm
two
ways
about
how
best
to
to
just
like
make
a
smooth
transition,
because
I
do
I
do
want
to
see
kind
of
a
table.
That's
just
like
a
referenceable
table
like
if
you
encount,
you
know
if,
as
a
client
or
registry
implementation,
you
encounter
certain
media
types
like
if
you
encounter
this
media
type.
Go
to
these
docs
just
know
what
to
do
with
it.
Like
case
in
point,
the
the
encrypted
layers,
like
I
see
a
media
type.
How
do
I
handle
it?
B
Y'all
had
after
I
posted
samuel
and
steve,
but
you
know,
even
if
it
was
something
like
sig,
artifacts
or
wg
artifacts,
if
we
just
like
rename
this
and
like
kind
of
like
make
it
clear
that
this
is
like
a
working
group
like
we
are
working
through
something,
and
it
has
very
clear
implications
on
what
is
currently
in
image,
spec
and
distribution
spec
and
we're
kind
of
like
working
it
out.
So
we
can
have
like
a
working
implementation,
proof
of
concept.
A
B
We
foster
so
she's
been
with
us
for
about
nine
months,
so
the
okay,
so
so
stuff
like
working
group
artifacts.
That
has
very
clear
implications
of
things
that
like
overlap
with
what's
in
distributions,
but
we're
still
figuring
out
what
those
exact
changes
are
and
they
overlap
with.
What
currently
is
in
like
image,
spec
and
we're
figuring
out
what
those
changes
are
and
those
kind
of
working
groups.
B
B
Those
kind
of
working
groups
will
lead,
hopefully,
the
kind
of
clear
conversation
like
we
had
during
the
image
spec
grooming
of
like
there's
this
manifest
concept,
there's
a
manifest
concept
that
clearly
is
its
own
spec.
That's
not
related
to
image
spec
at
all.
You
know,
like
maybe
there's
another
place
for
a
conversation
around
the
spec
to
exist,
but
it
was
born
out
of
the
working
group.
If
that
makes
sense,
so
initially,
first
step
could
be
as
simple
as
just
renaming
artifacts
to
like
sig
artifacts,
wg
artifacts.
B
A
I
think
we're
talking
two
things.
One
is
a
concrete
example
and
then
there's
just
the
larger:
how
do
we
do
incubations
in
oci
versus
you
know
it's
the
model
if
you
do
something
outside
and
try
to
bring
it
in,
which
is
what
you
know
the
docker.
Basically,
the
docker
implementation
was
and
then
we,
you
know,
brought
it
into
oci
and
we
being
proverbial.
We
always
hear
that
and
try
to
you
know
turn
that
into
a
spec
or
do
you
incubate
under
oci,
so
that
it
naturally
evolves
and
things
don't
have
to
change.
A
The
the
question
I
kind
of
have
is
you
know:
how
can
we
move
forward
because
we,
you
know,
we've
been
talking
about
this
for
a
long
time.
We
have
to
move
forward
like
I
think,
and
we
have
it
we
can
do
both
like
I
said.
Maybe
we
just
do
this
in
parallel,
we'll
go,
you
know,
go
forward
and
do
the
project
and
then
we'll
continue
to
do
this
in
parallel
working
under
oci,
and
we
can
do
it
keep
the
pr
going
or
we
can
do
the
incubation
under
oci.
A
If
we
can,
you
know
kind
of
unblock
that
work.
I
think
the
question
specific
to
this
one
is
like
artifacts
is
a
proved
project.
It's
a
thing
that
people
are
already
using.
There's
the
implementer's
guide.
I've
got
the
exact
name
of
the
url,
but
basically
there's
a
serious,
very
specific
doc.
That
says:
here's
how
you
use
the
manifest
types
and
two
implement
your
your
artifact
type.
I
said
manifest
types
well,
it
is
manifest
types
of
media
types
so
that
one's
concrete.
B
Then
then,
it's
if
it
basically
some
of
those
conversations
and
links
that
have
been
shared
broadly,
of
course,
what
I
was
talking
about
being
able
to
like
preserve
the
permalink
like
redirects,
the
github
redirects
on
for
some
of
those
links
that
have
been
shared.
Broadly,
I
don't
I
yes,
I
don't
want
to
revert
anything
particularly
like
if
there's
a
table
like
here's,
how
to
use
these
different
media
types.
A
Have
implemented
it,
so
it's
there
is
broad
adoption.
At
the
same
token,
that
gets
a
couple
of
conversations
that
create
a
lot
of
anxiety
for
folks
is
that
there
isn't
a
spec?
Is
it
released
so
to
take
something
that
and
we
keep
on
saying,
look
it?
It
is
done
it's
there.
It
doesn't
actually
have
a
release,
because
today
it's
really
defining
a
behavior
of
what's
defined
in
the
existing
specs
that
are
there.
A
So
the
the
thought
process
just
working
through
that
conversation
was
artifact
stays
where
it
is,
we
close
pr29
and
we
create
another
repo,
that's
wg
artifact
spec,
and
that
then,
is
where
you
know
this
new
spec
can
get
incubated.
I
they
don't
think
it
goes
to
the
image.
I
do
think
I've
always
thought
the
distribution
and
artifacts
and
the
spec
that
we're
talking
about
would
converge,
but
not
everybody's
there.
So
that's
why
we're
keeping
them
separate.
A
B
A
A
Well,
whatever
this,
whatever
this
new
repo
that
we
create
and
not
renaming,
one
like,
let's
leave
the
one
instability
of
where
it
is,
let's
create
a
new
one
and
then
that
new
one,
the
output
of
that
look.
If
we
knew
exactly
where
it
was
going
to
land,
we
wouldn't
be
asking
for
a
working
group,
we'd
say:
hey.
I
just
approved
this
thing.
It's
done.
The
whole
point
is
we
want
to
innovate,
incubate
and
churn,
and
we've
already
made
a
bunch
of
churns
and
a
bunch
of
changes
because
we
went
through
implementation.
A
A
B
A
We
can
decide
later
that
it
does.
You
know
the
files
from
this
new
repo
might
go
into
the
artifacts
project
and
maybe
the
artifacts
project
does
get
renamed
spec.
I
don't
know.
Maybe
the
stuff
goes
into
distribution
and
the
artifact
spec
gets
folded
into
distribution.
I
you
know
those
are
some
options.
We've
discussed,
I'm
not
ready
to
say
that
those
are
the
options
we
should
do.
Those
are
just
some
examples,
which
is
why
you
know.
I
think
we
just
need
to
let
it
play
out.
B
Yeah-
and
this
is
one
of
the
reasons
why
I'm
excited
about
the
you
know
the
coming
getting
some
some
language,
invertebrates
and
procedure
around,
enabling
folks
to
have
these
kind
of
working
groups
or
whatever,
so
that
we
can
have
proof
of
concepts
done
under
the
oci
umbrella
kind
of
an
open
governance
model,
because
that
is
very
important
for
a
lot
of
like
people's
work
and
cross-company
collaboration.
Because
again,
like.
C
Vince,
I
think
they're
two
separate
things.
I
think
we've
got
some
structural
changes
that
are
being
requested
to
be
made,
which
really
isn't
a
work
group
kind
of
thing,
and
then
we've
got
people
who
want
to
do
extensions
to
the
existing
specs
and
that's
more
of
a
work
group
kind
of
thing
right,
yeah.
B
Well,
yeah,
I'm
just
saying
like
in
general,
being
able
to
foster
this
kind
of
proof,
perfect
concept
under
the
oci
umbrella,
rather
than
the
the
the
path
that
oc
has
typically
been
in
of
like
it
happens
somewhere.
You
know
like
somebody
somewhere
innovates
and
it
becomes
an
industry
standard,
and
then
we,
you
know
nail
it
down
that
that
we've
kind
of
left
the
current
model
of
allowing
those
proof
of
concepts
to
happen
under
oci's
all
umbrella.
C
And
a
little
bit
of
the
the
inability
to
do
the
proof
of
concepts
is
around
some
of
the
structural
limits
that
we
have
and
currently
in
the
image
spec.
For
example.
Today,
one
of
the
things
that
steve
just
brought
up
with
something
that
stephen
you
know
stevo
brought
up
over
the
weekend,
which
was
you
know,
one
things
we'd
like
to
have
is
a
common
cast
model
right
and
if
we
had
that
and
we
thought
we
did
an
image.
But
image
was
a
little
restricted
and
very
focused
focused
on
on
the
image
specification.
C
If
we
had
a
cast
model
specification,
that
was
more
like
a
reference
and
then
image
built
on
top
of
that
which
it
already
does
right,
but
then
that
generic
cast
was
it
a
little
bit
more
extensible
to
be
able
to
support
things
like
artifacts
as
well,
where
artifacts
aren't
really
a
container
image?
So
why
would
you
want
to
have
a
container
image
config?
C
It
just
doesn't
make
sense
for
an
artifact
to
also
be
a
container
image
and
there's
other
dependencies
and
requirements
that
the
artifacts
guys
want
that.
I
don't
think
the
image
spec
team
would
want,
because
they're
trying
to
build
an
image-
spec,
not
a
artifacts
pack
right,
but
if
you
have
a
cast,
that's
common,
which
was
stevo's
recommendation.
C
You
know
not
not
in
a
little
discussion,
but
you
know.
If
we
had
a
little
cast,
then
we
could
build
these
other
two
specs
on
top
and
those
would
be
working
groups
that
would
be
off
trying
to
you
know,
prove
a
concept
things
that
were
you
know
more
more
interesting,
but
still
kept
to
the
same
basic
oci.
A
F
G
C
B
So
the
the
I
guess,
the
this
artifact
artifact
type
authors
you
know-
can
continue
referencing
this
way
of
using
or
specifying
different
media
types.
So
that's
like
the
purpose
or
whatever
of
like
the
artifacts
repo.
So
in
that
sense
leave
it
like
it
is,
and
then,
if
we
do
just
you
know
a
discussion
among
tmb
or
otherwise
to
say
this
look,
you
know
creating
a
new
repo
for
a
working
group.
B
Does
that
need
to
wait
on
the
full
working
group
model,
then
to
like
propose
that
whole
thing,
I
guess,
is
kind
of
a
question
then
so
for
not
just
renaming,
like
kind
of
like
continuing
on
the
purpose
of
directly.
What
kind
of
like
artifacts
is
a
working
group
and
success
criteria
that
it's
like
fully
met?
What
it's
set
out
to
do
like
done,
then
it
to
me.
A
Specifically
versus
ph
yeah,
I
look.
I
I'm
not
trying
to
make
this
more
complicated.
I
realize
it's
already
complicated,
so
I'm
looking
for
the
path
of
least
resistance-
and
you
know
from
my
cousin
but
he's
like
our
clock-
is
ticking
like
I,
and
I
don't
want
that
to
be
the
pressure
on
oci
it's
just,
but
we
have
to
we've
been.
You
know
this
has
been
a
very
monthly
long
decision,
so
if
there
is
a
a
way
that
we
can
unblock
it,
you
know
today
this
week,
then
awesome.
Let's,
let's
figure
out
how
to
do
that.
A
If
we
can't,
then
we
can
do
the
parallel
effort,
we'll
create
this.
You
know
this
other
spec,
this
artifact
spec
and
and
work
there
and
then
in
parallel
as
oci
figures
it
out,
we
can
figure
out
converge
it
up
if
it's
a
day
after
we've
done
the
work,
if
it's
a
month
after
or
if
it's
never
like.
All
of
those
are
okay
options.
I
just
I
I
I'm
looking
for
definitive
guidance
on
which
way
we
should
go
about
it
with
time
being
a
constraint.
G
Indeed,
our
theories
about
common
content,
distribution
primitives
were
well
founded
and
we
have
some
success
on
it,
and
now
we
got
some
people
pounding
the
table
to
turn
that
into
a
spec
and
the
I
mean
the
thing
is
called
open
containers,
and
so
now,
like
the
word
containers,
is
a
flexible
word
in
that
it.
It
typically
refers.
I
mean
in
our
context
it
refers
to
the
linux
containers
or
like
process
containers
or
whatever
you
want
to
call
them,
but
they
could
also
be
containers
for
things
like
artifacts.
G
That's
that's
neither
here
nor
there,
but
the
the
real
shift
that
I
think
we
need
to
make
in
oci
in
general
to
to
support.
This,
though,
is
is
kind
of
distancing
ourselves
from
the
thing
that
we
call
process
containers
to
containers
of
artifacts
and
distribution
and
make
oci
about
that
distribution.
Is
that
the
distribution
of
general
content
now?
Is
that
the
shift
we
want
to
make
as
oci?
G
Maybe
it
probably
we
should
I
mean
like
we
don't
like
there's
nothing.
I
can't
think
of
anything.
That's
that's
content.
Addressable
has
security
and
signing
and
a
whole
bunch
of
people
who
want
to
work
on
it.
Like
that's
a
that's
kind
of
a
rare
thing
to
see
in
the
community.
So
maybe
that's
something
that
oci
moves
into
now.
That
said,
I
think
the
taking
the
artifacts
project
and
turning
it
into
an
artifact
spec.
G
I
think
that
does
serve
a
near-term
purpose
very
well,
but
I
I
think
that
some
of
the
the
criticism
that
you
have
of
the
current
image
spec
as
not
supporting
other
artifacts,
will
end
up
happening
with
the
artifact
spec.
One
of
those
is
like
what,
if
I'm
a
notary
developer-
and
I
think
I
brought
this
up
in
in
a
in
the
artifact
maintainers
chat.
G
You
know
what,
if
a
notary
developer
wants
to
do
something
what
if
they
want
to
work
on
their
own
stuff
and
not
be
inside
of
the
artifact
spec
and
have
their
own
release
cycle
outside
of
the
artifact
spec
or
what?
If?
What?
If
there's
a
new
thing
that
we
didn't
come
up
with,
that
they
want
to
work
on.
So
we
kind
of
need
to
like
figure
out
how
we
can
shift
the
project
into
that
distribution
mindset,
but
then
also,
at
the
same
time,
allow
these.
G
You
know,
build
this
distribution
system
in
such
a
way
that
it's
open
to
extension
and
that
new
implementations
don't
need
to
ask
our
permission.
They
can
go
and
do
it
and
make
it
work
and
say:
hey
this
thing
works,
and
then
it's
open
for
specification
and
to
me
that's
that
would
be
building
the
infrastructure
for
the
future
of
oci.
G
Now
how
we
do
something
that
gets
you,
mr
lasker,
and
your
team
unblocked
and
the
hard
work
of
the
artifact
maintainers,
while
also
kind
of
hey,
let's
go,
let's
make
the
shift.
Let's
lead
into
this
a
little
bit
and
make
this
shift.
How
can
we
do
that
without
making
irreversible
decisions
on
a
short
timetable
that
we're
not
happy
with
that's
what
I
don't
know
about,
but
those
are
the
like:
the
the
pieces,
the
balls
in
the
air
that
I'm
kind
of
looking
at
right.
G
A
And
if
you
so,
the
I
think
the
approach
that
we're
trying
to
do
is
to
make
it
very
general
right.
It's
it's.
It
shouldn't
know
anything
about.
No
like
the
reference
type
stuff,
which
is
just
the
new
piece
of
the
artifact
stuff,
is,
would
support
notaries
for
cosine
supports
spdx
cyclone
dx.
You
know
the
things
that
we
know
of
to
your
point,
but
it
shouldn't
know
about
any
one
of
those
particulars.
A
What
it
knows
is
what
are
the
common
requirements,
so
we
build
that
general
app
general
generality,
yeah,
and
because
we
have
you
know
this,
this
time
constraint
and
then
the
larger
goals.
If
you
look
at
the
way
pr29
was
set
up,
is
we
did
identify
this
gap
or
the
the
challenge?
So
we
have.
You
know
you
always
have
the
three.
The
three
sides
of
the
triangle
right
time,
resources
and
features
or
quality
time
features.
Quality
will
never
be
a
viable.
You
know
a
variable.
We
always
want
quality
to
be
there.
So
we
have.
A
If
time
is
fixed,
then
we
can
only
do
certain
features
and
if
we
really
relax
time,
we
can
do
more
features.
So
what
we
want
to
do
is
say
we
know
we
need
to
do
for
this
fall
for
the
security
for
security
work
that
we
we
all
have
to
ship
right.
The
executive
order
fits
us
all,
and
then
we
know
with
the
larger
things.
So
it's
more
of
a
scoping
thing
of
like
all
right
what
we
know
what
we
know
today-
and
we
don't
know
we
don't
know
about
today.
A
So
but
we
know
we
need
to
deliver.
Let's
scopes
things
that
we
will
ship
for
this
summer,
call
it
a
draft
call
it
anything
other
than
a
final
release
or
whatever
we
want
to
do
and
then,
as
we're
going
through
that
and
getting
more
requirements
from
other
artifact
types
from
other
scenarios
that
we
discovered,
then
we
roll
it
into
phase
two.
So
that's
that's
how
we
were
trying
to
balance
those
two
things
and
to
your
point,
like
I
just
to
the
open
container
thing.
A
I
view
this
as
a
kodak
moment,
like
the
kodak
decided
they
were
going
to
stick
where
they
were
and
they're
gone.
I
don't
even
know
what's
branded
kodak
anymore,
whereas
adobe
like
adobe,
was
known
for
the
graphics,
software
and
stuff
and
now
they're
doing
ml
like
this
is
our
chance
to
kind
of
evolve
the
brand
to
support
a
broader
things
that
I
love
hearing
that
you
guys
have
thought
about
this
earlier
on,
like
I
have
no
aspirations
to
think
of
something,
we
saw
something
brand
new.
A
It's
like
we
just
like
to
see
it
move
forward,
so
we
can
leverage
the
escape
these
general
capabilities.
So
that's
kind
of
how
we
were
thought
about.
Releasing
that
tension
between
the
larger
thing
that
we
want
to
do
versus
the
thing
that
we
could
do
now
and
learn
from
right.
It's
like
there's
a
lot
of
yeah
something
to
learn
from
it.
G
G
A
Think
in
long
term
there's
a
refactoring
but
yeah,
but
I
want
to
relax
in
one
piece
like
if
you
look
at
29
it
was
never
set
for
anything
more
than
a
draft
like
we
recognize
that
this
is
an
incubation
that
we
don't
know
what
the
end
result
will
be.
So
I
think
whatever
we
used,
because
you
know
we
have
enough
done
now
that
we
know
what
we
can
ship
and
we
can
learn
from.
A
But
I
know
that
I
would.
I
would
like
to
see
the
change
like
every
all
of
our
engineering
teams
and
the
mutual
registry
teams.
Panic,
because
we
start
storing
stuff
forever,
and
you
know
how
do
you
shift
so
we
need
to
deal
with
that.
Don't
get
me
wrong,
but
I
think
we
can
take
what
we've
learned
today:
rev
it
and
then
evolve
it
like.
I
that's
why
having
what's
called
wg
or
something
dash,
something
spec,
don't
really
care,
but
that's
why
I
want
to
leave
the
artifact
stuff
that
exists
today.
A
Stable
nothing's
changed
guys,
it's
great,
hey!
Here's,
the
new
stuff
that
oci
is
evolving
to
it
is
a
working
group.
It
is
a
draft,
it's
whatever
hint
that
suggests
this,
isn't
you
know,
look
with
distribution
was
out
there
for
how
many
years
and
it
wasn't
finalized.
So
I
don't
know
what
I'm
going
to
recall
it,
and
then
we
wrap
it.
We
make
revs
as
we
learn
and
revs
by
the
way
residents
we
learn
might
be
hey
these
things
move
to
different
repos,
also
like
I'm,
not
making
any
conclusions
around.
A
Your
point,
if
it
wants
to
be
cast
like-
and
I
just
also
I-
I
believe-
that
the
refactoring
kind
of
thing
that
we
talked
about
with
image,
but
everything
that
we've
done
to
date
is
really
really
a
hundred
percent
focused
on
having
absolutely
no
impact
the
image
supply
image,
container
image
supply
chain
tool
chain.
Rather
that
goes
on
like
everything
we've
done
from
the
new
manifest
type
and
everything
is
to
make
sure
we
have
no
impact
on
that.
A
B
B
That's
what
I
mean
by
like
the
stuff,
that's
kind
of
kind
of
like
protected
or
otherwise
that's
in
image
spec
currently
could
could
take
some
rearranging
and
otherwise
that's.
This
is
what
I'm
alluding
to
like.
This
is
why
it's
you
know
protected
is
because
it's
what's
like
broadly
implemented
and
collaborated
on,
even
if
it's
confusing
that
it's
in
an
image,
spec
repo-
and
it's
actually
could
be
like
two
different
things
like
two
different
concepts:
one,
that's
more
container,
you
know,
process
container,
related
packaging
versus
the
content.
Distribution.
B
Side
of
you
know
those
those
things
regardless.
So
that's
like
yes,
one
kind
of
restructuring
conversation
mike,
like
you
you
mentioned,
but
how
to
how
to
like
effectively
move
forward
in
in
what
could
be
container.
You
know
a
container
config
related
manifests
versus
a
general
config
manifest
and
not
breaking.
B
It
should
be,
you
know.
Are
we
in
agreement
that
effectively
what
like
this
reference
types
and
generic
manifest
generic
artifact
manifest
should
be
in
a
working
group,
so
some
amount
of
success
criteria
around
it,
some
amount
of
like
identifying
how
it
overlaps
or
what
it
means
for
the
different
specs
or
if
it
means
massaging
out
to
where
there's
like
a
new
new
place
for
this
kind
of
manifest
to
live.
B
B
I
saw
that
wilson,
the
wilson
person
made
a
bunch
of
responses
to
comments.
I
haven't
gone
through
those
yet
so
you
know
I
felt
like
in
the
last
week,
there's
been
a
lot
of
iterations
on
that
it
probably
would
be
good
to
time
box
that
to
say
get
all
your
comments
in
or
otherwise.
If
there's
no
blockers,
then
we
can
vote
within
whatever
seven
to
ten
days
winslow.
Thank
you.
E
A
I
think
we
should
do
that
regardless.
I
want
to
I'm
hoping
we
can
do
that.
Unfortunately,
it's
like
unless
again
the
time
it
takes
for
that.
If
we're
gonna
continue
commenting,
I'm
not
saying
we
shouldn't
that'll
take
some
time
in
the
there's,
the
least
of
bad
options.
If
you
will,
you
know
if
it
cares,
what
others
think,
but
if
we
were
to
rename
artifacts
to
be
wg-artifacts
and
we
kept
the
maintainers
of
the
artifact
the
way
it
was
that,
in
other
words,
the
you
know
the
owners
there.
A
Is
there
a
concern
about
us
merging
29
into
that
part
and
making
sure
that
the
media
types
had
whatever
it
is
that
we
can
say
that
convey
wg
or
whatever
to
to
reference
that
in
the
manifest
types
or
whatever
it
is
that
we
define,
if
that's
the
path
of
least
resistance.
That
is
the
less
of
all
bad
choices.
A
That's
something
I
could
see
doing
because
when
I
say
less
of
bad
choices,
the
alternatives
that
we
do
something
outside
of
oci
and
that's
not
my
choice,
but
I
just
I
don't
know
what
else
to
do
at
this
point.
So
if
that
was
an
amenable
thing
and
we're
not
constantly
blocked
on
endless
pr
feedback
that
should
iterate,
but
sometimes
it
can
iterate
after
it's
merged,
then
I'd
be
okay
with
that.
B
Oh,
this
is
not
official
stuff
that
is
currently
being
you
know
worked
through
and
it
kind
of
reverts
past
efforts
is
that
that
also,
that
renaming,
does
not
accomplish
having
established
like
success
criteria
of
this
new
spec
for
working
out,
and
so
I
think
in
in
my
mind
it
no,
the
proof
of
concept.
Work
doesn't
just
go
somewhere
else,
because
you
know
effectively.
That
should
be
the
point
of
open
governance
is
that
it
works
here,
and
it
typically
means
that
there's
more
deliberation.
B
I
think,
even
with
how's
this
as
a
proposal
then,
based
on
the
conversation
we've
had
like
you
first
said,
leave
artifacts,
as
is
like.
Will
it
expect
to
have
like
a
working
group
for
the
place
to
work
on
kind
of
like
the
spec,
and
what
that?
What
that
touches
on
and
like
group
of
concepts
like
has
a
different
repo.
B
The
based
on
effectively
to
look
at
this
as
like
a
gantt
chart
the
critical
path,
even
though
this
to
be
full
99
is
not
merged,
or
you
know
it's
like
not
solidified,
the
kind
of
like
template
proposal
of
like.
Oh
here's,
a
working
group.
Here's
the
success
criteria,
what
here's
the
kind
of
tldr
abstract
of
it,
given
that
you've
already
worked
on
this
full
request,
99
a
29.
B
B
We
could
have
kind
of
like
a
proposal
ready
for
this
working
group
kind
of
model
immediately
and
close
that
out
and
then
like
be
off
the
races
and
like
the
critical
path
could
be
pretty
well
lined
up
there,
and
then
we
could
like
that,
would
allow
us
to
leave
artifacts
as
it
is.
It's
like
a
way
to
track
these
different
media
types
and
like
who's
using
them
and
how
to
use
them,
and
then
we
could
have
a
separate
like
actual
working
place
for
proof
of
concept.
B
A
B
A
B
B
B
B
The
only
thing
that
potentially
could
stand
to
suffer
is
if
those
things
you
know
like
without
any
with
any
amount
of
slack
like
that,
could
be
the
most
critical
path
he's
there,
but
it
could
still
be
in
like
a
couple
of
months
or
whatever,
but
it
just
could
be
governed
like
it
could
be
tighter
than
a
couple
months.
But
I'm
just
saying:
what's
a
couple
of
months
you
lost
me
there.
B
B
A
Well,
let
me
let
me
just
try
to
help,
because,
like
yeah,
I'm
literally
talking
like
the
next
day
or
two,
we
need
a
workplace
to
work.
So
what
I
wasn't
sure
is
if
you're
saying
the
working
group
would
be
defined
and
we
would
create
the
repo
and
give
it
a
couple
of
months
to
evolve
to
a
point
or
say
before
we
could
even
create
the
repo
and
the
place
to
work.
It'll
be
a
couple
of
months
a
month
or
more
like.
A
If
it's
even
two
weeks,
then
what
I'd
just
say
is
that
that's
okay,
let's
just
do
the
parallel
effort,
we'll
start
the
artifacts
work
in
another
public
location
and
we'll
keep
this
thing
going
and
then,
whenever
it's
ready
like
we're,
we
would
build
it
so
that
it
can
be
donated.
Oci
like
it's
always
been
that
way.
A
It'll
always
be
that
way,
meaning
that
there'll
be
a
specs,
because
there'll
probably
be
a
couple
of
repos
for
some
of
the
things
that
being
proposed,
there
will
be
a
specs
repo
that'll
conform
to
what
oci
currently
does
today,
whether
it
has
go
libraries
or
not.
There's
interesting
challenges
there,
but
it'll
be
a
specs
repo
for
the
artifact
spec
that
would
be
set
up
so
that
it
can
be
donated
to
oci.
A
A
Once
we
start
shipping
it
for
customers
to
use,
we
can't
change
it
like
some
of
these
things
can
be
a
string
change
and
I
just
say
you
know:
saj
hey:
we
have
to
change
the
string.
No
customer
content
is
stored
on
it.
Yet
so
we
don't
care,
we
have
to
roll
it
out,
that's
a
challenge,
but
that's
fine.
Once
we
roll
it
out
and
customers
start
using
it,
then
we're
locked
for
that
release
or
that
version.
If
you
will
so
I
I'm
really
I'm
not
trying
to
force
any
time.
A
The
decision
that
I'm
just
saying
we
have
to
make
a
decision.
We
have
to
move.
It
is
something
we've
been
working.
This
isn't
like
hey
by
the
way,
surprise
we're
showing
up
today
we
need
a
decision
by
the
end
of
the
day,
like
we
have
been
talking
about
this
since
this
iteration
of
february
or
I
came
over
when
it
was
so.
If
we
think
it's
realistic,
it's
going
to
take
a
couple
of
weeks,
then
that's
okay.
Let's,
let's
do
this
with
two
parallel
efforts
and
we'll
see
if
we
can
convert
them.
A
G
I
think
we're.
I
think
we,
I
think
the
real
danger
is,
if,
if
you
market
experimental
and
then
you
really
suspect
from
it
and
it's
an
oci
spec
now
and
then,
when
microsoft
and
aws
say,
hey
we're
implementing
the
oci,
spec
and
then
oci
says
well,
no,
it's
an
experimental,
spec
it'll
just
be
confusing.
That's
I
think.
That's
the.
G
Yes,
yeah,
but
like
do
we
do
we
have
a
formal
incubator
process
now,
like
that,
we
never
built
that
in
this
project
was
really.
This
project
was
tiny.
It
was
like
10
people
versus
like
say
cncf,
which
was
thousands
of
people
now
right
like
so
it's
we
just
we
just
didn't
build
this
in
because
every
you
know
just
the
size
of
it
is
so
much
smaller.
G
So
the
what
we
do
risk
here,
though,
is
the
draft
spec
being
so
like
I
don't
know
if
anybody's
familiar
with
am
q
amqp
is
that
right
they
never
went
so
they
released
09
and
then
and
it
had
like
exchanges
and
queues
and
an
interesting
model,
and
then
they
had
1.0
spec,
which
was
like
unintelligible.
It
was
like
nodes
and
taps
and
very
complicated,
and
nobody
ever
used
1-0
and
they
just
always
used
09
and
that's
what,
if
you
work
with
like
amqp
protocol,
that's
what
you
do
today.
G
So
you
know,
and
just
like
you
know
like
with
docker
right
like
you
know
the
what
you
know
largely
what
was
done
in
the
in
in
that
implementation
is
what's
in
the
spec
today
and
there's
all
sorts
of
stuff
in
there.
So
what
gets
shipped
is
going
to
end
up
being
the
spec.
So,
yes,
sam
experimental,
all
caps,
unless
that's
an
acronym
for
something
somebody
can
come
up
with
an
acronym
for
experimental
that'd,
be
great.
I'm.
C
G
Mean
like
like
that's,
the
only
thing
is:
if,
if
you
ship
it
it's
that's
it
right,
people
use
it
and
then,
like
I'm
going
through,
I
hadn't
looked
at
29
in
detail.
I
see
a
couple
of
mistakes
being
carried
from
the
old
docker
stuff
that
are
still
there
and
if
that's,
what
we're
shipping
you
know,
we're
gonna
have
to
we're,
not
gonna,
be
able
to
use
this
to
kind
of
get
around
those
mistakes.
A
A
Like
do
you
even
know
how
to
look
at
it
and
because
we
we
don't
want
to
ship
mistakes,
we
want
to
learn.
We
had
this
conversation
the
other
day
around
a
paging
api
that
actually
turned
out
to
be
on
acr
because
it
doesn't
exist
in
distribution,
so
we
had
to
create
one
and
we
made
our
own
mistake
and
yeah.
That's
all
part
of
learning,
but
we'd
like
we'd
like
to
be
in
this
open,
a
place
that
we
can
get
feedback
but
at
the
same
token,
as
we're
getting
feedback.
A
We
have
the
ability
to
say,
like
okay,
appreciate
the
feedback,
but
we
are
going
to
move
forward
because
we
have,
we
can't
just
be
stopped
on
every
last.
You
know
question
we
want
to
be
able
to
ship
things
that
we
know
might
not
be
perfect,
but
it's
good
enough
for
us
to
learn
to
make
the
next
steps
I'm
not
trying
to
pick
on
the
whatever
it
is
that
you
don't
even
know
which
snake
issues
you're
talking
about
it
doesn't
matter.
A
My
point
is
that
that's
part
of
this
working
group
thing
model
that
I
want
to
make
sure
we
have
in
place
is
there's
a
set
of
maintainers.
I
hate
the
word
maintainers
now
collaborators
owners
that
are
focused
on
a
common
goal
and
are
trying
to
move
forward.
We
want
to
be
open
to
take
all
feedback.
We
want
to
have
the
ability
to
make
decisions
to
move
forward.
E
Steve,
I
think
that
is
what
the
governance
structure
is
about,
like
with
the
existing
specs.
We
have
maintainers,
the
maintainers
can
make
decisions
and
with
the
working
groups
where
the
proposal
is
to
have
owners
and
those
owners
can
make
decisions
too.
It's
not
about.
Like
you
know,
every
bit
of
feedback
is
going
to
stop
everything,
but
it
is
also
you
know
everyone's
going
to
value
the
feedback.
E
B
H
A
I
pasted
the
two:
it's
like
I'll
pitch
them
in
sorry
in
zoom,
I'll
paste
them
in
the
slack
as
well.
There
is
there's,
basically,
we
we
wrote.
One
up
is
here's.
What
the
reference
type
working
group
could
look
like
and
then
99
is
here's.
What
working
groups
as
a
whole
look
like,
so
we
can
vote
on
either
both.
E
H
H
Either
one
if,
if
we
think
that
we
need
to
come
up
with
action
items
or
like
follow-ups,
then
we
can
do
something
synchronous
but,
like
I,
I
agree
with
the
feedback
about
having
multiple
owners
from
multiple
orgs
that
that
seems
that
seems
reasonable
for
oci
some
other
stuff.
There
was
some
discussion
that
we
could
address
later
as
well.
B
And
then
steve
that
you
know,
as
far
as
like
you
working
it
on
the
outside
somewhere,
you
know
outside
of
oci.
If
it's
not
tomorrow,
I
think
that's,
that's
kind
of
like
should
be
effectively
a
parallel
effort
and
whether
that
means
something
that's
donated
or
effectively
just
continuing
on
like
a
path.
B
This
is
how
different
media
types
like
here's,
here's,
what
to
do
with
different
media
types.
You
know
so
implementers
and
then
anything,
that's
actually
spec
related
becomes
its
own
working
group
go
through
the
we
get.
This
pool,
99,
tod.99
figured
out
and
then
open
a
proposal
for
a
working
group
of
specs
is
completely
parallel
to
the
proof
of
concept
I
want.
I
would
love
for
the
proof
of
concept
to
happen
under
a
working
group,
but
it
sounds
like
that's
pretty,
obviously
not
in
in
your.
H
A
B
A
Because
I
don't
want
to
create
any
more
pressure
on
the
feedback
and
time
that
the
whatever
the
wrong
decision
outcome
is.
I
think
what
I'd
like
to
do
is:
let's
put
artifacts
in
a
place
that
has
mutual
governance
and
make
it
very
clear
this
will
is
intended
to
be
donated
to
oci.
This
is
a
place
to
do
the
incubation.
While
that
process
happens
and
those
efforts
work
in
parallel,
then
we
can
make
progress
in
a
place
that,
and
this
process
can
have
its
its
time
to
do
the
right
thing.