►
From YouTube: OCI Weekly Discussion - 2023-01-26
B
A
C
A
B
B
A
You're,
good
computers,
okay,
I,
think
and
I
hope
that
the
first
two
are
going
to
be
quick,
I
added
all
three
of
these,
but
I
think
and
I
hope
that
the
first
two
will
be
quick.
The
deprecate
non-distributable
layers,
PR,
is
still
open,
I,
don't
know
if
anyone
has
a
reason
we
shouldn't
do
it
I
just
wanted
to
remind
everyone
that
this
PR
is
open.
A
It
got
another
approval
last
night,
so
please
go
take
a
look
if
you
care
about
non-distributable
layers
or
don't
care
about
them
and
want
them
to
be
deprecated,
the
other
topic
and
I
think
it
will
be
hopefully
quick
quicker
than
the
third
one
is
that
I
was
talking
with
John
and
a
lot
of
our
discussion
has
been
about.
How
can
a
client
know
that
the
registry
processed
the
subject
and
we'll
handle
that
and
update
the
references?
A
The
refers
API,
endpoint
and
John
had
a
good
idea
which
I
am
sharing
on
his
behalf,
which
was
that
the
registry
can
respond
with
some
header.
That
says
we
got
your
subject.
It's
like
it's
this,
not
you
know
not
just
like
true
false
but
like
subject
processed
as
Digest,
which
gives
a
an
affirmative
response
to
the
client
that
the
registry
knew
that.
That
was
a
thing.
It
could
still
lie
about
it,
I,
guess
or
take
some
time
to
to
update
its
references
endpoint,
but
those
are
both
sociopathic
behaviors.
B
So
I'm
going
to
circle
back
real
quick
to
the
first
one
of
the
non-distributable
layers
and
ask
a
general
oci
question
that
I
think
we've
kind
of
gone
back
and
forth
on
different,
depending
on
when
or
who
we
ask,
which
is
how
many
approves
do
we
need
to
merge
this
because
I
know
we
need
a
majority
to
do
a
release
and
so
that
that
makes
sense,
but
I'm
wondering
for
these
ongoing
individual
PR's.
If
we
can
just
two
and
we
hit
approved
because
that's
what
GitHub
is
currently
set
to.
B
A
Yeah
I
mean
I
think
we
have
the
safeguard
that
it
requires
a
majority
to
get
a
release.
So
this
is
not
really
binding
until
there
is
a
release
and
if
somebody
sees
this
merge
and
then
is
like
no,
no,
you,
my
house
is
built
on
non-distributable
layers.
You
need
these
I
need
these
back.
Then
we
can
revert
it
and
ask
them
why
they
did
that
all.
C
B
Time
as
we
spent
cleaning
it
open,
and
the
discussion
has
happened
on
there,
I
feel
like
we're
we're
in
a
good
place
on
that
one
cool
cool.
Unless
someone
has
something
on
the
first
and
I'll
jump
to
the
second
one,
real
quick,
which
is
I
like
the
idea,
it
eliminates
a
round
trip
that
I've
gotten
some
of
my
code,
which
is
push
the
image.
Then
query
the
refers
API
see
if
it
worked
and
if
it,
if
it
did
great,
if
it
didn't,
then
I
pushed
the
referrer
tag
and
update
that
thing.
A
B
The
other
thing
I
like
about
is
that
it
feels
like
it's
fully
Backward
Compatible.
So
if
I
don't
know
about
this
header
and
I
still
do
my
old
stuff.
It's
still
going
to
work.
If,
if
a
registry
doesn't
implement
the
header,
all
the
fallback
stuff
would
still
work
the
way
it
should
it's
just
it's
something
it
will
speed
up.
If.
A
You're,
a
client
that
is
determined
to
push
the
fallback
tag.
Even
if
the
registry
supports
references,
then
you
can
you
ignore
the
header
and
you
just
do
it
and
you
know
you
did
more
work
than
you
needed
to
and
you're
yeah
not
taking
advantage
of
the
future.
But
that's
your
choice,
so
I
think
yeah
I
think
it's
a
really
elegant
solution
or.
A
All
right,
unless
there
are
any
other
things
about
those
two
topics
or
any
other
topics,
I
think
the
next
one
is
going
to
potentially
oh
yeah
Aaron
go
ahead.
Please
yeah.
G
Yeah
I've
been
joining
a
number
of
of
oci
related
calls,
as
you
might
have
noticed
in
the
past
couple
months,
I've
also
joined
the
oraz
object.
Oci
registry,
as
storage,
Community
calls
and
obviously
they're,
pretty
heavily
invested
in
artifact
and
I
think
they
default
to
artifact
on
push.
So
has
there
been
any
Outreach
to
them
ahead
of
this
potential
change.
A
The
artifact,
the
artifact,
manifest
you
mean.
A
Okay,
I
don't
mean
this
I
mean
this,
because
I
am
very
confused
and
not
because
I
don't
think,
because
I
think
you
are
confused
I
think
I
am
confused.
Does
any
registry
support
the
artifact
manifest
today?
Where
are
they
pushing
to
stuff
that
supports
the
artifact
manifest.
A
G
There
are
there,
are,
there
are
multiple
Registries
there's
actually
quite
a
number
that
support
the
artifact
manifest,
and
so
my
concern
here
is
that
removing
it
ahead
of
1.1,
it's
not
just
or
as
I
think
as
a
community,
but
I
think
a
number
of
the
major
Cloud
providers
also
currently
support
artifact,
manifest
in
their
registries.
B
F
F
E
C
I
I
also
tested
that
one
and
Docker
crop
so
I
can
push
artifact
manifest.
G
So
I
guess,
my
thought
here
is
in
terms
of
this
change-
is
that
there
might
be
a
inhibitis
here
not
just
to
make
a
change
in
Spec,
but
also
perhaps
a
blog
post
or
some
sort
of
reach
messaging
is
like
here's.
Why
we
are
making
this
change
fairly
late
in
the
cycle?
I
think
because
I
think
folks
expected
1.1
to
come
out
fairly
soon.
A
Yeah
I
mean
I,
think
I.
Think
Jesse's
point
is
worth
I
I
will
I
will
agree
with
Jesse's
point
right
that
that
these
are
all
pre-release
things
oci
maintains,
has
maintained
and
will
maintain
the
ability
to
change
or
remove
that
API
in
any
breaking
way.
That's.
E
A
Say
we
should
like
change
it
to
the
mermaids,
manifest
API
just
to
break
folks,
but
sorry,
there's
a
bunch
of
stuff
going
in
the
chat
now
I
think
I.
Think
the
confusion
in
my
head
also
has
been
that
artifacts.
The
term
oci
artifacts
in
common
usage
for
years
has
been
an
image
which,
with
a
config
media
type,
that
is
weird.
A
B
C
A
We
have
not
decided
anything
to
be
clear.
The
pr
is
open.
My
non-binding
approval
means
nothing.
No,
you
know,
Brandon
has
put
a
roadblock
up,
so
just
so,
we
don't
accidentally
merge
it
and
even
if
it
merged,
we
won't
cut
a
release
without
a
majority
of
people.
So
do.
A
Not
about
to
become
law,
this
is
about
to
become
about
to
become
about
to
become
about
to
become
law.
Okay,
thanks,
yeah
and
sorry.
Also
for
the
confusion
about
what
it
takes
to
merge
a
PR.
It
sounds
like
what
what
it
takes
to
merge.
A
PR
is
two
people
and
then
a
majority
to
make
it
law.
Basically
I.
Guess
among
the
points
in
my
response
in
that
issue,
was
sort
of
maybe
buried.
A
What
is
the
user
benefit
of
an
artifact
manifest
versus
an
image
that
you
know
an
image
manifest
that
contains
some
stuff?
The
user
will
never
see
the
artifact
in
it
like
we've
messed
up
completely.
If
a
user
ever
sees
this
Json
Jesse
are
you
do
you
have
I'm.
F
Just
nodding
to
everything
you
say
you
keep
talking,
I
won't
I'll
put
my
hand
down
like
everything,
you're
saying
so
I
will
say
for
history
sake
and
some
of
the
people
in
this
room
might
know
this.
I
was
around
for
image.
1.0
I
lost
this
battle,
then
I
said:
hey
people
might
want
to
store
things
that
aren't
images
shouldn't.
We
call
it
like
an
artifact,
no
images.
Then
we
did
this
whole
lowercase,
a
artifact
thing,
that's
like
well,
you
could
set
config
media
type
and
images
can
then
masquerade
as
artifacts.
That's
groovy.
F
The
reality
is
is
that
it's
nice,
it's
nice.
In
my
mind,
I
was
talking
to
Michael
about
this
last
night,
like
at
the
end
of
the
day,
tools
have
to
care
people
shouldn't
have
to
care.
So
if
we
have
something
that
works,
we
don't
necessarily
have
to
pull
it
all
apart
and
change
it,
especially
because
it
actually
is
confusing.
F
There's
a
lowercase,
a
and
there's
uppercase
a
there's,
a
media
type
and
there's
a
config
media
type.
There's
you
know
whatever
the
whole
thing
revolves
around
tools
working
and
if
tools
already
know
this,
we
already
know
the
rules
of
the
road
they're
well
proven
and
they
work.
I
am
not
opposed
to
dropping
capital,
a
artifact
from
the
scope
of
1.1
I.
F
Don't
think
it
breaks
any
of
the
use
cases,
we're
all
really
excited
about,
and
in
fact
greatly
simplifies
client
tooling
and
takes
the
thing
that
Brandon
and
I
have
been
like
battle
hugging
over
right
out
of
the
picture.
We
don't
have
to
worry
about
it.
So
I
think
that
I'm
generally
in
favor
of
this
John
that
I
don't
really
have
any
questions.
A
I
think
I
think
I,
don't
know
if
this
came
through
in
the
in
the
response
to
the
issue
to
the
pr
either
but
I.
Don't
know
that
we're
saying
artifacts,
never,
you
know
die,
never
come
back,
but
we
are
I
think
we
could
be
saying
this
is
out
of
scope
for
1.1.
A
F
A
Okay,
whatever.
A
It
was
true,
except
for
that
I
got
him
to
disagree
with
me.
We
can.
We
can
delay
the
rollout
of
1.2
and
or
the
rollout
of
artifact
manifests
to
a
potential
future
1.2
and
any
registry
that
supports
it
can
still
support
it
as
a
pre
1.2
release
instead
of
a
pre
1.1
release.
This
is
mostly
as
an
effort
to
you
know.
A
Sometimes
you
just
want
to
get
a
release
out
the
door,
and
so
you
have
to
strip
stuff
out
of
it
to
get
it
over
the
over
the
fence
and
I
think
this
is
an
attempt
at
that,
so
that
we
can
just
sort
of
set
in
stone
what
we
all
agree
on
and
push
forward.
What
we
might
still
have
questions
about,
I
will
lower
my
hand
and
stop
talking.
B
I
was
wondering
if
we
might
want
to
call
it
a
technical
preview
feature
or
something
like
that
or
just
something
that's
defined
exists,
but
please
don't
use
it
yet
feature,
and
that
way
we
don't
have
to
rewrite
the
whole
PR
a
second
time
again,
but
either
way
I
see
value
in
long
term
having
an
artifact
I,
just
don't
see
the
value
in
creating
them
in
the
short
term
and
so
I
I'm
trying
to
balance
those
two
views
there
in
the
long
term.
B
The
nice
Advantage
is
that
when
we
look
at
the
definition
of
when
oci
image
is
it,
it
clearly
says
these
are
an
ordered
list
of
layers,
and
if
you
have
throw
something
out
of
order,
you're
not
really
following
the
spec
it
it,
they
always
have
to
have
a
config
blob.
Even
if
you
didn't
really
want
to
push
a
config
blob.
So
there
there
are
some
advantages,
but
and
at
the
end
of
the
day,
they're
they're
so
minimum
it's
not
worth
breaking
things,
and
so
that's
kind
of
where
I
agree.
Yeah.
A
Brandon
I
think
I
think
it's
interesting.
You
mentioned
that
too
I
think
we
can.
We
also
have
the
ability
to
loosen
those
restrictions
in
a
future.
One
point
X
where
we
say
config
blob
is
now
optional
like
required.
If
this
or
layers
generally
mean
ordered
something,
but
we
can
we
have
the
flexibility
to
say
it
would
be
a
breaking.
A
1.2
baby
just
kidding
just
kidding
toddy
go.
C
Ahead,
yeah
carrying
in
mind
that
maybe
I'm,
the
only
proponent
of
the
artifact
type
in
this
group
right
now
is
I
would
like
to
really
discuss
the
use
case
that
I
posted
in
the
issue
itself,
where
we
want
to
actually
update
just
the
metadata
or
annotations
for
the
image
where
you
don't
have
a
config
blob.
You
don't
have
any
layers
and
so
on,
and
that
is
the
actually
use
case
that
we
already
are
are
using
for
certain
purposes
just
like.
C
If,
if
we
don't
have
the
artifact
type
and
honestly,
if
we
say
that
we
are
taking
this
out
of
the
of
the
spec
I
I,
don't
think
that
we'll
be
investing
in
creating
those
annotations
in
like.
Although
let's
say
we
support
that
in
ACR,
so
we
will
go
and
start
pushing
like
empty
blobs
just
to
satisfy
the
the
image
spec
right,
which
will
be,
by
my
opinion,
quite
ugly,
implementation
right.
A
Yeah
no
I
think
I.
Think
that's
absolutely.
The
fallback,
like
the
the
behavior,
where
I
I
am
personally
recommending,
is
that
in
order
to,
if
you
just
want
to
store,
you
know,
Foo
equals
bar
in
a
registry
somewhere
and
no
blobs
and
no
config
and
no
other
stuff
push
an
empty
config
push
an
empty
layer
to
satisfy
the
registry.
A
It
is
ugly,
it's
very
ugly,
at
least
as
far
as
client
like
client
behavior,
that
you'll
push
that
empty
blob
once
or
you'll
push
each
empty
layer
once
and
the
config
blob
once
and
then
deduping
will
prevent
you
from
having
to
do
it
again
like
there's.
No,
the
user
is
sitting
at
a
machine
like
doing
stuff,
won't
see
any
additional
latency
you
and
I,
and
all
of
us
who
knows
how
the
plumbing
Works
will
know
that
it's
gross,
but
the
user
won't.
C
Yeah
I
I
agree
with
that.
So
the
question
is
like
are
we?
Is
it
our
expectation
that
only
we
are
the
users,
because
I'm
kind
of
looking
at
let's
say
other
other
folks
are
jumping
on
the
background
and
saying
well
now,
registry
can
store
more
than
images,
because
the
message
that
we
are
sending
with
that
is-
and
this
is
more
kind
of
the
philosophical
explanation
is
so
far-
everybody
is
thinking.
C
Container
registry
is
only
for
container
images
right
and
if
we
continue
to
keep
that
that
message,
we
will
have
people
saying
well
I'll,
go
and
store
my
s-bombs,
not
with
the
container
image.
I'll
go
store
them
in
I,
don't
know:
S3
buckets,
Azure,
storage,
Google
storage,
whatever
it
is,
I
see
that
actually
making
it
artifact
registry
and
not
container
image
registry,
as
a
message
will
open
those
folks
actually
to
coming
up.
And
then,
if
we
have
this
confusing
implementations,
less
tools
will
be
willing
to
go,
go
and
do
all
this
work
and
understanding.
C
So
that's
kind
of
my
my
thought
and
as
I
said
so
if,
if
we
are
not
adding
artifact
manifest,
so
we
need
to
go
and
actually
change
all
these
things
on
our
side,
because
I
don't
want
to
like
have
things
that
only
ACR
can
do
right,
which
actually
right
now
I
did
quite
quite
some
work.
It's
ACR,
Docker,
Hub,
zot
supports
artifact,
manifests
already
I,
don't
know
Jesse.
F
That's
not
a
segue
to
why
my
hands
up,
but
I
will
answer
the
question
yeah
we
had.
We
have
full
1.1
support,
running
in
our
in
our
test:
environment,
staging
environment
and
just
waiting
waiting
for
a
spec.
So
we
yeah
we,
we
will
have
code,
we
have
to
change
it's
just,
not
public,
because
because
well,
this
is
why
we
we
don't
ship,
we
don't
ship
things
ahead
of
a
spec
because
of
this
not
a
told
you
so
I'm
I'm,
very
happy
for
all
the
brave
souls.
F
My
my
hand
was
up
to
say
first
toddy.
That
was
a
super
well
organized
set
of
thoughts.
I
really
I
think
that
that
was
really
good.
I
have
a
I
guess:
I
have
a
Counterpoint.
So
one
of
the
things
we
see
with
supporting
Helm
charts
in
oci
Registries,
which
ECR
does,
is
that
my
customers
continually
come
to
me
and
they're
like
it's
broken
I
hate
it
because
it's
not
a
Helm
repo
artifact
behaviors
are
typically
different
than
oci
images.
F
This
is
one
of
the
things
that
I
tried
to
bring
up
way
back
with
the
oci
image.
Spec.
To
begin
with
is
to
say,
will
we
ever
store
things
other
than
images?
I
did
bring
this
up
in
a
call.
We
could
look
back
in
YouTube,
maybe
like
September
I
bet,
Brandon
will
remember
where
I
said
something
in
the
same
effect.
We
already
made
this
decision
like
I'm.
Okay
with
this.
This
is
cool
and
I
kind
of
bought
into
the
artifact
thing,
but
we
already
made
this
decision
back
in
1.0.
We
did.
F
F
Now
we
do
have
a
way
to
store
non-imaging
things
and
we
all
know
how
it
works
and
I
think
that
comes
back
to
if
your
behavior
works,
like
it
does
for
home
charts
some
customers
really
like
that
in
home
three
eight
you
can
install
a
chart
right
from
right
from
an
oci
register.
That's
cool
the
tool
has
to
know
how
to
do
that.
F
So
now
the
question
is:
do
we
go
change
that
tool?
How
many
tools
are
there
right
right
now?
There
are
some
tools
that
already
do
capital
A
artifacts
for
1.1,
ahead
of
the
spec.
I
would
definitely
say
confidently
that
there
is
a
lot
more
tools
that
already
do
the
old
style
config.manifest
to
config,
that
media
type
of
the
Manifest
artifact
type,
so
I
think
that
regardless
clients
would
have
to
change.
The
question
is
who
has
to
change?
F
Well,
nobody
has
to
change
to
go
to
1.1,
they
might
just
not
change,
but
if
they
don't
change
now
and
they
and
we
don't
change
the
spec,
then
nothing
needs
to
change
and
so
I
think.
That's
kind
of
the
thing
to
look
at
here
is
like:
what's
the
value
of
having
artifacts
versus
images,
I
think
that
that
is
a
case-by-case
basis
and
I
think
some
work
and
some
don't
and
I
think
some
are
confusing.
F
And
then,
moreover,
you
know,
if
we
add
this
in
what
changes
like
if
we
drop
it
I
think
1.1
becomes
a
lot
simpler
to
reason
about
it
becomes
a
lot
easier
for
us
as
a
community
to
say:
oh,
that's
actually,
1.1.
Now,
like
there's
no
more
argument,
we
can
always
revisit
it
for
one
two
or
2.0.
As
John
was
John
recommended
like
we
can
always
reduce
it's,
not
a
one-way
door,
nobody
wants
to
kill
it
right.
It's
just.
F
Is
it
part
of
1.1
right
now
and
I
think
the
problems
that
oras
solves
will
continue
to
keep
solving
right,
because
that
is
a
way
to
use
a
registry
as
more
of
a
general
artifact
store.
I
personally,
don't
want
to
put
npm
packages
into
an
oci
registry.
I
have
no
interest
in
doing
that,
so
I
think
that's!
The
thing
is
that
we
can.
F
We
can
balance
it
right
for
me
if
we
simplify
this
and
just
say,
what's
the
easier
way
to
get
reference
reference,
the
refers
API
out
because
I
think
that's
the
cluge
right
now
that's
what
was
really
difficult.
You
look
at
cosine
cosine's,
a
wildly
popular
tool.
Everybody
loves
it
it's
kind
of
ugly
and
it
doesn't
want
to
be
ugly
anymore
right
so
like
can
we
give
it
a
reverse,
API
and
put
it
in
the
spec
and
then
maybe
1.2
now?
B
B
My
most
comfortable
position
is
to
say
the
people
that
are
storing
and
consuming
it'll
be
good
if
they
started
getting
on
board
with
the
capability
to
handle
this,
when
they
start
showing
up
just
to
have
that
code
written
and
ready
to
go,
and
we
just
say
that
anybody
producing
it
don't
produce
it
yet
that
that
feels
like
the
key
detail
to
me
as
long
as
nobody's
producing
them,
but
the
plumbing
is
in
there
for
later
on.
When
it
happens,
I
think
everybody
has
been
writing
the
plumbing
will
be
in
a
better
place.
G
Yeah
I
think
the
question
for
me
is
one
I
guess
I
would
say
is
Jesse.
You
said
something
about
not
wanting
to
store
npm
packages
in
an
oci
registry.
There
actually
are
I,
think
a
lot
of
people
who
are
very
interested
in
that
and
there's
folks
Red
Hat.
Looking
at
that
and
look
whether
you,
you
agree
with
sort
of
the
their,
you
know,
motivation
for
that.
G
I
think
whether
you
look
at
projects
like
notary
or
six
or
cosine
and
oras
and
others-
is
that
there's
this
sort
of
I
think
the
sense
that
I've
gotten
joining
all
these
different
committee
calls
over
the
past
couple
few
months.
G
Is
that
there's
a
lot
of
motivation
to
move
towards
artifacts
and
that
there
was
a
sense
among
those
other
groups
that
artifact
was
essentially
a
done
deal
that
had
already
been
merged,
the
repo
for
the
1.1,
RC
I,
think
and
to
take
it
away
at
this
point
feels
maybe
like
I
think
there's
some
reputational
risk
that
maybe
needs
to
be
assessed
here.
Is
that
there's
already
working
implementations
using
artifact
and
to
say
no
to
that
or
essentially
shut
the
door
on
it
we'll
make
those
parties,
maybe
think?
Why
would
they?
G
Why
would
oci
consider
this
in
the
future
right
if,
if
they
were
going
to
go
back
on
that
and
there's
also
I,
think
the
risk
of
folks
having
I
there's
a
lot
of
Open
Source
contributors
right
that
have
essentially
toiled
on
this
and
now
see
that
as
potentially
wasted
work,
I
think
I
would
go
to
something
which
I
forget
who
might
have
said
it
is
there's
a
there's,
this
argument
about
the
Simplicity
of
the
spec
and
getting
1.1
out
the
door,
but
it
seems
like
this:
isn't
the
sticking
point
as
far
as
I
can
tell
right,
like
artifact,
is
already
sort
of
working
in
a
lot
of
implementations,
so
what
I
guess
is
gained
by
making
this
change
so
late
in
the
cycle?
G
F
I'm
going
to
jump
the
hand
here,
just
really
quick,
because
I
want
to
respond
to
one
thing
and
clarify
what
I
was
saying:
I
don't
mean
and
Sanjay
called
this
out
too
I
don't
mean
that
the
mission
of
the
working
group
should
change
or
that
we
should
go
back
in
time
and
change
what
we
were
doing.
I
think
Sanjay
just
said
this
in
chat.
The
working
group
was
about
storing
related
content
that
aren't
images
completely
agree.
S-Bomb
signatures
things
that
make
sense
to
ride
next
to
an
image.
F
I
think
we
are
all
about
that
and
I
think
the
refers
API
makes
that
scene,
whereas
right
now
it's
difficult.
The
related
content
is
definitely
the
part
that
I
think
is
the
is
the
that's
doing
the
most
work
in
that
in
that
sentence
right.
It's
related
content.
It's
not
new
content
types.
It's
the
related
content!
That's
I
just
wanted
to
clarify
that
so
I
yeah
I
do
have
faith
in
that
I.
Don't
think
an
npm
package
is
related
content
to
anything.
F
G
Can
I
just
want
to
really
quickly
respond,
I'm
at
Poly
me
and
we're?
Actually,
thinking
of
you
know
evaluating
oci
registry
as
a
mechanism
for
Distributing
plugins
across
multiple
architectures,
and
so
we
actually
I
I
was
actually
considering
throwing
this
on
a
the
agenda
is
demoing
using
oci
registry
as
a
mechanism
for
Distributing
and
acquiring
plugins
and
I'm
using
the
artifact
type.
I.
Think
Homebrew
is
another
example
where
they're
currently
using
image
index
and
an
image,
but
they
would
like
to
move
to
artifact
in
the
future.
G
A
Yeah
I
yeah,
you
said
a
couple
things
that
I'd
like
to
rebut
some
of
them
too.
As
a
user,
I
use,
Homebrew
and
I,
don't
know
or
care
that
they
implemented
it
as
an
artifact
or
an
image
or
whatever,
like
I.
Just
to
me,
I
brew
and
stall
and
I'm
happy
and
go
about
my
day
right.
A
If
they
did
the
work
to
migrate
to
an
artifact,
manifest
I
would
never
notice.
I
would
I
would
hopefully
never
I
mean
only
if
something
went
wrong
would
I
noticed
and
if
they
did
that
they
would
have
to
the
thing
that
they
would
be
doing
is
limiting
the
number
of
Registries.
They
are
portable
to
oh
sorry,
I
cut
off
John
and
potentially
many
others
I'm
gonna
lower
my
hand.
A
C
I
I
can
go
because
it's
kind
of
if
I
want
to
relate
a
little
bit
to
what
Jesse
said
so
I
I
understand
that,
actually
that
we
us
or
the
tools
actually
need
to
be
responsible
for
handling
that
right
and
the
tools
can
go
and
actually
hack
it
as
they
want
it
right,
because
it's
hidden
from
the
users
totally
agree
with
that.
Json,
though
I
will
kind
of
a
lot
of
tool
makers
actually
looked
at
the
artifact
type
as
yeah.
We
want
to
actually
store
other
stuff
in
the
Registries.
C
That's
Asylum
mentioned
like
npm
or
or
Brew,
or
we
have
like
our
Powershell
team,
wants
to
actually
store
stuff
there
and
they
sold
out
as
opportunity
that
actually
they
can
leverage,
and
there
are
many
other
reasons
why
they
actually
store
it
in
a
registry
and
not,
let's
say
in
some
other
storage
system.
But
what
I
wanted
to
say
is
that
and
kind
of
what
also
Brendan
said.
C
So
if
what
we've
seen
in
in
our
discussions,
is
people
don't
want
to
change
the
consume
part
of
the
thing
until
there
is
a
Content
produced
that
actually
they
can
consume.
So
if
we
tell
the
Publishers,
don't
publish
artifact
types,
the
consumers
will
never
start
actually
consuming
artifact
types
and
the
problem
that
we'll
have
with
this
is
like.
C
C
Yeah
I
can
repeat
it.
So,
in
order
for
the
consumers
to
consume
artifacts
manifests,
you
need
to
publish
content
that
is
published
with
artifact
manifests.
So
if
we
tell
the
Publishers,
don't
publish
this
content,
the
consumers
will
not
actually
change
their
code
to
consume
it.
That's
kind
of
the
point.
C
Yes,
because
the
tool,
the
tools
will
have
no
kind
of
incentives
to
go
and
actually
start
using,
artifact
manifests.
So
if
we
tell
them
that
there
is
a
artifact
manifests
right
now
in
1.1,
as
you
heard,
like
npm
or
or
Brew
or
or
other
teams,
they
will
start
using
that
tool,
actually
publish
the
content
with
the
proper
manifest
else.
They
will
go
and
do
the
the
hacking
around
the
image
manifest
to
publish
the
content,
and
you
will
generate
like
a
lot
of
content
that
is
with
the
old
manifest
in
the
future.
C
H
Sure
so
I
I
still
I
fail
to
see
the
Practical
difference
between
using
the
image.
I
A
H
A
field
but
like
in
practice
their
their
equivalent
to
me.
Okay,
like
there's
no
additional
power,
you
gain
with
the
artifact,
manifest
over
the
existing
image,
manifest
other
than
if
you
use
the
artifact,
manifest
to
just
attach
annotations.
C
C
H
Manifest
which
doesn't
seem
sufficiently
compelling
to
break
backwards,
compatibility
with
existing
Registries
and
clients
to
me,
I
think
that
you
know
if
we
added
this
I,
don't
think
1.1
is
an
appropriate
version
number
if
we
care
about
simver,
which
I
don't
particularly
care
about
simvar
but
I,
think
it's.
H
You
know
that
is
kind
of
a
backwards
and
compatible
backward
thing.
Compatible
change
to
make
is
that
oh
now
like
I'm
using
1.1,
but
it
doesn't
work
with
1.0
I.
Think
a
lot
of
consumers
would
expect
that
1.1
and
one
was
backwards
compatible
with
1.0.
Usually,
but
like
I
know
it's
like
a
new
feature,
so
maybe
you
could
argue
that
I'm
wrong.
C
H
That's
fine
but
I
the
value
of
this
working
with
all
current
existing
registry
and
client
implementations
and
not
having
to
wait
for,
but
on
the
order
of
years
for
it
to
get
rolled
out
to
everything
we
care
about,
seems
to
be
much
greater
than
I,
don't
really
see
any
value
and
to
choosing
backwards
incompatible
type
for
your
artifacts,
like
I,
understand
that
there
are
clients
that
have
gone
ahead
and
started
using
this
and
I
would
say
that
is
like
a
premature
change
to
make,
but
also
it's
useful
for
us
to
have
seen
that
and
then
have
the
arguments
about
the
fallback
behavior
and
trying
to
figure
out
what
should
clients
do.
H
C
D
No
thank
you.
Yeah
I
just
want
to
make
sure
John
who
opened
the
pr
hat
his
word,
in
other
words,
it'll,
be
hard
to
kind
of
like
get
a
sense
of
where
this
is
coming
from
right
and
just
for
everybody's
sake.
D
I
think
there
are
I
want
to
probably
Channel
a
little
bit
of
IBM
Mike
here,
because
he's
not
here.
The
spec
is
about
moving
the
industry
forward.
Right,
we
shouldn't
forget
the
cat.
We
have
to
acknowledge
that
we
are
hacking.
The
hell
out
of
image
back
right
now
and
I.
Think
that's
a
fair
statement
and
I,
don't
think
it's
a
good
place
to
be
is
something
that
we
all
collectively
agree
on.
D
The
the
disagreements
that
I
have
with
the
not
value
added
the
strictness
of
the
image
spec
as
to
the
config
descriptor
needs
to
exist,
which
means
we
need
to
handle
zero,
byte,
blobs
or
two
by
blobs,
depending
on
the
registry,
so
that
is
already
registry.
Specific
implementation
that
clients
will
have
to
do
the
layer
is
specified
as
an
ordinalist
with
layers
required.
So
the
I
think
the
hinge
here
is,
if
folks
want
to
use
the
registry
to
store
non-blob
related
content.
D
There
is
a
hack,
but
if
that
scenario
is
not
real,
then
I
think
the
image
manifest
is
more
than
enough.
So
we
need
to
kind
of
like
at
least
quantify.
Is
there
a
use
case
where
there
is
a
non-image,
a
non-blob
based
manifest?
And
then,
if
that
is
the
case,
then
I
I'm,
I,
think
I'd
I'd
agree
with
John
here
that
there's
no
value
in
adding
another
artifact
manifest
instead
just
a
specification
calling
out
that
to
store
things
that
are
not
image
related.
A
B
Saw
Aaron
looking
down
so
I
figured.
He
was
going
for
his
mute
button.
There
I
just
wanted
to
chime
in,
and
disagree
a
little
bit
with
what
Tony
was
saying
earlier
there,
which
was
that
clients
it
gets
really
complicated
to
be
able
to
handle
both
and
whatnot.
B
As
someone
that's
gone
through
the
effort
of
making
the
client,
it
hasn't
been
that
difficult
for
me,
it's
two
media
types,
I'm
sporting
instead
of
one
and
the
fields,
are
lining
up
so
from
the
client
perspective
of
how
is
this
stored
in
the
registry,
it's
been
pretty
straightforward
for
me
to
handle
both
media
types
and
to
currently,
when
I'm,
producing
my
default,
pushing
the
image
manifest
and
that
way
I
keep
that
portability
out
there,
and
so
for
me,
it's
been
fairly
straightforward
to
implement
that
and
deploy
that
and
I
feel
like
any
client
that
jumped
that
queue
that
want
to
say
we're
only
going
to
support
the
artifact
media
type.
B
A
Yeah
I'll
be
totally
honest:
I,
don't
remember
what
I
was
trying
to
reply
to
when
I
raised
my
hand
20
minutes
ago,
so
I'm
gonna,
I'm,
gonna,
sheepishly
lower
it
now.
G
Yeah
I
think
I
I
think
I
would
just
say,
is
I
I'd
be
opposed
to
removing
artifact,
just
sort
of
as
a
I
think.
The
argue
I
think
the
engineering
argument
that
John
made
is
is
exactly
right
is
like
the
power
to
weight
ratio
is,
is
really
poor
and
it's
all
acknowledge
that
I
think
what
artifact
gives
is
more
about
product
and
messaging
of
oci
and
the
direction
sort
of
forward,
as
opposed
to
anything
about
technical
capability
right.
G
There
was
nothing
I
think,
fundamentally
stopping
folks
from
pushing
cat
pictures
as
layers
to
Docker,
Hub
and
ghcr
and
others
adopting
artifact
was
more
at
least
my
impression.
Was
it
signaled
a
reorientation
of
the
oci
format
and
Registries
and
I
think
I'd
be
concerned?
Well,
I
am
concerned
that
the
appearance
of
dropping
artifact
will
be
no
oci
is
doubling
down
on.
This
is
for
images
and
in
regardless.
G
A
I
I
acknowledge
that
it
is
embarrassing
to
be
making
this
change
at
this
time.
I
think
you
know
hindsight
being
20,
20
I
wish
we'd,
never
we'd
never
gone
to
Camelot
right
like
let's
just
never
have
it
put
in
I.
Do
think
that
we
have
still
done
a
mammoth
amount
of
work
and
I've
been
to
like
hundreds
of
hours
of
meetings
about
the
references.
The
refers
API
endpoint,
which
I
think
to
Sanjay's
Point
moves
the
industry
forward
and
shows
you
know
demonstrable
value.
A
I
cannot
wait
to
start
seeing
that
pop
up
in
Registries
and
start
using
it
and
start
writing
clients
against
it.
I
am
personally
much
less
interested
in
artifact
type
or
artifact
manifests,
because
I
know
that
I
could
always
have
pushed
any
cat
pictures
to
Registries
and
I.
Think
I.
Think
if
it's,
if
the
main
reason
not
to
do
it,
is
we'll
look
we'll
look
backward
facing
or
will
look
like,
we
are
not
innovating,
then
I.
A
Think
I
would
point
you
to
the
entire
new
endpoint
that
does
a
bunch
of
cool
stuff
that
we
just
spent
a
year
designing
and
not
the
like
slightly
different
Json.
You
know
schema
that
no
one
will
ever
see
as
a
signal
for
our
you
know.
Innovation.
F
Okay,
back
back
to
agreeing
with
Jason,
so
yeah
I
think
that's
that
summarizes
kind
of
like
the
context.
I
think
a
couple
of
specific
things,
I
would
say
so,
as
I
said
before
and
I
maybe
said
it
in
a
clumsy
way.
F
1.1
solves
a
lot
of
problems
for
artifacts
lowercase,
a
artifacts,
whatever
you
want
to
say,
not
an
immediate
type,
but
things
that
aren't
images
which
are
already
in
let's
say
our
Registries
I.
Think
what
I'm
hearing
is
people
want
things
that
aren't
images,
but
we
already
do
have
that.
Like
I
said
we
have
a
gajillion
Helm
charts
in
ECR,
for
example,
like
we
already
do.
Have
that
you
can
push
cat
pictures
now.
F
I
think
the
thing
that
makes
1.1
really
special
is
the
refers
API
and
that
work
and
I
like
like
I'm
kind
of
mirroring
what
Jason
said.
What
we
don't
want
to
do
is
disavow
all
of
the
users
or
community
members
are
excited
about
Capital,
artifacts
and
I.
Think
that
that
is
that
can
be
a
messaging
thing.
I
think
we
say
to
you
know
to
detangle
a
lot
of
the
what
we
are
referring
to,
sometimes
as
the
upgrade
problems
or
what
I
would
say
is
you
know
future
minor
version
versus
Legacy
support
right.
F
F
As
long
as
we
on
this
call
agree
that
we're
capable
of
doing
that
so
I
didn't
mean
to
confuse
things
with
I,
don't
want
to
store
npm
like
if
you
want
a
stream,
that's
fine,
you
can
do
it
today,
that's
kind
of
the
point.
What
I
want
is
sanity
and
and
references,
and
we
can
always
explore
new
media
types
in
the
future.
That's
that's
kind
of
my
take
on
a
oh
I
kind
of
repeating
myself,
but
I.
Just
I
wanted
to
make
clear
what
I
was
trying
to
say.
H
Indicating
that
the
config
descriptor
media
type
is
important
and
had
some
explanation
of
you
know.
Implementation
should
allow
like
arbitrary
media
types
here
and
like.
C
H
Not
validate
XYZ
and
maybe
a
link
to
a
blurb
about
artifacts
or
something
I,
just
like
I
want
this
ability
and
I'm,
currently
speaking
to
you
through,
like
a
computer
that
thinks
it's
talking
to
a
tell
type
over.
Oh,
you
know
dial
up
something
or
other
it's
like.
Can
we
just
use
the
infrastructure
in
place
so
that
we
don't
have
IPv6?
You
know
I'll
yield.
G
Yeah
I
mean
it's:
it's
a
it's
a
very
funny
point
to
make
you're
right
like
we're
we're
using
abstractions
on
abstractions,
and
we
we
pay
for
the
cost,
for
those
incrementally
I
think
constantly
at
different
layers
of
the
stack
I
think
what
I
would
what
I
would
say
is
if,
if
oci
1.1
doesn't
contain
the
artifact
media
type
hypothetically,
then
I
think
implementers
and
there's
sort
of
like
this
critical
mass
I.
Think
of
of
especially
I've
noticed
in
different
communities
of
people.
G
Looking
at
sorting
python,
you
know
potentially
using
oci
as
a
distribution
format
Homebrew
already
using
oci
image.
You
know
other
communities,
they're
gonna
ossify
on
whatever
is
supported
in
oci
1.1,
and
so
this
was
like
an
opportunity.
I
think
to
make
like
a
real
clear
change
is
like.
G
Let's
see,
I
1.1
is
the
supported
registry
for
our
artifacts,
whatever
they
are,
whether
they're
bloomy
packages
or
python
packages
or
npm
or
or
Powershell
I,
think
that
if
we
drop
artifact
from
the
spec,
those
communities
are
just
gonna
say
we're
image
forever
and
there
won't
be
a
there
won't
be
an
impetus
for
us
to
ever
adopt
artifact.
G
Now
that
you
can
definitely
make
the
case
that
okay,
let's
just
never
adopt
artifact
but
I-
think
there's
value
in
positioning
oci
in
that
forward-looking
direction,
and
certainly
this
conversation
alone
has
me
concerned
that
I
need
to
go
back
and
actually
change
my
client
code,
because
I
was
I
already
written
code
to
Target
a
CI,
artifact
and
I
was
expecting
that
only
support
oci
artifact.
A
I
still
think
that
in
the
grand
balance
and
scheme
of
everything,
unfortunately,
the
cost
of
you
doing
this
work
and
having
to
re-target
is
orders
of
magnitude
less
than
the
than
the
pain
of
everyone
having
to
maintain
artifact
type
artifact
manifest
and
everything
registry
side
and
client-side
and
user
confusion
about
I
can
push
an
artifact
to
Docker
Hub,
but
I
can't
push
it
to
you
know:
Google's
artifact
registry,
like
no.
We
support
artifacts,
as
defined
in
2018,
not
artifact,
as
defined
in
2023
I.
A
Think
yeah,
I
I
know
that
that's
frustrating
I
don't
want
to
inflict
that
on.
You
I'm,
sorry
that
we
are
talking
about
doing
this,
but
yeah
John.
You
have
your
hand
up
as
well.
H
Yeah
yeah
I
I'm
sympathetic
to
your
car
I
I've,
been
in
the
situation
before,
and
it
is
very
frustrating
and
I
I'm
happy
to
play
the
part
of
a
villain
having
come
in
the
final
hour
to
take
away
everyone's
favorite
feature
and
I
do
like
bear
some
of
that
responsibility.
H
I
think
like
at
the
beginning
of
the
working
group,
stuff
I
basically
disappeared
for
personal
reasons
and
haven't
really
taken
a
look
at
this
until
we
got
to
the
arguments
about
like
Packard's
compatibility,
but
so
so
I'm
happy
to
take
that
role
on.
If
that's
helpful,
but
I,
don't
think
it
is.
H
I
do
think
there
is
like
a
lot
of
room
in
an
oci
2.0
when
we
make
significant
breaking
changes
that
give
us
a
lot
of
power.
I.
Don't
think
that
1.1
is
that
time,
but,
like
I
I
think
it
is
reasonable
that
there
will
be
a
new
format
and
I
think
that
having
a
non-container
specific
data
structure
makes
sense
at
that
time.
When
we're
already
going
to
rip
off
some
Band-Aids.
C
I
think
it's
only
me
lifestyle,
sorry,
one
question
and
kind
of
I'm
trying
to
understand
really
the
backwards
compatibility.
So
if
we
like
tools
Publishers,
they
can
continue
to
publish
with
the
image
manifest
right.
They
are
not
required
to
use
the
artifact
manifest.
So
adding
it
to
the
spec
does
not
actually
make
that
a
requirement
or
do
I
understand
the
spec
wrong.
A
No,
you
unders,
you
understand
it
correctly.
I
think
that
let
me
fall
back
into
the
like
issue
that
so
that
nobody,
if
people,
if
a
if
a
producer
of
content,
wants
to
have
an
assurance
of
portability
across
every
registry,
even
Quay
0.7
from
1998,
then
then
they
have
to
use
the
image
manifest.
And
so,
if
you
value
portability,
you
have
to
use
image
manifest
and
now
we're
kind
of
falling
into
the
argument
of.
Why
would
they
ever
upgrade
if
they
care
about
portability
like
yeah.
C
A
Already
passed,
the
Event
Horizon
of
there
is
no
reason
for
folks
to
upgrade
to
artifact
manifest.
If
there
is
already
support
for
image
manifest
everywhere,
then
maybe
we've
already
passed
the
the
critical
juncture
where
we
can't
go
back
and
if
that's
the
case,
then
we
shouldn't
commit
ourselves
to
supporting
something
new
that
we
think
might
not
be
widely
adopted
in
in
Practical
use.
C
And
and
that's
I
think
we
are
Aaron
and
I
were
coming
from,
because
if
we
actually
don't
add
this
in
one
one
is
I
I,
don't
think
that
anybody
will
be
looking
for
for
this
in
the
future.
But
my
question
is:
is
more
like
okay,
if
people
want
portability,
they
will
publish
with
the
image
manifest
right,
we'll
expect
that,
as
Brandon
said,
the
tools
to
be
able
to
handle
both
the
image
and
the
artifact
manifest
right.
C
A
Next
weekend,
I
don't
mind
looking
silly
I
look
silly
every
day,
I
would
say,
I,
think
OCS,
one
and
only
value
to
the
world
and
the
internet
is
maintaining.
Portability
is
in
in
having
some
forum
for
all
of
the
Registries
and
clients
to
come
together
and
say
you
accept
this
I
accept
this
I
produce
this.
You
accept
it.
If
we
are
going
to
make
compromises
on
portability,
then
why
not
just
go
invent
your
own
API.
That
does
exactly
what
you
want.
You
can
do
that
right,
you
can
go
create.
You
know.
A
C
A
A
Yep:
okay,
Jesse,
what's
up.
F
I
Yeah
I,
just
you
know,
I
like
really
see
all
sides
of
this.
My
main
reason
for
not
doing
it
is
just
a
matter
of
creating
a
precedent
that
oh
you
spend
a
year
in
oci
and
that's
how
you
can
get
things
done
and
then,
at
the
last
minute,
it'll
be
ripped
out
undernews.
I
So
it's
more
of
I
want
the
community
to
like
stay
a
community
after
this
release,
and
that's
really
my
only
reason
I
think
technically,
it
does
make
sense
to
drop
it
and
I
I
just
it
would
have
been
nice
to
come
to
this
conclusion
back
in
the
fall
like
I've
already
me
and
Sanjay
gave
like
a
talk
at
kubecon
about
this.
The
you
know
it's
like
so,
but
if
I
just
drop
my
principles
and.
F
F
Don't
you
hurt
my
soul?
Sometimes
all
right
love,
you
so
look
I
want
to
say
one
thing
before
we
drop
I've
said
it
before
I'm,
going
to
repeat
it
for
the
context
of
this
I
think
we're
conflating
implementations
and
specs
I
think
often
we
complete
conflate,
even
client,
tooling,
versus
the
role
of
a
specification
right.
So
the
role
of
a
spec
is
not
the
same
as
running
code.
You
can
always
choose
to
do
things.
You
have
product
decisions,
inspect
decisions,
I
think
the
next
time
we
talk
as
a
group.
F
If
we
kind
of
go
into
it
starting
there,
we
might
come
to
a
different
resolution
for
this.
The
specification
is
meant
to
indicate
how
you
can
build
something
full
stop,
so,
whether
you
roll
it
out
in
a
year
or
not,
not
part
of
a
spec,
whether
or
not
you
implement
it
or
not,
not
part
of
a
spec
right.
So
if
we
want
to
look
at
it
that
way
and
think
a
little
bit
more,
a
noodle
on
this
on
this
PR
I
I
would
be
in
support
of
that.
F
B
B
What
I
want
to
say
is
just
consider
what
it
should
take
for
CI
to
introduce
something
new
that
would
be
backward
incompatible.
What
kind
of
steps
do
we
need
to
take,
and
how
should
we
handle
that
kind
of
rollout,
so
something
to
think
about,
and
also
with
something
to
think
about?
There
is
the
notes
that
Amy
Linked
In,
the
me
minutes
for
for
me
next
week,
so
feel
free
to
throw
something
on
the
agenda
for
that
one
and
look
forward
to
seeing
everybody
there.
That
shows
up
in
person.