►
From YouTube: OCI Weekly Discussion - 2023-08-10
B
Yeah
I'm
the
new
product
marketing
manager
for
open
source
at
Docker,
so
I'm
trying
to
you,
know,
get
play
of
the
land
and
some
of
our
various
Foundation
memberships
and
stuff
so
suggested
as
a
good
call
for
me
to
join.
A
Feels
like
something
I
should
have
remembered,
but
doctors
had
a
lot
of
new
people
lately
I'm
losing
track.
B
A
We
can
kick
this
thing
off,
even
though
Sasha
is
not
here
but
looks
like
he
wanted
chat
about
issue
1101
and
I'm
guessing
also
1100
as
well
over
on
the
image
spec,
where
we
were
just
kind
of
looking
at
various
guidance.
I
feel
like
I
wish,
even
if
Sanjay
wouldn't
hear
Tina
I
was
here,
but
let's
see
and
I
went
back
and
forth
a
bit
on
this
one.
But
there
are
just
some
questions
for
what
it
looks
like
when
we,
the
fatness,
let
me
get
my
screen
so
I
can
share
it.
A
A
What's
the
preferred,
and
every
time
someone
asked
me
that
I
I
kept
going
back
and
saying
there,
there
is
no
preferred
which
makes
nobody
happy,
but
I
do
at
least
have
somewhat
of
a
decision
Tree
in
my
head
of
what
makes
sense
to
me-
and
so
this
was
my
logic-
doesn't
necessarily
mean
this
official
oci
logic
unless
we
decide
to
merge
to
PR,
but
this
is
what
was
coming
out
of
my
head.
A
One
of
the
first
things
that
I
was
doing
was
I
kind
of
took
this
phrase
out
because
I
kind
of
got
people's
attention.
This
was
a
copy
and
paste
from
the
next
from
the
next
file
I
modified,
but
to
say
the
configure
type.
You
know
it
must
be
a
value
of
something
or
other
and
it
got
picked
up
by
people.
That
said,
well,
you
didn't
expand
all
that
and
no
I
didn't,
because
it's
expanded
on
the
document
I
linked
to
so
I
had
to
simplify
it
down.
Just
saying
hey.
A
If
they
config
me
a
type,
isn't
a
container
image,
then
the
thing
is
pointing
to
is
going
to
be
an
artifact,
and
so
that
was
it's
the
way.
That
makes
a
lot
of
sense
to
me
that
got
keyed
off
or
picked
up
at
you
not
on
that
one
and
said
well,
there
are
some
artifacts
that
use
that
can
take
me
a
type
set
to
a
container
image
field.
A
My
take
on
that
is
that
people
are
doing
that
are
basically
doing
a
little
bit
of
a
hacker
occlusion,
the
system
to
work
around
Registries
that
are
blocking
this
stuff,
and
it's
not
necessarily
something
we
want
to
be
recommending
as
from
oci,
but
I
want
to
leave
that
up
to
the
bigger
audience.
Since
it's
not
just
me
saying
that
to
see
what
other
people
think
about
how
to
decide
whether
or
not
it
is
an
artifact.
C
D
Yeah
I'm
I
was
gonna
chime
in
here
with
my
like
putting
on
my
tianan
hat
since
Canon
is
actually
going
to
be
PTO
for
quite
some
time
here.
I
think
tianan
would
be
the
first
to
agree
that
what
buildkit
is
doing
is
absolutely
an
ugly
cluge,
and
it
really
shouldn't
have
been
that
way,
but
it
is,
and
we
probably
need
to
probably
need
to
fail
forward
and
still
use
language.
D
Like
should
acknowledging
that
these
artifacts
already
exist,
and
this
is
a
pattern
that
people
are
already
I
mean
I
think
this
is
what
the
first
implementation
of
Oris
also
did.
If
I
remember
right,
it's
it's
a
pattern
that,
unfortunately,
is
out
there
and
can't
break
support
for
since
it
was
technically
twisting
the
words
of
previous
iterations
of
the
spec.
It
was
something
that
was
valid
to
do.
D
Oh
yes,
that
is,
that
is
how
cosine
works.
Yeah
yep,
that's
how
they
have
registry
support
today,
and
you
know,
I
mean
it's
it's
kind
of
just
undefined
behavior
on
previous
version
of
the
spec.
You
can
just
do
it
in
run
times
accepted
it.
So
I,
don't
think
we
can
change
that
now.
D
You
well
that's
kind
of
what
I
mean
by
accepted
it
and
like
I,
say
accepted,
but
like
in
the
case
of
Moby
multiple
times
we
had
things
break
where,
like
all
of
a
sudden,
I
can't
run
an
image
that
has
attestations
I'm
like
oh,
we
forgot
to
add
the
special
case
and
we
have
to
filter
the
we
have
to
filter
on
the
layer,
type
yeah.
It's
it's
not
a
great
situation
and
like
it's
a
leaky
abstraction,
but
the
ecosystem
mostly
is
tolerated
it
up
to
this
point,.
A
Yeah
putting
my
oci
hat
on
the
config
spec
itself,
when
you
look
at
the
definition
for
that
media
type,
we
do
say
right
at
the
top
of
that
that
hey
this,
this
specification
is
talking
about
the
Json
format
for
use
with
a
container
runtime,
and
so,
if
you're,
using
it
for
something,
that's
not
designed
for
container
runtime,
you're
you're
abusing
the
spec
and
I
totally
get
the
people
been
abusing.
The
spec
did
what
they
had
to
do
to
get
something
that
worked,
but
I'm,
just
leaning
toward
from
the
oci
guidance.
A
D
I
mean:
is
there
room
language-wise
to
document
that,
while
this
may
not
be
TR,
because
there's
there's
a
couple,
people
who
are
who
are
consumers
of
the
spec
right,
there's
implementers
who
are
implementing
a
runtime?
There
are
people
who
are
trying
to
build
a
conformant
layout
and
if
you
can
make
it
clear
that
implementers
of
a
runtime
you
know
hey,
there
may
be.
There
are
artifacts
out
there
that
do
this.
D
There
may
be
people
doing
this,
but
if
you're
building
a
new
tool
that
produces
oci
layouts,
you
should
not
be
doing
this
like
I,
think
that
is
in
your
perfect
world.
That's
what
you
do,
but
that's
been
tried
with
various
degrees
of
success
and
like
I'm
thinking
of
the
the
whole
debate
over
annotations
versus
labels.
D
That
is
still
unresolved
with
with
Alexa
nakahiro
right
now
trying
to
split
the
difference
there.
I,
don't
think
it
made
anybody
happy
either
with
the
current,
where
that
PR
is
stuck
at
so.
C
Yeah
I,
I,
agree
and
I
think
I
think
it
would
be
great
to
this
is
equivalent
to
a
should
right.
This
is
not
really
actually
saying
that
these
artifacts
are
breaking
the
spec.
This
is
this
is,
should
correct
for
this
guidance
and.
A
D
The
whole
file
is
guidance,
I
mean
I
will
be
honest
with
you.
The
word
will,
even
if
it's
not
in
all
caps,
people
are
going
to
interpret
that
as
as
binding
and
like
Fast
Forward
18
months
from
now,
and
somebody
who's
going
to
open
a
bug
complaining
about
something
not
being
spec
complained.
If
you
use
the
word,
will.
C
Yeah
I
would
I
would
agree
with
that.
I
would
I
would
probably
try
to
avoid.
Will
you
must
Etc,
but
I
think
this
entire
thing?
Maybe
we
could
have
a
passage
at
the
beginning
that
says
that
this
is
purely
should
guidance
for
producing
artifacts,
not
necessarily
prescriptive,
because
and
then
you
can
probably
cite
some
sources.
C
The
oci
image
spec
committee
is
is
aware
of
you
know
these
tools,
which
may
deviate
from
this
specification
over
this
guidance.
I
think
that's
probably
as
best
as
we
can
do.
A
A
This
was
where
we
got
in
trouble
earlier.
We
were
trying
to
define
the
empty
descriptor
or
when
we
came
in
it's
how
we
needed
to
find
the
empty
descriptor.
Is
that
your
point
told
media
type,
the
one
the
same
so
I
think
we're
okay
enough,
the
people
that
have
been
abusing
this
have
also
been
abusing
the
content
itself
and
they
are
passing
some
root,
FS
layers
and
other
stuff
inside
of
that
blob.
D
I
guess
what
you're
saying
is
there
is
a
must.
There
is
a
must
include
layers,
but
not
necessarily
only
layers
right
and
when
I
talk
about
runtimes,
accepting
I
mean
I'm,
mostly
coming
back
to
like
our
the
container.
D
is
layer
type
function,
which
is
horrible,
but
it
is
widely
used,
and
that
logic
is
the
fact
that
it's
proliferated
everywhere
is
what
makes
me
think
that
you
know
this
isn't
going
to
go
away
in
the
in
the
medium
term.
A
E
A
I'm,
sorry,
no,
no
worries.
E
He
couldn't
come
on.
These
calls
right
so,
but
he's
also
kind
of
like
leaving
comments
on
the
issue
who,
what's
what's
been,
the
general
consensus.
I,
think
what
I'm
trying
to
understand
is
we're
also
trying
to
make
a
few
decisions
as
to
how
do
we
tell
customers
when
to
use
out
of
it
like
when
not
to
use
it
and.
E
That
so
I
think
we
just
want
to
probably
formulate
this
to
some
extent
and
then
go
with
it.
I
think
that
was
my
my
thinking
out.
D
A
D
I
wonder
if
language
around
deprecation
is
maybe
productive
here,
because
that
is
to
say
like
these
these
artists.
So
so
so,
arguably,
if
it's
not
a
layer,
it
shouldn't
be
used,
I
mean
not.
Arguably,
if
it's
not
a
layer,
it
shouldn't
be
using
the
layer,
media
type
in
a
world
where
we
have
artifacts.
D
You
still
have
to
handle
the
case
of
there
being
non
non-layer
layers,
something
that
claims
it's
a
layer
but
actually
isn't,
but
certainly
anybody
who's
trying
to
produce
something.
That's
packaged
in
an
oci
format
going
forward
shouldn't
be
doing
that
so
I.
Just
wonder
if
you
know
the
deprecated
wording
is
enough
to
imply
that
implementers
of
runtimes
you
might
have
to
handle
this.
There
could
be
things
in
there.
D
There
aren't
layers
and
you
should
be
looking
and
not
trying
to
treat
them
as
layers,
which
is
that
containerdy
helper,
but
you
know
implementers
who
are
producing
layouts.
You
should
not
do
this
going
forward.
You
should
only
ever
put
layers
in
something
that
says
it
contains
layers
in
a
world
where
artifacts
are
available.
They
should
be
preferred
for
any
new
implementation.
A
Yeah
the
layers
part
below
I'm,
I'm,
more
flexible,
I.
Guess
it's
to
me.
It's
when
we
say
that
this
is
a
configure
type
for
an
oci
image,
and
it's
not
an
oci
image
that
that
gets
me
a
little
bit
concerned,
but
I
I
would
be
comfortable
enough.
Saying
should
not,
if
someone's
someone
wanted
me
to
make
that
change
instead
of
will
not
should
not
I
can
at
least
work
with
that,
and
since
this
is
guidance,
I
think
I
would
even
say.
A
We
have
a
concern
on
writing
in
here
that
if
someone
does
that
they're
they're,
not
following
our
guidance.
A
E
E
E
A
E
Yes,
all
I'm
saying
is
it's
already
defined
that
this
config
media
type
is
an
image?
Do
we
even
need
to
call
this
out
here,
because
if
somebody
wants
to
use
an
image
they're
going
to
use
their
config
media
type
agree
that
people
might
do
things
like
storing
I,
don't
know
anything
into
the
config,
but
I.
D
Mean
I
think
it's
important
to
have
the
guidance,
because
there
are
plenty
of
implementations
out
there,
which,
if
I
look
if
I,
was
to
go,
look
at
how
cosine
or
build
kit
are
implemented.
Today
they
are
putting
not
layer
things
into
a
image.
Config
shaped
object
and
the
tools
that
are
aware
of
that
are
either
well
tools
either
do
nothing
and
they
pretend
that
that
data
doesn't
exist
or
they
know
how
to
interpret
it.
D
But
it
is
packing
things
into
a
schema
that
wasn't
designed
for
this
as
a
way
to
work
around
registry
support,
and
so
I
can
go.
Look
at
that
implementation
and
think
that
this
is
the
way
to
do
it.
But
in
a
world
where
we
have
artifacts,
nobody
should
really
be
doing
that
anymore,
because
that
was
the
entire
point
of
this
work
was
to
come
up
with
something
better
than
trying
to
create
a
non-runnable,
a
non-runnable
image,
and
you
know
stuff
all
your
data
in
there.
D
E
I,
don't
have
any
concern
of
putting
the
closet
I'm
asking
for
kind
of
like
a
way
to
get
out
of
the
log
champ
if
people
want
to
kind
of
like
have
this
called
out
that
the
image
start
config
is,
is
kind
of
reserved
for
an
image,
then
we
then
yeah
I
think
it's
fair
to
kind
of
recommend.
Don't
do
it
yeah.
You
have
always
free
to
step
away
from
the
recommendation
and
it
is
a
guidance
it
should
be.
Okay,
there's.
E
D
All
it's
all
there
so
yeah
well
and
and
personally
I
would
be
inclined
to
just
even
add
an
acknowledgment
of
existing
tools
have
done
this,
and
this
is
you
know,
even
maybe
this
is
how
how
they
did
it.
But
this
is
why
you
shouldn't
you
know:
please
don't
do
that.
I
mean
obviously
something
a
lot
more
formal
than
that,
but
I
don't
think
it's
necessarily
bad
to
acknowledge
that
you
might
come
across
existing
tools
that
do
pack
non-layer
data
into
an
image
config
in
the
layers
field.
D
You
know,
please
don't
do
that
going
forward
refer
to
the
artifacts
documentation.
Instead,
you
know
I
I,
do
say
that,
with
the
caveat
of
like
that's
exactly
you
know,
I
was
bringing
up
the
the
annotations
versus
labels
on
the
on
the
the
runtime
spec
earlier
of,
like
that's
essentially
what
the
current
PR
does
and
nobody
really
likes
it.
A
E
Use
the
oci
image,
config
media
type
anywhere
else,
because
that's
kind
of
what
we
determine
that
it
is
an
image,
but
we
in
no
way
figure
out
that
it's
an
image
without
actually
inspecting
the
config
blot
Mouse.
It
makes
sense
to
me
I
just
wanted
to
kind
of
like
find
out
if
there's,
if
there
is
blocking
or
anything
like
that,.
A
Now
we
get
to
the
fun
part,
I
guess
so!
Yes,
we
don't
have
yeah.
This
person
is
not
here
and
I
think
this
is
outside
the
script.
What
we're
talking
about
so
I'm
gonna
ignore
this
one.
For
now,.
A
So
this
is
the
question:
I
think
would
make
sense
to
go
up
to
the
bigger
group
rather
than
just
having
me
and
Dean
on,
go
back
and
forth
on
it,
which
is.
Does
it
make
sense
to
say
the
forward
advice
is
that
if
you
have
an
artifact,
you
should
always
Define
the
artifact
by
type
field.
Even
if
it's
the
same
thing
as
your
config
media
type
field,.
E
Do
you
mind
if
I
give
some
context,
we
had
a
bunch
of
debates
that
I
can
maybe
summarize,
but
I'll
probably
do
a
pretty
bad
job
at
it.
So
we've
been
discussing
how
there's
going
to
be
producers
going
to
make
this
choice
and
consumers
going
to
be
making
this
choice?
E
The
challenge
that
we
were
facing
is
when
we
publish
images,
there's
a
bunch
of
events
that
we
need
to
send
out
and
fan
out
and
all
that
every
place
we
are
having
to
like
double
check:
config
media
type,
artifact
type-
and
this
is
like
multiple
places
right
so
also,
if
you
have
tools
that
are
going
to
compose
with
like
just
the
Json
or
event,
then
like
no
code
kind
of
tools,
they
have
to
do
if
blocks
and
whatnot.
So
generally,
there
was
a
sense
of
a
very
simplistic
approach
of.
Can
we
check
one
field?
E
The
the
internal
discussion
was
unify
that
and
give
another
field
out
if
the
spec
doesn't
do
it.
My
thinking
is:
if
the
spec
can
do
it,
then
we
don't
need
to
do
this
other
fields.
So
it's
about.
How
do
you
want
to
reflect
that
going
forward
and
I
also
see
there's
redundant
information?
That's
there
so
I'm,
looking
at
it
from
a
producer
consumer
standpoint,
a
producer
decision
tree
is
pretty
large
right,
like
0.4
is.
E
It
was
getting
harder,
so
I'm,
I'm,
hoping
that
we
can
take
that
input
and
I
didn't
want
to
put
it
in
here,
because
it
was
hard
to
kind
of
articulate
what
they
were
saying,
but
long
story
short.
How
many
places
will
be
checked
these
two
Fields
going
forward.
It's
also
becoming
challenging,
but
if,
if
this
is
the
guidance
that
we
want
to
go
with,
I
don't
have
any
reason
to
push
back,
but
this
is
a
problem
that
might
exist.
This
is
kind
of
what
I
want
to
do
highlighted.
E
I,
don't
think
there's
anything
breaking
here
right,
like
those
clients
can
continue
producing
it
with
country
media
type,
you're
not
telling
them
to
move
I
think
the
idea
is.
This
is
guidance
looking
forward
if
you
have
support
for
this
use,
the
artifact
type,
the
other
point
I
wanted
to
bring.
Was
we
doing
this
because
we
could
not
null
the
config
blob
out?
We
cannot
null
the
layers
flow
about,
and
things
like
that
and
technically.
E
If
we
in
in
V2,
we
say
that
config
media
type
is
not
required,
then
artifact
type
is
there
for
them
to
kind
of
use
that
so
I
was
going
down
that
path
where
it's
one.
It's
one
position
three.
It's
simple
that
if
it's
a
matter
of
fact,
I'd
look
here,
but
everything
else
kind
of
sticks
as
a
damage
anyway
of
style
yield.
D
I
I
guess
maybe
I'm
not
quite
following
Which
Way
Sanjay
is
arguing
myself,
but
what
seems
from
a
spec
standpoint,
what
seems
obvious
to
me
is
that
it
doesn't
hurt
to
have
the
redundancy
I
mean
it
is
in
the
case
of
the
two
of
in
case
of
the
the
artifact
type
being
the
same.
D
You
are
printing
the
same
information
twice,
but
it
greatly
simplifies
the
implementation.
Not
not
in
that
like
adding
in
extra
conditional
is
a
lot
of
work,
but
then
it
makes
it
just
harder
to
screw
up
and
then
some
future
oci
2.0,
that's
allowed
to
make
breaking
changes
can
say:
oh
yeah,
this
is
redundant
information.
We
can
drop
it,
but
from
a
spec
standpoint
you
know
being
aggressively
backwards,
compatible
and
expanding
the
schema,
but
also
making
it
easy
to
for
old
implementations
and
for
new
implementations
to
get
things
right.
D
A
I
started
that
sentence
in
the
wrong
place:
you're
you're
talking
about
the
config
descriptor
you're,
thinking,
okay,
that
that's
going
to
be
duplicate
of
the
artifact
types.
So
in
the
future
we
can
just
drop
the
config
descriptor
completely
from
a
future.
Version
of
the
spec
is
kind
of
a
thought
processor
going
down.
If.
A
A
A
Well,
I've
got
layers,
so
do
a
layer,
artifact
type
field,
config
blob
is
with
the
empty
descriptor
and
then
three
here
is
where
he
is
a
saying:
I
actually
do
have
a
blob
of
config
that
I
need
to
package
in
and
ship
out
with
my
artifact
itself,
and
so
I
do
need
to
fill
in
that
config
descriptor
field
I
can't
get
rid
of
it.
Do
I
also
have
to
populate
that
artifact
height.
That's
where
we're
at.
D
Right,
so
what
I'm
saying
is
I,
don't
think
it
hurts
anything
to
just
suggest
people
populate
the
artifact
type
unconditionally,
so,
regardless
of
whether
or
not
you
have
a
config
and
whether
or
not
I
mean
really,
what
this
is
is
whether
or
not
the
artifact
type
is
different
from
the
media
type.
In
the
case
of
having
well
I,
guess
that
would
be
Case
Case
case
four
below.
D
D
E
E
D
Go
ahead,
oh
I
was
just
gonna
say
like
I
think,
like
the
above
case,
it
doesn't
necessarily
hurt
to
acknowledge,
like
hey
existing
implementations.
Did
this
and
that
when
inspecting
their
output,
you
know
this
is.
This
is
why
you
might
not
find
this
everywhere
in
the
wild,
but
I
think
it's
maybe
less
beneficial
than
the
than
the
above
case,
where
we
were
talking
about
the
media
type.
A
D
D
E
I
think
that's
fair
as
a
as
a
concern
and
maybe
addressing
that
the
current
implementation
it
uses
config
media
type
might
be
the
thing
to
go
forward.
D
I
mean
I
think
making
it
clear
that
this
is
guidance
for
creating
an
image
but
doesn't
describe
the
only
valid
way
to
create
one
that's
allowed
by
the
spec
is
important,
calling
that,
out
of
because
to
be
fair,
this
is
no
longer
in
the
the
guidance
for
artifact
authors
file,
but
making
it
clear
that
other
other
combinations
are
possible
and
implementations.
You
know
linked
to
the
section
to
spec
where
it's
described
and
what
the
fallback
is
described.
That
implementations
must
keep
this
in
mind.
If
you
want
to
be
really
paranoid.
A
So
we'll
have
a
a
three
bullet
guidance
of
you
know,
no
items
just
just
something
in
in
a
layer,
single
artifact
in
there
or
something
that
has
a
config
in
the
layer.
All
three
of
those
will
have
an
artifact
type
and
then
have
a
section
after
that
and
says.
Also,
for
example,
you
will
see
a
lot
of
artifacts
that
look
like
y
EP.
This
fourth
case,
just
for
your
awareness,
if
you're
writing
anything,
it's
interpreting,
it.
A
D
Was
almost
comfortable
with
it,
the
only
suggestion
I
would
make.
There
is
just
linking
back
to
the
spec
like
not
just
just
making
it
clear
that
yeah
you
might
so
so
in
the
case,
if
you
provide
an
example
of
Y,
which
would
be
like
say,
the
helm
chart
case,
make
it
clear
that
that's
not
the
only
one
that's
possible
either
and
that
the
final
word
for
for
people
interpreting
images
is
the
full
spec
language
describing
the
fields
all
right.
A
Yeah
that
this
specific
bit
is
actually
in
the
Manifest
spec
it's
at
the
end
of
the
file,
and
it's
just
saying:
hey,
we
document
the
entire,
what
the
file,
what
the
Json
spec
is,
here's
how
some
people
are
using
it
with
our
guidance
right.
D
F
E
E
A
I
think
that's
what
we're
thinking
and
and
to
kind
of
go
along
with
the
last
previous
comment
of
separate
that
this
is
the
guidance
for
creating
and
if
you're
going
to
be
reading,
you
should
probably
read
according
to
the
spec,
which
we
document
in
this
file
that
way
people
can
do
all
kinds
of
stuff.
That's
why
they
inspect
that's
not,
according
to
our
guidance.
A
I
feel
like
I
should
be
queuing
up
ROM
at
that
point
on
that
comment
in
case
he
wants
to
chime
in
or
not.
G
No,
it's
I
mean
my
general
comment
is
it
is
the
lack
of
guidance
that
has
made
it
a
wild
west
right.
So
if
you
have
guidance,
hopefully
it
things
converge
there.
G
That's,
that's!
Wonderful!
That's
that's
what
this
will
hopefully
achieve.
Yes,
otherwise
it's
it's!
If
there
is
no
guidance,
then
all
you
need
is
one
client
tool
and
one
the
server
tool
to
agree
on
each
other
and
they
just
go
forward
right.
So
it
doesn't
quite
work
if
you
want
to
standardize.
D
If
you
get
90
of
people
to
do
with
the
Blessed
Way
the
10
of
case,
and
then
you
have
10
of
cases
where
you
know,
people
are
on
the
edges
of
the
spec
language
or
wow
I
never
thought
to
interpret
it
that
way,
but
I
can
see
how
you
read
that
okay,
we're
gonna,
have
to
adapt
to
this.
At
least
those
cases
become
less
common.
If
most
people
take
the
safe
default,
unless
they
have
a
strong
reason
to
do
otherwise.
Yeah.
A
So
exactly
what
you're
saying
what
to
give
people
some
context
about
Rob
and
I
went
back
and
forth
on
a
bit
ago
was
reading
the
spec.
You
could
just
as
easily
say
I'm
going
to
package
together
an
spdxs
bomb
and
ship,
the
s-bomb
as
the
config
blob,
and
leave
the
layer
descriptor
as
empty
and
it's
within
spec,
but
the
guidance
never
said
that
that
was
good
or
bad.
A
G
And,
and
that
would
really
be
the
the
big
achievement
out
of
this
work.
A
A
A
I'm
I'm
going
to
drop
this
down
from
four
items
to
three
items,
and
the
third
item
is
going
to
be:
if
you
have
a
config
blob,
you're
still
citing
artifact
type,
whether
or
not
it's
the
same
or
different,
and
then
what
I'm
going
to
have
is,
after
that
an
example
that
just
says
FYI.
This
is
guidance
for
creating
it
when
you're
consuming
it.
People
will
do
things
a
lot
differently.
For
example,
a
lot
of
artifacts
look
like
this
and
give
you
one
without
the
artifact
height.
A
A
A
If
I
do
that,
I'll
probably
take
into
account
saying
it's
scrolling
very
slow,
the
the
other
open
issue,
I'll,
probably
upset
them
when
I
do
it,
but
I'll
probably
take
into
account
the
workflow
that
was
being
done.
So
you
have
a
name
here:
okay,
I'm
not
going
to
pronounce
it
so
I
won't
try
to
pronounce
it.
But
the
pattern
that
was
worked
on
over
here
was
intermixing.
A
A
A
And
when
I
say
a
few
more
implementations,
I
would
be
comfortable,
seeing
ECR
ACR,
Docker
Hub,
and
these
people
that
have
implementations
that
they
can't
go
public
with
to
run
the
conformance
test
against
your
private
testing
and
just
show
those
results
to
say:
hey.
We
ran
through
our
own
internal
stuff,
our
internal
registry.
We
can't
make
public
yet
and
here's
our
report
that
shows
that
it's
all
green,
you
don't
have
to.
We
don't
emerge
it
or
commit
anything,
but
just
either
come
here,
put
up
a
trap
here
or
something
like
that.
A
E
Mean
we've
been
blunt
them
with
with
the
artifact
manifest
I.
Think
that
should
be
fair.
Asking
more
is
probably
unfair
at
this
point.
It's
what
I'm
thinking
so
I.
F
E
A
Ed,
my
fear,
is:
we
have
put
stuff
into
the
conformance
test
before
that.
We
then
came
later
on
and
was
just
like.
Oh
that
didn't
work
and
then
I
run
through
and
tested
stuff
and
I'm
like.
Oh,
this
is
panicking
against
some
well-known
Registries
out
there
and
I
just
feel
like
nobody's,
actually
run
the
test.
A
I
feel
like
everybody's
saying
yeah.
The
spec
looks
good,
we'll
go
ahead
and
support
it,
but
nobody's
actually
run
the
test
to
prove
it.
When
we
tag
this
thing,
you
can't
retake
it.
It's
done.
We
can't
come
back
and
fix
the
conformance
test
to
make
it
actually
work
right.
So
we're
at
that
point.
We're
done
it's
out.
A
Maybe
I'm
putting
the
fear
of
everybody.
Maybe
everybody
is
like
man
that
brand
kind
of
just
won't
let
it
up,
but
I
get
nervous
about
CPX
coming
out
of
the
conforms
test.
G
No,
so
there
was
a
so
Saturday.
You
did
reach
out
to
all
these
people
and
filed
a
bunch
of
issues
on
what
what
folks
think
about
the
the
conformance.
But
I
was
just
trying
to
look
it
up
on
how
many
people
responded
and
how
many
people
have
not.
A
I've
seen
a
fair
number
of
responses,
a
lot
of
them
are
more
on
the
client
side
and
most
of
them
said
officially
looking
through
the
spec
changes.
They
don't
see
anything
that
concerns
them.
They're,
not
a
lot
of
people
saying
okay,
I've
taken
this
I've
implemented,
it
looks
it
actually
works.
They
haven't
taken
that
second
step.
F
E
Anyway,
maybe
I
should
just
comment
on
this
one.
What
we
have
about
a
week's
time
in
what
I'm
planning
to
do
is
we'll
open
up
a
vote
and
take
it
from
there
as
planned
and
if
there's
anything
that
folks
can
do
during
that
time,
we'll
still
have
a
week
before
which
we
cut,
and
it's
probably
the
standard
operating
procedure.
At
this
point.
E
I
hear
Brandon
I
hear
like
your
side,
so
I
need
to
compromise
somewhere,
but
foreign.
A
I'm
trying
to
find
the
most
flexible
way
to
get
that
feedback,
and
so
that's
why
I
was
saying
hey.
If
just
to
have
someone
say
we
ran
this
test,
we
can't
we
can't
show
you
all
the
details.
We
actually
did
run
your
performance
test.
We
we
have
a
server
that
we
can't
present
to
you
that
everything
shows
up
the
screen.
E
A
G
And
then
that's
that's
really
the
point
right.
It
is
that
a
any
anybody
from
the
client
side
is
able
to
run
this
test.