►
From YouTube: OCI Weekly Discussion - 2022-09-01
B
A
A
B
C
B
I
I,
don't
think
we
specified
exactly
what's
going
to
happen
for
cutting
the
1.1
release.
I
know:
there's
been
a
request
over
an
image,
spec
to
say:
hey,
can
you
cut
a
1.0.x
release
and
I
would
be
good
doing
that?
That's
separate
from
what
we're
doing
they
wanted
to
have
released
from
before
we
merge
all
our
stuff
and
we
can
easily
go
out
and
pull
those
over
into
the
branch
so
yeah
there.
There
is
some
Repro
maintenance
through
there
from
last
week,
because
yeah
that
recording
didn't
get
posted.
B
The
decision
was
okay,
we're
good
merging
this
stuff,
but
we
did
have
a
punch
list
of
things
we
wanted
to
finish
up
and
add
to
this
after
the
fact,
and
so
people
are
saying:
okay,
we're
comfortable,
hitting
merge
as
long
as
we
agree,
we're
going
to
come
back
and
fix
on
these
other
things,
so
I
think
a
bunch
of
that
was
Mike
and
I.
Don't
see
him
here.
Yet
he'll
probably
show
up
in
two
minutes
now
that
I've
called
his
name
out
in
public
but
yeah.
B
B
B
B
The
buttons
refers
naming
so
they
were
starting
to
get
into,
and
this
is
kind
of
one
of
the
reasons
I
wanted
to
jump
in
and
see
who
showed
up
today
they
were
debating,
refers
versus
other
names
and
I
feel
like
if
we're
going
to
rename
any
of
these
apis
and
Fields
inside
of
the
Manifest.
We
should
do
that
much
earlier
rather
than
later
so.
B
I
want
to
make
sure
that
one
gets
kind
of
a
high
priority.
I,
don't
know
if
we
need
to
but
I
know,
there's
just
been
kind
of
back
and
forth.
People
saying
is
that
really
the
name
you
want
to
have,
and
so
if
we
want
to
bike,
shut
that,
let's,
let's
knock
that
out
I
think
the
must
language
got
merged
already.
So
let
me
pull
up
the
PRS
over
here
see
how
we
merged
in,
for
this.
B
See
we
added
the
spec
MD?
Actually,
the
must
language
I
think
that
was
pulling
in
from
Mike's
comment.
He
said
there
was
something
for
a
must
language
in
there
and
I,
don't
know
which,
specifically,
he
was
talking
about
over
on
image,
spec
and
then
I
tagged
him
on
this
one,
because
I
wasn't
sure
what
he
wanted
on
that
either.
So
I
think
I
think
these
last
two
are
Mike
and
then
the
naming
is
just
kind
of
a
general
there's
been
discussion
on
that
going
back
and
forth.
B
People
just
started
by
sharing
the
names
of
things
saying:
okay.
Well,
if
refers
is
difficult
to
understand,
do
we
want
to
change
it
to
the
subject
or
something
else
like
that?
It's
over
there
going
back
and
forth
on
different
names
of
what
they
want
to
call
it
and
I
I,
don't
know
if
you
were
at
the
point
that
we
were
saying:
okay,
we
are
going
to
change
it,
but
there
there
was
a
little
bit
of
bike
shedding
going
on
over
there.
C
C
A
B
B
B
We
might
actually
do
have
a
couple
in
there.
So
I
could
hit
merge
on
this.
For
everybody
let's
go
with
that
refers
to
call
it
refers
field
and
refers
list
that
is
changed
a
little
bit
of
stuff.
They
said
to
get
rid
of
all
the
uppercase.
That
was
where
most
of
this
change
came
from,
but
the
rate
for
specifically
said
instead
of
saying,
refers
and
refers,
say
refers
field
and
refers
list,
and
that
way,
it's
kind
of
very
clear
we're
talking
about
the
list
that
you
get
back
from
the
API
versus
the
field.
B
B
D
B
A
B
B
A
B
B
D
C
B
C
B
B
B
B
C
B
Cool
so
let's
see
so
yeah
we
did
that
line
on
I'm
in
there
the
error
code
realized.
We
didn't
have
an
error
code.
If
there
was
ever
any
parsing
issue
or
something
like
that,
we
we
can't
do
a
404,
so
we
need
to
have
some
other
error
code
in
there.
So
we
got
that
in
there
and
let's
see
that
was
a
bee
bats
thing
saying
make
it
a
big
bright
note
thing
or
something
saying
that
we
can
have
race
conditions
and
data
loss
effects
and
effectors.
B
B
Most
people
is
just
changing
case
on
stuff.
So
that's
why
it's
all
over
the
place.
They
came
back
and
said:
don't
make
all
the
defined
terms
uppercase,
so
I
just
went
through
and
changed
those
to
lowercase
Vincent's,
make
sure
there's
a
big
shiny,
note
thing
over
there
italic
or
something
so
that
people
get
attention
to
that
and
let's
see
I
think
that
was
most
of
this
so
Josh,
even
though
we
changed
that
from
ref
to
digest,
hopefully
you're.
Okay
with
that.
C
C
B
B
Wait
we
haven't
said
no,
we
we
just
said
not
to
start
with,
but
yeah
it's
the
flexibility
is
there.
We
need
to
add
later
on
so
cool
I,
remember
seeing
two
approved,
so
this
is
good
to
be
merged
and
one
of
those
mic
and
easier.
So
that's
good.
The
other
shoe
Josh.
Let's
see
anybody
else
on
this
list.
Feed
batch
a
lot
of
people
didn't
comment,
but
I
don't
think
I
was
expecting
them,
but.
D
B
B
B
One
last
thing:
so
with
that
done,
we
got
a
bunch
of
items
that
I
got
knocked
out,
I'm
going
to
leave
these
first
two
just
in
case.
If
you
want
to
keep
playing
around
the
names,
let's
see
to
find
words,
we
cleared
that
one
out
registry
should
the
must.
We
got
questions
on
that.
One,
in
fact,
Mike
was
that
you
asking
about
the
should
the
muster
was
that
the
other
mic
I
feel
like
somebody
comment
on
that.
E
E
E
B
B
I
wonder
I
couldn't
find
it
I'm
used
to
seeing
it
in
the
spec,
where
everything's
separated
by
one
lineage
registry
should
accept
refers
when
it
doesn't
exists.
This
plan
we
were
talking
about
so
it's
an
open
question
of
whether
or
not
we
want
to
change
this
line
to
a
registry
must
accept
a
manifest
with
a
refreshed
yield
that
does
not
exist
because
the
question
becomes
a
few
things.
One
is
backward
compatibility
today
we
can
already
push.
B
Our
refers
doesn't
exist
because
the
registry
doesn't
even
know
what
it
refers
is,
and
so
it's
not
even
looking
at
that
field
and
so
clients
can
push.
This
class
can
push
the
index
with
the
tag
digest
thing,
and
so
we're
able
to
do
this
today
with
backward
compatibility
solution
so
going
from
the
Backward
Compatible
solution
to
the
new
forward
solution
in
there
when
Registries
do
know
how
to
work
with
this
field,
should
they
be
allowed
to
then
change
their
mind
and
say
well
you
already
before,
but
now
you
can't
push
it
anymore.
B
So
that's
one
question
or
one
way
to
look
at
this
and
the
other
way
to
look
at
it
is
that
I've
been
looking
at
it
as
a
complete
manifest,
and
so,
if
I'm
pushing
something
for
the
registry
and
I'm
copying
stuff
over
or
I'm
uploading
a
built
image,
I
like
to
make
it
for
myself
when
damage
is
first
pushed
that
when
it's
available,
you
pulled
from
a
manifest
that
everything
I
need
to
pull.
Is
there,
and
so
today
we're
looking
at
that
from
blobs.
B
So
you've
got
every
blob
out
there
already
you
can
pull
all
the
blobs
to
config
and
everything,
because
you
know
all
that
is
there
before
you
pull
that
manifest,
and
so,
if
we're
going
to
add
signatures,
s-bombs
things
like
that.
It
feels
useful
to
me
to
know
that
when
that
manifest
is
there
that
all
the
other
metadata
around
that
image
is
also
there,
so
that
that's
the
way
I'm
looking
at
it,
but
I
want
to
leave
it
open
to
the
restroom.
B
I'll,
give
you
an
even
farther
left
field
scenario,
which
is
that
a
lot
of
people
are
looking
for
how
they
can
track
attestation
signatures
s-bombs
all
that
stuff
on
things
that
aren't
container
images,
things
that
aren't
even
up
in
an
oci
registry,
but
they
want
to
use
the
registry
itself
as
a
place
to
store
all
the
metadata
around
that
data.
So
if
they
build
a
binary,
they
get
the
digest
for
binary,
and
then
they
just
say:
hey
go
where
there's
oci
registry
give
it
that
digest.
B
B
C
B
A
B
B
So
he
got
the
two
officers
here.
What
I
was
going
to
ask
is:
do
we
want
to
just
open
this
up
as
like
a
quick
verb
thing
that
we
we
did
several
verbs
before
some
people
that
didn't
have
that
weren't
vocal
on
a
meeting
came
around
and
came
out
with
a
vote
after
the
fact,
and
so
that
might
make
this
easier
for
people
to
look
at
this
think
it
over
and
then
make
up
their
mind.
C
B
B
So
I
think
that's
the
big
stuff
that
we
want
to
cover
going
forward,
and
so,
as
long
as
we
get
some
of
niche's
bullet
points
in
there,
we
can
also,
let's
see
where
is
it
this
one?
So
if
Nisha
drops
comment,
I,
don't
know
if
you've
already
done,
I
just
need
to
hit
refresh
or
you're
still
working
on
them,
yeah
to
kind
of
go
through
and
think
about
other
names.
If
we
want
to,
if
we
want
to
change
names,.