►
From YouTube: OCI Weekly Discussion - 2023-04-27
A
B
H
H
So
I
think
merge
this
and
then
push
a
tag
manually
from
the
command
line.
Is
that
check
out
the
command
and
push
it
manually?
Does
that
sound
right.
H
F
H
That
it
is
I
wish
Vince
was
here,
I
think,
is
this
actually
better
December.
H
H
H
H
All
right
that's
going,
and
then
this
should
push
a
PDF
and
markdown
version
of
the
specs.
H
C
H
Okay,
I
think
these
artifacts,
the
PDFs
and
stuff
need
to
be
done
manually
by
the
way
so
I'm
gonna
do
that.
C
And
I'm
I'm
trying
to
understand
Alexis
point.
A
I
I
D
I
D
I
C
C
A
C
C
B
B
C
C
C
A
E
I
F
Were
there
other
release
related
items
before
we
proceed?
Aaron
we
just
cut
I
did
I
had
nothing
to
do
with
it.
Josh
and
John
just
got
release
candidates
of
image.
Back-End
distributions
back,
but
I
think
we're
done
with
that.
Unless
anybody
wants
to
talk
about
sember,
okay,
so.
G
F
I'll
jump
the
queue
a
little
bit,
but
I
think
it's
fast.
Wasm
is
back
and
wants
to
change
our
advice,
or
rather
remove
our
special
casing
for
wasn't.
The
advice
had
been
image
spec
when
specifying
a
platform
says
use
what
go
uses
go
at
that
time.
Didn't
have
a
thing
for
wasm
or
it
did,
but
it
was
like
Js
wasm.
F
We
sent
a
change
through.
That
said,
Don't,
listen
to
go
about,
wasm,
just
use,
wazzy,
wazz
and
wazzy
as
the
platform
and
since
then
go
has
added
a
platform
for
wasm,
which
is
called
wasm,
wazzy
P1
or
in
the
future.
Wasm
was
ep2
and
in
the
future,
was
he
when
it's
done
being
a
preview,
so
I
think
what
we
should
do
is
remove
the
special
case
and
say:
if
you're,
you
should
still
just
always
do
what
go
says
he
won.
Wasm
was
ep1
is
a
valid
platform
and
the
one
you
should
use.
F
J
Try
to
articulate
my
thoughts,
I
think
that
we
should
allow
other
languages
to
dictate
their
own
platforms
and
I,
don't
think
like
if,
if
rust
and
other
languages
want
to
also
Define
their
own
architecture
or
another
wasm
runtime
comes
along,
we
should
include
language
that,
if
it's
a
like
sort
of
like
the
don't
generate
an
error,
if
you
know
so,
don't
error
on
unexpected
platforms.
Just
don't
you
just
don't
know
how
to
run
them.
That's
fine.
F
Yeah
I
I
do
agree
with
you,
I
think
the
small
tactical
change
on
the
table
is
remove
this
line
and
align
with
previous
advice.
I
do
think
in
the
long
term.
General
case
we
need
to
like
we'll
probably
find
a
case
where
we
need
to
have
another
special
thing
where
like
go,
does
this,
but
we
want
everyone
else
to
do
this,
so
the
community
does
this
already,
and
we
just
want
to
specify
that
this
is
what
everyone
should
do
in
the
future.
That
might
not.
That
might
be
listen
to
go
for
these.
F
You
listen
to
rust,
for
these
here
are
three
other
special
cases,
but
I
think
we
should,
and
probably
like
you
said,
have
a
if
you
don't
recognize
the
platform,
don't
barf.
It's
probably
just
something
new
and
new
things,
though
they're
scary
are
okay,
but
I,
don't
think
I,
don't
think
we
need
to
make
that
guidance
in
this
in
the
small
tactical
change.
I
realize
we're.
Also,
we
just
cut
an
RC
and
I'm
requesting
making
a
new
change
so
I'm.
F
Sorry
about
that,
but
I'm
trying
to
make
the
smallest
possible
change
before
cutting
an
actual
release
and
then
yeah.
We
can
talk
about
platform
guidance
generalization.
F
You
know
as
they
come
up
in
the
future.
We
did
talk
about
that
some
when
we
talked
about
the
exception
to
the
go
rule
for
wasm
that
in
general
I
think
we
all
know
that,
like
we
should
get
off
of
just
writing
goes
coattails
John,
you
had
your
hand
up,
and
then
you
took
it
down.
Did
I
you've
covered
it.
Okay,
great.
F
J
I
think
I
had
the
the
next
episode
I
want
to
push
PR
1030
to
next
week
and
I
wanted
to
ask
if
it
belongs
better
as
a
PR
on
distribution,
spec
or
image
stack,
there's
a
line
that
Brandon
suggested
I
change
on
PR
1030,
about
implementations
that
are
sort
of
involved
in
in
storing
and
copying
content
that
they
should
essentially
I
want
to
think
about.
J
How
could
we
make
the
oci
spec
explicitly
forward
compatible
and
prevent
an
oci,
1.2,
Log,
Jam
or
future
issue
that
essentially
caused
so
much
conservation
with
the
artifact
manifest
right
and
as
long
as
implementations
are
able
to
implement,
allow
lists
of
acceptable
content
and
manifest
types?
J
It's
always
going
to
be
an
issue
where,
like
the
analysis
that
we
did
on
someone
did
on
issue,
10,
25,
I,
believe
of
putting
various
types
of
of
content
to
Registries,
there's
always
going
to
be
Registries
that
just
it
if
they've
implemented
an
allow
list
are
not
going
to
accept
anything
new,
that's
standardized
and
that's
always
going
to
be
a
blocker
I.
J
Think
there's
a
real
opportunity
to
think
about,
especially
in
the
context
of
this
artifact
type
field,
requiring
that
implementations
don't
Implement,
allow
us,
because
that's
just
antithetical
to
or
compatibility
and
being
able
to
progress
the
standard.
J
So
I
wanted
to
have
an
open
conversation
here
about
how
do
people
feel
about
requiring
that
again?
These
implementations
that
are
involved
in
storing
and
copying
I
want
to
focus
on
that.
Like
things
like
oci
registry
proxies
or
private
registry
implementations,
things
like
that
that
if
they
don't
support
arbitrary
content
types
or
media
types,
end
up
being
blockers
to
new
functionality,
I
mean
eventually
we're
going
to
want
something
like
a
new
manifest
type
and
we're
not
going
to
be
able
to
support
it.
J
I,
don't
think
that's
quite
true
Brandon
that
every
registry
today
has
a
manifest.
Allow
us
I,
don't
believe.
That's
the
case.
I
think
there
are
Registries
that
that
don't
don't
inspect
the
media
type
or
they
don't
require
a
specific
media
type.
For
example,
they've
experimented
with,
for
example,
artifact,
manifests.
J
C
Is
it
is
challenging
to
implement
things
in
that
way,
but
I
think
it
is
technically
possible.
I
would
be
surprised
if
there
was
a
registry
that
didn't
look
at
the
content
of
a
manifest
at
all,
but
I
I
think
it
is
probably
possible.
J
If
Registries
restrict
content
types,
then
things
like
s-bombs
or
signatures
like
as
the
external
Community
innovates
here,
what
wazzy
programs,
for
example,
if
they
create
a
image
manifest
that
contains
a
wowzing
program,
that's
not
going
to
be
portable
across
different
Registries.
Unless
we
have
made
it
clear
that
arbitrary
layer
types
would
be
accepted,
and
it's
currently
not
explicitly
the
case.
J
J
If
registers
want
to
say
they
don't
want
to
participate
in
the
helm
ecosystem,
and
then
they
want
to
choose
one
by
one
that
they
just
don't
want
to
participate
in
things,
but
as
sort
of
a
default
I
think
accepting
content
should
be
the
norm
because
otherwise,
again
there
won't
be
portability
for
any
of
these
innovators
in
this
ecosystem.
J
J
J
C
I
think
a
a
PR
and
image
spec
clarifying
that
the
media
type
can
be
arbitrary
and
the
artifact
type
can
be
arbitrary,
is
important
and
then
maybe
considerations
on
distribution
spec
about
like
these
should
be
opaque
to
you,
like
you,.
J
Okay,
I
think
if
no
one
objects
it
I'm,
gonna
I'll,
make
sure
10
30
lines
up
with
that
sort
of
thought,
and
it
seems
there's
still
a
lot
of
confirmation
around
or
rather
silence
around
supporting
for
compatibility
of
manifest.
But
I
want
to
keep
this
conversation
going
on
on
manifest
because
I
just
think
that
there's
going
to
be
a
well
eventually
there's
going
to
be
a
oci
1.2
or
oci
2.0
and
I
want
to
be
Forward
Thinking
about
mitigating
The,
Log
Jam
that
occurred.
C
Yeah
I
I,
practically
right,
like
a
registry,
won't
support
a
new,
manifest
media
type
and
be
able
to
do
the
things
the
Registries
do,
and
people
expect
them
to
do.
It
needs
to
parse
it
in
some
way
and
like
you
could
write
a
parser
that
doesn't
actually
care
about
the
exact
format.
But
if.
A
C
Rethink
like
how
the
spec
is
worded
and
how
it
works,
because
every
implementation
I've
looked
at
basically
takes
the
structs
in
the
spec
and
Marshalls
and
unmarshals
them,
and
so
you
can't
do
that.
If,
if
we
allow
arbitrary
formats
and
that's
a
problem
to
be
solved,
that
would
be
a
prerequisite
for
any
language.
That's
like
registry
should
allow
arbitrary
to
manifest.
C
I,
don't
have
a
good
solution
to
offer
to
the
problem,
but
it
is
a
problem.
J
I
think
you've
suggested
some
things
in
the
past,
if
you're
worth
exploring
of
what
typing
or
creating
a
more
abstract,
artifact
type
in
the
future.
That
is
just
fully
General,
so
I
think
it's
worth
talking
about
and
exploring
those
options
going
forward.
J
That's
that's
all
I
had
is
I
just
wanted
to
take
the
temperature
there.
Unfortunately,
I
only
got
a
couple
signals
on
arbitrary
content,
but
I'll
revise
PR
1030
or
next
week.
G
C
I
was
trying
to
think
of
a
response
that
would
live
up
to
that
level
of
quality
and
I
just
drew
a
blank.
Wow.