►
From YouTube: OCI Weekly Discussion - 2023-02-09
A
D
Is
this
set
up
to
a
punch
line,
or
is
this
serious
about.
C
C
B
E
Oh,
those
are
mine,
yeah
thanks
everyone
for
looking
and
improving,
and
we
still
have
time
if
you
have
issues
with
them.
After
the
fact,
we
still
have
time
before
a
release
to
fix
our
boarding
or
examples
or
whatever.
B
Yeah,
nothing
jumped
out
to
me
any
issues
over
there
I
liked
it.
B
D
I'm
here,
I'm
ready
to
I'm
ready
to
argue
with
anybody,
but
also
I
have
I
just.
C
C
That's
fair
I'll
have
to
I,
have
to
low-key
laugh
at
myself
with
the
thing
about
the
subject
pointing
at
manifests
and
being
surprised
about
that,
and
your
response
was
like
I
mean
I
like
to
laugh
at
myself
for
being
an
idiot
and
overlooking
things,
but
it's
really
great
to
laugh
at
yourself
in
a
forum
of
people.
D
C
And
even
even
to
the
Nuance
of
those
kind
of
points
is,
you
know,
has
it
was
I
think
somebody
I
think
a
couple
of
people
brought
up
something
about
like
zero
length
data.
You
know
data
structures
or
no
nothing
in
the
layers,
and
it
was
even
like
reading
that
line
in
the
layers
file
of
like
that
I'll
pull
it
up,
but
still
like
a
rereading
it.
It
was
like
I
got
two
interpretations
from
the
same
sentence
and
it
was
like
I
know
what
I've
I've
assumed.
C
That
sentence
to
mean,
but
now
I
see
that
it
could
mean
two
different
things.
So
sometimes
even
just
getting
exhausted
reading
and
rereading
it,
then
you
find
a
new
interpretation
or
something
you
didn't
catch,
so
yeah
go
John.
Do
you
have
you
want
to
dive
into
things,
because
I
could
probably
talk
about
some
stuff,
but.
D
Yeah
we
could
talk
about
my
distribution
so
that
question
briefly.
First,
maybe
I
I
asked
about
this
because
I
think
it's
a
mistake
not
to
at
least
have
a
suggestion
about.
D
I
know
for
like
most
garbage
collection
and
and
that
for
most
of
those
discussions,
we've
just
kind
of
let
that
go
because
there's
a
lot
of
different
behavior
and
you
know
we-
there
was
no
guidance
on
how
things
should
behave,
and
so
different
Registries
do
different
things.
But
if
we're
creating
a
new
type
of
relationship
between
artifacts
I
think
it
would
be
really
nice
for
clients
to
have
some
kind
of
expectation.
D
D
I
like
there
are
two
kind
of
I
guess
two
or
three
points
to
this
question
like
a
lot
of
Registries
enforce
Integrity
of
references
between
objects
by
that
I
mean
like.
If
you
try
to
delete
an
image
that
is
referenced
by
an
index,
it
will
fail
in
GCR,
because
we
don't
want
you
to
create
an
invalid
index
that
will
fail
later
on.
F
D
A
D
Then
other
registries
would
even
expire
tags
after
a
certain
amount
of
time,
so
I
like
if,
if
I
delete
something
that
is
referenced
via
the
subject
field
should
I
expect
that
the
manifest
that
references,
it
will
also
go
away,
or
is
that
a
clue
that
you
know
it's
eligible
for
garbage
collection
or
should
I
be
unable
to
delete
something
if
it's
referenced
via
the
subject
field
I'm,
not
sure
what
most
people
would
expect.
I
have
opinions,
but
I'd
like
to
not
share
them
until
other
people
have
shared
what
they
think.
E
I
I
think
I
think
the
issue
has
mostly
agreement.
I,
don't
know
if
John,
if
you
have
a
specific
way,
you
are
personally
leaning
but
I.
Think
the
two
comments
are
in
agreement
and
I
am
in
agreement
with
them.
I
don't
know
if
Brandon's
about
to
blow
it
all
up
by
disagree
with
all
this,
but
I
think
I
agree
that
it
would
be
nice
but
espec
to
have
a
suggestion
and,
like
you
should
in
general,
expect
the
registry
to
operate
this
way.
E
I
think
there's
value
in
giving
Registries
the
ability
to
have
different
Behavior
if
they
feel
like
it,
but
I
think
you
can
say,
users
should
expect
that
deleting
the
thing
doesn't
delete
all
the
refers
to
the
thing
check
with
your
Registries
documentation
to
see,
if
that's
true
or
not,
but
in
general,
that
that's
the
expectation
you
should
come
in
with
by
default.
I
think
that's
worth
spelling
out.
I
agree
with
you
and
I
agree
with
that.
Being
the
way
that
we
spell
it
up.
B
Yeah
I
think
the
policy
we
had
kind
of
put
in
there
was
to
say
that
if
you
have
a
subject
that
points
to
a
manifest
that
manifests
exists
and
you
shouldn't
delete
the
thing
with
the
subject
field
and
as
long
as
it's
there,
so
we
we
did
the
inverse.
We
said
you
need
to
keep
this
thing
around.
As
long
as
the
original
manifesture
Point
who
still
exists,
we
didn't
specify
the
negation
of
that
of
once.
You
delete
the
Manifest.
B
G
Yeah
I
can
go
I'll
share
some
history
on
why
GC
was
pulled
out.
It
was
again
one
of
those
contentious
topics
of
how
much
do
we
weigh
it
into
the
whole
garbage
collection,
discussion
with
distribution
spec,
and
hence
we
decided
not
to
put
it
in
at
that
point.
G
The
one
scenario
maybe
I
can
talk
about
is
the
when
you
wanted
to
copy
content
or
push
content,
you
wanted
to
push
the
subject.
The
signatures
before
you
push
the
actual
image
that
was
requested,
and
so
the
ability
for
the
signature
to
exist,
pointing
to
an
invalid
subject,
was
the
primary
driver
for
keeping
that
as
an
option
in
the
registry
to
keep
it
there.
Now.
That
said,
right
now
from
ACR
side,
we
don't
implement
it.
That
way.
G
We
actually
delete
everything
if
the
route
is
deleted,
but
we
don't
block
on
pushing
it.
So
it's
it's
a
little
bit
confusing
and
hard
and
so
guidance,
and
if
we
can
get
guidance
in
this
respect,
definitely
that
would
be
helpful
for
other
implementers.
So
I
I
love
the
fact
that
we're
actually
discussing
an
ability
to
put
GC
into
it
super
excited.
E
Yeah
I
remember
the
conversation
about
not
wanting
to
Rattle
down
the
GCE
battle.
I
think
there
is
a
good
balance
in
saying:
Registries
can
choose
to
GC.
However
they
you
know
don't
use
that
word
but
like
Registries
can
delete
stuff.
However,
they
feel
like,
but
in
general
you
should
have
the
expectation
that
pushing
a
signature
without
the
thing
it
signs
is
fine.
E
Deleting
the
thing
and
keeping
the
signature
is
the
expectation
unless,
unless
the
registry
is,
is
not
like
non-conformant
or
uncompliant
but
like
unless
that
is
the
thing
they
do,
but
in
general
you
should
expect
that
to
be
the
case.
I
think
that
is
the
case
for
most
things,
I'm
surprised,
Mr
President
sounds
like
the
ACR
doesn't
have
that
today,
but
there's
still
time
to
change
it.
If
we
change
the
expectation
of
the
spec.
G
E
That's
the
case,
I
think
specifically
we're
talking
about
you
can
part
one
is
you
can
push
a
signature
without
the
thing
you're
signing
you
do
that?
That's
great
part,
two
is
when
I
delete
the
image.
I
think
the
expectation
we
should
assume
is
that
that
doesn't
delete
everything
Downstream.
Maybe
there's
some
Force
delete
or
you
know,
crawl
delete.
Do
the
whole
thing
you
know
recursive
delete,
but
that
should
be
an
explicit
choice
or
an
explicit
behavior
of
the
registry
outside
of
the
normal
expectation.
A
D
Yeah
I
just
see
I
just
saw
that,
where
is
the
language.
D
Something
something
must
there's
some
must
that
you
can
push
a
thing
with
the
subject.
A
registry
must
accept
an
otherwise
a
valid
manifest
with
the
subject
field
that
references
a
manifest
that
does
not
exist,
allowing
clients
to
push
and
manifest
and
refers
to
that
manifest
in
either
order.
I
am
fine
with
this,
but
not.
D
I
D
If
I
push
this
first
and
never
push
the
thing
that
it
references,
then
it'll
stay
forever,
but
if
I,
then,
if
I
push
this
second,
you
know
after
that
thing
already
exists
and
I
delete
the
thing
that
exists
then,
okay,
now
I
can
garbage
collect.
It's
very
strange
to
me
that
this
is
not
level
triggered
Behavior
because
I
don't
know,
I,
think
I'm
tainted
by
kubernetes,
but
I.
F
B
B
A
lot
of
the
reasoning
for
saying
that
you
can
push
the
artifact
with
the
subject
on
there.
First,
before
you
push,
the
Manifest
was
just
knowing
that
there
would
be
certain
cases
out
there,
where
you
wanted
to
push
a
a
full
unit
of
everything
together,
and
so
you
didn't
want
the
Manifest
to
exist
before
all
the
metadata.
E
No
Brennan
I
think
there's
another
case
that
we're
talking
about
where
cosine
has
this
ability
to
to
store
images
in
repo,
a
or
registry
a
and
its
signatures
and
s-bones
and
Etc
in
registry
B?
So
the
the
signature
won't
just
exist
for
a
second
before
the
Manifest
shows
up.
It
will
exist
forever
before
the
Manifest
shows
up
in
that
registry.
F
Yeah,
so
some
of
these
discussions
are
so
so
my
suggestion
is
a
one
person's
trash
is
another
person's
treasure
right,
so
the
it's
as
far
as
the
spec
goes.
I
think
it
needs
to
be
really
strong
and
tight
in
terms
of
correctness,
but
lots
of
these
discussions
are
best
moved
to
a
best
practices
guide.
So
if
you
do
this,
then
this
will
happen
and
that
kind
of
stuff.
So
these
I
think
these
are
two
separate
documents
that
must
be
developed
rather
than
putting
everything
inside
the
spec.
A
B
J
E
D
I
mean
one:
one
of
them
is
yeah
that
helps
with
tag
immutability
within
a
repository,
but
also
it
helps.
You
sidestep
the
grossness
of
polluting
your
primary
registry
with
a
bunch
of
fallback
tags.
E
Yeah
I
was
going
to
say
even
aside
from
tagging.
It
can
be
useful
to
say
you
are
allowed
to
sign,
but
not
push
images
or
you
are
allowed.
You
know
you
have
a
process
that
pushes
s-bombs
but
is
never
allowed
to
push.
You
know
images,
there's
many
solutions
to
that
that
a
registry
can
take,
but
practically
with
Registries
that
exist
in
the
wild
today
separate
repos
like
repos,
are
the
IAM
boundary
and
so
people,
even
aside
from
TAG
pollution
and
tag
immutability
people,
might
want
to
have
a
process
that
can
push
to
tags.
J
Yeah
I
mean
I
it
just.
It
seems
as
though,
in
most
cases,
you're
going
to
want
the
artifacts
to
be
cleaned
up
and
I.
I
guess
I
question
why
we
like
cosine,
invented
this
approach
of
a
second
repo,
because
of
the
same
reason
that
we're
creating
reference
types
like
because
there
wasn't
a
way
to
do
this,
and
some
people
were
doing
all
these
tags
and
we're
having
trouble
with
immutability,
and
we
didn't
want
to
have
a
bunch
of
digest
tags
in
your
main
repo.
Oh
that's
going
away
with
reference
with
the
refers
API.
J
Yeah,
why
are
like
I
would
I
would
think
of
reference
types
as
much
more
similar
to
like
being
part
of
the
image.
You
know,
I
would
say
they're
part
they're
things
that
are
like
related
to
the
image
and
not
very
useful.
Without
the
image
sort
of
like
a
layer
is
except
for
you're
able
to
add
these
after
you
create
the
image
and
if
you
think
of
them
that
way,
then
once
the
image
is
deleted,
why
would
you
not
delete
the
reference
types
Maybe
not
immediately,
but
it
seems
fine
to
clean
them
up.
D
I
mean
on
the
issue:
I
mean
tienon
puts
forth.
The
use
case
of
you
know
it'd
be
useful
to
keep
around
s-bombs,
even
if
you
garbage
collect
the
storage,
wise,
expensive
thing
of
the
actual
image
and
I
I
also
think
that,
like
it,
is
useful
to
keep
around
signatures
for
a
lot
of
reasons
right
like
who
signed
this
for
for
investigation
after
something
I,
don't
I,
don't
think
it
is
obvious
that
you
should
always
garbage
collect
things
and
I
wish.
D
There
was
a
way
to
choose
that
like
if
we
did
something
silly
like
have
a
delete
verb
available
on
the
refers
path
that
would
be
nice,
but
I
just
came
up
with
this.
Maybe
a
terrible
idea.
G
John
we
actually
wanted
something
like
that
where
you
could
specify
Delete
all
children,
but
the
delete
apias
are
not
rich
enough
in
distribution,
I
mean
I,
didn't
want
to
touch
that
path
and
keep
your
Affairs
as
a
small
set
as
possible.
Now
I
mean
these
are
all
discussions
that
we
had
was
to
how
much
do
we
expand
the
scope
of
this
to
get
the
proposal
forward,
but
I
think
we
are
in
the
same
boat,
where
each
registry
will
have
to
go.
Introduce
new
Flags
saying,
delete
everything.
Keep
the
image,
keep
the
signatures.
G
It
is
a.
It
is
a
very
tough
part
right
now,
I
mean
the
number
of
conversations
I've
had
with
people
who
are
implementing.
It
is
painful.
So,
but
it
was
a
hindsight.
Is
the
working
group
just
wanted
to
scope
it
down?
But
if
you
want
to
kind
of
like
look
at
Delete
path,
I
think
that's,
that's,
definitely
something
we
can.
D
I
I
guess
the
reason
this
is
kind
of
a
sticking
point
for
me
is
that
I
lost
out
on
an
argument
where
the
justification
was
garbage
collection
and
then
garbage
collection
was
punted
and
so
I
feel
like,
like
it's
not
finished
right
like
if
we,
if
an
index
can't
have
a
subject,
then
I'm
mad.
Unless
we
like
very
explicitly
explain.
A
E
Brandon
I
think
I
disagree
with
your
comment
about.
If
you
liked
it,
then
you
should
have
put
a
tag
on
it.
This
a
lot
of
this
work
is
here
to
prevent
tag
pollution,
and
so,
if
the
solution
to
this
issue
is
to
pollute
your
tags
again,
then
I
feel,
like
we've,
done
a
lot
of
work
and
not
moved
that
far
forward
today,.
B
Only
in
the
cases
where
you're
you've
got
something
that
points
to
something
doesn't
exist
if,
if
you've
got
something,
that's
out
there
at
that
point,
something
does
exist
and
the
thing
you're
pointing
to
exists
with
the
tag
on
it
already
you're
going
to
keep
that
thing.
That
does
exist,
you're
going
to
keep
the
the
difference.
B
E
They
exist
so
that
I
can
query
them
via
the
references
endpoint
right.
G
A
F
H
D
Also
like
this
kind
of
came
up
for
me
mentally
when
someone
pr'd
like
Registries
May,
reject
manifest
that
references
things
that
don't
exist
like
the
ability
to
push
a
sparse
thing,
even
not
just
a
subject
field
but
say
like
an
index
that
references
manifested
don't
exist.
D
You
know
it's
surprising
behavior
for
that
to
work
or
not
work.
If
you
expect
the
other
thing,
and
so
it
would
be
great
if
there
was
a
way
for
a
client
to
be
like
hey,
I
know
this
is
broken.
I
know
what
I'm
doing
please.
D
Through
anyway,
because
I'm
prepared
to
deal
with
the
consequences
that
I
it's
kind
of
the
same
issue,
rarely
yeah
I
know
the
subject,
doesn't
reference
something
it's
on
purpose.
I
I,
don't
really
have
a
good
point
to
make
there
but
I
feel
like
there's
some
problem
to
be
solved
and
I
wish
we
could
solve
it.
I
would
encourage
people
to
like
disagree
with
me
on
this
distribution
spec
issue,
maybe
in
a
way
that
I
could
think
about
long
term.
D
E
I
think
there's
I
think
there's
value
in
saying
we
have
the
opportunity
to
set
a
precedent
or
set
set
an
expectation
for
people
rather
than
punching
it
to
whatever
you
want,
which
is
like
going
to
come
back
and
cause
complexity
later
for
people
I.
Think
we
don't
need
to
say
it
the
most.
We
don't
need
to
say
it's
a
like
a
requirement,
but
I
think
we
can
say
in
general.
You
should
expect
this
to
be
the
case
and
people
will
people
will
thank
us
for
it
in
the
future,
including
ourselves.
B
So
thinking
of
the
scenario
where
you
get
the
untagged
stuff
that
gets
deleted,
I
pushed
P3
of
an
image
multi-platform
image
has
a
whole
bunch
of
manifest.
All
the
manifests
have
signatures
on
them,
but
the
only
thing
that
was
tagged
was
that
original
V3
tag
at
the
top,
and
then
someone
pushed
the
new
version
of
E3.
B
B
D
I,
don't
know
they
have
to
stay
around,
but,
like
my
thought
here
is
there
are
Registries
with
existing
behavior
and
I.
Don't
want
those
to
change
so
like
if
you're,
not
tagging
your
artifacts,
and
you
know
the
tag
moved
from
the
Manifest
that
referenced.
That
thing
then
I
you
know
I
would
expect
those
things
to
get
cleaned
up
right.
If
you,
if
your
registry
deletes
things
that
aren't
tagged,
then
I
would
expect
that
to
apply
still.
J
B
D
And
if
you're
explicitly
like
so
there's
a
policy
that
cleans
up
the
subject,
then
that
policy
very
likely
will
apply
to
the
artifacts
as
well
right.
If,
if
there's
not
a
policy
that
cleans
up
the
subject,
then
I
would
expect
things
to
stay
around
forever.
But
if
you,
if
there's
not
that
policy,
then
you're
explicitly
deleting
a
thing
right.
That
action
is
intentional
and
I
think
that
you
could
make
that
deletion
of
all
of
its
referrers
to
also
be
intentional
right,
maybe
maybe
that
doesn't
make
sense.
H
H
It
should
do
something
different.
Can
you
can
you
draft
the
text
for
that,
and
is
that
the
last
thing,
or
the
only
thing
that
was
blocking
this
9.99
PR-
we're
reverting
I'll,
respect,
Samantha,.
B
Yeah
yeah,
we
still
have
trauma
all
over
the
place,
but
for
this
one
my
the
way
I
was
leaning
was
just
to
say.
This
is
what
we
expect
Registries
to
keep,
and
so
we
we
specify
you
know
if
you've
got
a
tag
manifest.
It
has
a
signature
point
to
it.
We
expect
you
to
keep
that
signature.
Even
the
signature
itself
isn't
tag
directly.
B
D
C
B
D
C
I'm
starting
to
say
something
but
I
mean
even
when
that's
come
up
before
and
like
people
get
into
like
describing
rough
counting
of
that,
like
all
the
manifests
that
point
to
a
blob-
and
you
know
like
ref
counting,
you
know
you
can
delete
them
and
then
it
was.
It's
been
garbage
collection.
It's
been
kicked
out
of
the
conversation
so
long,
it's
kind
of
very
much
a
Choose
Your,
Own
Adventure.
D
Yeah
I,
just
I,
think
the
change
I
would
like
to
see.
Is
this
clause
in
the
push
section
of
the
distribution
spec
about
how
a
registry
must
accept
it,
even
if
it
doesn't
exist,
I
think
that
that
should
be
made
a
little
bit
more
generic
about
how
like,
if
the
subject
doesn't
exist,
that's
okay,
that's
not
invalid
and
deleting
the
subject
doesn't
invalidate
the
reference.
D
I
mean
I'm,
okay,
with
keeping
this
for
the
sake
of
like
pushing
signatures
prior
to
pushing
the
image
but
I'd,
also
like
some
language
around
like
registry
should
you
know,
allow
this
to
continue
to
exist,
even
if
the
subject
just
delete
it
that
may
be
under
like
a
delete
section
or
something
it
it's
just.
You
know
we
current
we
kind
of
punted
on
the
rest
of
it,
because
so
much
of
that
behavior
is
already
cemented
and
and
customers
expect
one
or
the
other.
B
G
Other
challenge
is:
if
we
don't
delete
the
graph
or
give
an
API
that
says,
delete
the
entire
graph,
you
would
have
to
walk
through
each
one
of
them.
So
let's
say
you
have
an
S1
and
you
have
a
signature
attached
from
S4.
You
then
need
to
do
reference
of
refers,
so
it
gets
a
little
hard.
A
registry
flag
is
one
option.
Then
you
end
up:
can
you
do
it
for
repository
and
then
you
end
up
and
you
do
it
per
image
and
request.
G
So,
ideally,
if
the
API
was
defined
well
enough
to
say
that
image,
a
subject
plus
everything
just
go
away
or
subject
and
don't
and
ignore
all
the
reference
something
like
that,
that
would
be
more
my
preference
honestly,
rather
than
leaving
it
up
to
a
may.
But
again
we
might
not
solve
this
at
this
point,
but
these
are
the
other
problems
that
come
as
soon
as
we
leave
the
subjects
and
their
refers
hanging
around.
A
D
Hey
delete
everything
else:
I,
don't
care,
delete
everything
in
this
ballot.
I,
don't
know.
I
I
want
to
Hash
that
out
a
little
bit.
I
think
this
is
not
that
important,
like
I'm
fine
to
maybe
like
still
cut
the
apdi
and
have
this
maybe
as
part
of
the
guidance
section
but
yeah
I,
think
we
kind
of
talked
this
point
to
death.
I'd
be
interested
in
more
written
arguments
of
poorer
against
or
what
people
would
actually
like
to
see.
B
Feel,
like
everyone
else,
suspect
we've
left
this
so
undefined
a
feudalian
index
doesn't
go
out
and
delete
all
the
Manifest
the
index
points
to
so
it's
it
feels
like
it
fits
onto
that
same
model
of
whatever
GC
policy
a
registry
has
for
dealing
with
that.
After
the
fact
you
can
follow
up
with
that.
After
the
fact,
it's
not
an
explicit.
You
delete
the
top
thing
and
all
the
bottom
things
get
deleted.
D
C
D
Write
it
in
this
issue
and
then
I'll
tell
you
what
to
do.
I've.
B
I've
put
in
a
bunch
of
issues
the
the
index
having
a
subject
I've
put
in
a
few
places:
that's
come
up,
but
I
don't
know
where
to
put
it
in
the
spec
itself
and
it
needs
to
go
on
the
specs
somewhere.
I.
Think
because
people
keep
asking
the
question
for
good
reasons.
J
J
J
Cleaned
up
and
and
I'm
curious,
whether
I,
don't
know
I
think
the
way
we've
been
thinking
about
it
would
be
in
the
reference
types
get
get
cleaned
up
by
default
and
maybe
eventually
we're
able
to
turn
that
off
for
people
who
really
want
these.
But
what
I
think
is
going
to
be
the
smaller
number
of
use
cases
where
you
want
to
have
a
repo
full
of
just
signatures.
You
could
have
a
setting
on
the
repo
or
a
flag
on
the
registry
or
something
that
says:
don't
don't
do
this
for
this
repo.
E
Don't
know
that
anybody
was
arguing
that,
because
anybody
was
anybody
saying
that
it
Industries
must
retain
these
things.
I
think
we
were
just
saying
that
the
we
have
the
opportunity
to
put
in
language
that
says
that
you
should
have
the
expectation
that
a
registry
keeps
it
around,
however,
consult
your
Registries
implementation,
maybe
do
something
else.
B
D
Go
but
I
don't
think
it's
always
the
case,
which
is
why
this
is
something.
E
E
I
think
that
the
thing
I'm
interested
in
is
like
a
new
registry
implementation
wants
to
come
into
existence.
They
read
the
spec,
they
Implement
they
get
to
a
point
where
they
say:
okay,
I'm
deleting
a
manifest,
do
I
have
to
deleted
subjects.
Maybe
I
should
maybe
I
shouldn't
and
if
we
can
put
a
little
nudge
in
there
one
way
or
the
other,
then
I
think
it's
worth
nudging
for
sort
of
uniformity.
Implementation,
not
a
must
not
a
should
just
may
or
something
I,
don't
know.
E
Maybe
we've
talked
about
this
too
long
and
we
could
also
get
to
the
main
event
if
we
want
or
talk
about
anything
else,.
J
Yeah
I
I
think
yeah
I,
don't
know,
I
mean
I.
Think
most
people
are
coming
at
this
with
an
opinion
of
what
they
want
to
do
if
they
were
to
implement
it
and
I'm,
not
totally
convinced
that
the
spec
needs
to
tell
people
which
one
of
those
views
is
correct
and
so
like
a
May
or
a
hey.
This
is
a
you
know.
This
is
something
you
should
document
and
think
about
and
maybe
provide
a
way
for
cuts
for
your
users
to
configure.
J
H
Yeah,
as
Brandon
was
saying,
I
think
the
intent
of
the
work
group
was
to
allow
the
push
scenario.
Were
you
know
like
with
index?
You
can
push
the
damages
later
right
of
the
blocks
later.
If
they
you
don't
have
to
have
a
particular
sequence.
It's
over
a
particular
point
in
time,
and
it's
well
really
very
registry
dependent
right
and
that's
fine.
So
it's
more
I'm.
H
F
H
A
B
A
D
I
have
written
responses
at
length,
I
no
one
seems
to
be
addressing
most
of
my
points
and
I'm
happy
to
argue
or
not
argue
whatever.
D
Not
really
I
mean
I
think
that
I
mean
there
are
still
people
here
from
the
work
group,
but
I
would
say
you
know.
The
output
of
the
work
group
is
a
proposal
for
the
maintainers
to
assess
and
I
have
assessed
it
and
yeah.
Maybe
the
work
group
having
been
dissolved
is
part
of
the
problem,
but
yeah
we're
like
got
to
a
point
where
now
I,
you
know
don't
approve
of
it,
and
that
makes
me
a
bad
guy
but
I
think
that
that's
like
part
of
the
process.
So
here
we
are
Josh.
I
Points
all
the
points
aside.
There
is
one
thing
that
John
said
in
the
last
comment
on
the
thread,
which
was
releasing
image
and
distribution
separately
and
I
just
wanted
to
gauge
people's
thoughts
on
that
I
know.
A
lot
of
marketing
stuff
is
oci
1.1,
but
that's
definitely
something
that
we
could
do
or
is
it
not.
I
I
will
double
check
that
I
actually
am
not
sure
that
that's
the
case.
I
think
that
it
actually
just
talks
about,
subject
fields
and
refers
so
artifact
manifest
would
have
a
subject
field
if
it
goes
in.
If
it
doesn't
I
think
all
of
distribution
specs
still
applies,
I
think
the
big
downside
would
be
okay,
people
want
to
Launch,
we
have
support
for
oci
1.1,
and
now
we
have
made
it
even
more
confusing
for
what
that
means.
I
H
D
H
A
About
but
that's.
H
I
So
and
I'm
reading
Aaron's
points
here,
so
the
idea
of
an
artifact
artifact
as
an
image
I
think
is
support.
I
think
is
described
in
the
refers
API.
Maybe.
I
Yeah
and
and
I
think
you
know,
and
I
opened
an
issue
last
week
in
Rage
on
the
artifacts
repo
to
remove
it
because
I'm
being
asked
by
people
like
to
to
review
Wiki
pages
about
artifacts
and
we're
still
having
links
out
to
that
and
I
just
I
think
if
we
just
put
a
paragraph,
that's
like
oci
artifacts
probably
means
this.
I
Unless
you're
thinking
of
this
and
distribution
spec
talks
about
cooling
out
config
media
tape,
it
media
type,
it
doesn't
mention
that
means
artifacts,
but
that
is
how
you
can
get
artifact
type
into
the
refers
response.
An
artifact
type
is
described
in
refers
response
which
is
in
distribution
spec.
So
maybe
there's
not
enough
language
in
distribution,
spec
about
oci,
artifacts,.
G
K
G
J
Gonna
take
artifact
manifest
out
of
this
release
because
we
can't
figure
it
out
and
we
have
agreement
on
the
rest
of
the
stuff
and
we
should
do
a
1.1
release
in
both
both
of
these
specs
because
it
I
don't
know
it
just
something
about
saying:
there's
a
subject:
descriptor
that's
in
manifests,
but
we're
not
actually
specifying
it
where
we
specify
manifest
because
we
don't
want
to
rip
out
the
artifact,
manifest
seems
I,
don't
know
it
seems
like
we
should
do
this
in
a
way
that
is
a
little
clearer
and
I.
B
H
Yeah
I
thought
the
goal
would
be
to
have
a
simultaneous
release,
not
a
not
a
split
once
award
group
decided
to
hit
volts
back.
H
D
I
I
think
we
should
remove
it.
I,
don't
think
we
should
have
it.
I
think
that
it
is,
would
be
better
to
add
language
around
the
image
manifest
to
enable
the
same
things.
The
artifact
manifest
is.
D
It
is
the
churn
on
the
ecosystem,
both
registry
and
client-side.
That
I
think
is
not
worth
the
very
small
benefit.
E
C
K
Thanks
folks,
I
actually
I
I
will
continue
to
disagree.
That
there
is
a
small
benefit
on
the
artifact
and
I
want
to
make
that
clear.
But
I
think
Brandon
had
a
proposal
last
week
and
I
just
want
to
bring
that
again.
So
what
about
just
updating
the
wording
in
the
spec
and
saying
that
if
you
use
artifact
types
that
will
not
be
compatible
with
all
the
Registries
so
Registries
that
do
not
support
for
me,
that's
kind
of
the
go
forward.
K
Work
that
we
can
do
and
be
explicit
by
saying.
Look
if
you
use
that
thing,
you
will
not
be
able
to
actually
save
those
things
in
all
the
Registries
and
then
we
leave
it
to
the
implementers
to
make
that
decision,
whether
they
want
to
support
actually
all
Registries
and
not
I,
just
wanted
to
bring
that
that
one
I.
B
E
My
only
concern
with
that
as
a
as
a
solution
quote
unquote
to
the
problem,
is
that
oci's
values
are
for
portability,
it's
written
in
the
charter,
and
so,
if
we
start
to
say
if
you
care
about
portability,
because
we
don't,
if
you
care
about
portability,
then
do
this
as
opposed
to
saying
we
are
formally.
You
know
in
the
charter
in
our
blood
in
you
know,
care
about
portability.
E
C
C
Bring
somebody
brings
up
the
fermian
use
case
and
it's
like
I
think
that
you
know
if
the
refers
API
in
the
subject
field
is
tightly
coupled
to
the
same
messaging
that
the
artifacts
manifest
is,
then
that
might
be
part
of
the
same.
The
same
confusion
of
like
at
some
point,
I
was
mentioning
I.
Think
I
did
it
in
the
thread.
I
don't
know.
C
I've
talked
to
so
many
people
now
of
like
if
there
was
like
a
card
trick
of
like
even
just
like
the
the
variable
that
you
use,
that
pulls
in
you
know,
from
specs.go
pulls
in
a
certain
field
type
and
the
fact
that,
like
it's
using
layers
and
config
can
be
mostly
empty
and
whatever
it
almost
looks
like
a
card
config,
you
know
like
a
card
trick
and
then
you're
just
shoving
stuff
into
the
layers
fields
and
whether
or
not
you
use
the
config
field
or
not
you
just
people
just
keep
rolling
and
they
don't
really
care
and
they
can
use
the
refers
API.
C
E
C
I
mean
like
even
if
there
was
like
a
couple
other
fields
that
were
allowed
to
be
optional
and
added.
You
know
people
could
add
them
to
the
image
type.
The
image
manifest
and
Registries
that
didn't
handle
you
know,
don't
don't
know
about
those
fields
can
just
safely
ignore
them.
That's
fine,
they'd
be
optional.
Again,
that's
like
back
to
the
car
card
trick,
I'm,
not
even
a
project
of
dubious.
C
G
I,
don't
have
a
few
comments
on
the
chat
as
well.
I
think
the
pr
in
its
current
shape
doesn't
address
the
updates
to
the
image
manifest,
so
you
want
to
get
it
making
progress
I
think
we
should
get
the
Fiat
update
to
reflect
what
you
wanted
an
image
manifest.
The
other
point
I
had
was
there
was
a.
There
was
a
use
case
where
we
said
no
blob
annotations.
G
We
need.
We
need
to
probably
consider
how
the
image
manifest
with
no
blobs
can
be
can
be
achieved
because
there
are
different,
behaviors
and
Registries
right
now,
like
zero
blob
is
not
an
option.
Two
byte
blobs
is
a
different
one.
We
don't
call
those
specifications
because
config
descriptor
is
required.
G
I
want
us
to
stop
saying
that
there
is
no
value
in
the
artifact
manifest,
because
a
lot
of
these
were
discussed
in
your
working
group
and
I've
kind
of
held
myself
back
from
talking
about
this,
the
status
there
was
value
in
when
we
discussed
it
because
we
didn't
want
to
modify
the
image
back
to
loosen
the
config
blob
requirements.
We
need
to
modify
the
layers,
add
zero
statement
in
the
specification
to
say
that
layers
is
optional.
We
assume
it's
optional,
but
that's
not
how
the
wording
is.
G
We've
discussed
this
a
couple
of
times
so
if
we
can
get
to
image
manifest
and
ignore
the
media
type,
which
I
love
to
forget
about
and
see
that
yes,
no
blob
scenarios
are
supported
in
this
way
and
layers
is
optional.
Then
I
think
we
get
back
to
where
we
were
and
I
really
don't
care
honestly,
whether
the
media
type
is
artifact
or
image
as
long
as
the
Json
can
handle
those
scenarios,
that's
kind
of
where
the
whole
discussion
is
so,
let's
kind
of
like
come
back
with.
G
What
is
the
proposal
that
we
want
to
make
image
manifest
generate
so
that
these
scenarios
are
taken
care
of
or
if
the
scenario
is
not
important,
then
we
say
that
you
have
to
push
the
dummy
blob,
and
this
is
the
hack
you'll
have
to
do
to
get
to
achieve
that.
That's
also
fine.
So
let's
correct
the
verbiage
before
we
and
worry
about
the
scenario,
not
whether
we
want
to
remove
artifact
or
that's.
That
seems
like
the
solution,
but
I
think
the
use
case
is
still
not
addressed.
E
Better,
as
an
artifact
I
John,
do
you
want
to
do
that
in
your
PR?
Do
you
want
me
to
suggest
changes?
Do
you
want
me
to
make
a
PR
based
on
your
PR.
D
K
E
I
think
Sanjay's
suggestion
was
that
we
can
document
how
to
produce
a
zero,
a
an
effectively
zero
layer,
effectively
config-free
image
without
breaking
portability.
So
saying
things
like
if
you
want
to
push
an
image
manifest,
that
is
free
of
useful
layers,
push
an
empty
blob
or
empty
layer
as
the
only
blob,
and
if
you
want
to
make
a
config,
that's
just
Open,
Bracket
and
bracket
documenting
that
would
help
show
that
we
are
doing
this
in
a
in
a
non-breaking
way.
E
It
sucks
like
these
are
the
hacks
you
have
to
live
through,
but
like
better
than
Breaking
portability,
getting
a
thumbs
up
from
Brainerd.
Okay,
thank
you.
Brandon
thanks,
I
think
we're
out
of
time.
Actually,
if
nobody
beats
me
to
it,
I'm
going
to
PR
John's
PR,
but
I,
don't
know
if
I
disagree
with
him
enough
to
satisfy
the
requirement
of
someone
disagreeing
with
him
doing
the
pr
so
someone
please
otherwise
do
it.