►
From YouTube: OCI Weekly Discussion - 2022-09-08
B
A
A
That
one
has
the
discussion
on
what
we
call
this
thing.
If
we're
going
to
rename
it,
and
so
if
we
do
that,
I
want
to
do
that
sooner
rather
than
later,
and
otherwise
say
that
we're
stuck
with
the
name
and
live
with
it
because
code's
starting
to
get
written
and
I
think
people
want
to
be
able
to
commit
and
release
at
least
I.
Do.
B
A
C
A
C
A
We're
just
going
to
stick
with
status
quo
unless
there's
we're
really
close
on,
relates
to
relationships.
A
I
wasn't
a
fan
of
the
underscore.
We
could
always
change
that
to
camel
case
if
we
needed
to.
A
A
A
A
A
So
this
was
the
follow-up
on
the
language
here
that
says
a
registry
May
reject
the
Manifest
if
it
doesn't
see
the
blob,
but
that
originally
we're
saying
it
should
accept
a
manifest
if
it
sees
a
reference
to
a
manifest,
doesn't
exist,
the
reverse
field,
and
so
that
was
kind
of
giving
us
some
guidance
a
little
bit
of
guidance.
Saying
hey.
You
probably
should
allow
this.
But
logically
those
two
are
identical,
because
it's
basically
saying
mayonn
either
may
be
checked
on
either,
and
so
the
question
here
was:
do
we
want
to
change
that?
A
A
If
it
instead
of
that
refer
that
references,
if
it
references
the
concern
here,
I
was
looking
at
was,
if
we
say
a
registry
must
accept
and
manifest
with
a
refers
field
to
manifest
that
exist.
That
kind
of
implies
that
you
can
break
everything
else
and
the
repo.
As
long
as
you
have
a
reference
to
a
manifest
that
exists,
then
the
registry
must
accept
it
and
I
was
like
that's
not
really.
What
we're
trying
to
say
here
and
so
I
was
looking
at
other
ways
to
phrase
that
of
saying.
A
Maybe
a
registry
must
not
reject
a
manifest
because
a
refers
field,
references
manifest
that
does
not
exist,
and
that
might
be
a
little
bit
more
clear
of
what
we're
trying
to
say
is
the
word
because
does
that
make
sense
in
the
specs?
The
way
we've
been
writing
so
far,
or
is
that
the
wrong
word
to
use.
A
We
were
looking
at
just
for
the
first
field
because,
right
now
the
language
says:
apologies
for
the
scrolling
that
a
registry
May
reject
if
it
references
a
blob
that
doesn't
exist
and
right
now
pretty
much.
Every
registry
out
there
that
I've
seen
takes
us
a
lot
more
strict
and
they
basically
say
we
are
going
to
reject
your
manifest.
If
you
try
to
upload
and
the
lobby,
your
referencing
doesn't
exist
and
we've
even
got
the
error
code
to
find
and
everything
in
there.
A
So
if
you
try
to
push
a
manifest
before
you
push,
the
blobs
registry
says
Nope:
wait.
You
need
to
push
the
Bobs
first,
and
this
is
one
of
those
few
cases
where
we
said.
Actually,
let's
flip
that
scenario
around
make
it
so
that
the
registry
needs
to
allow
the
push
of
the
man
the
push
of
the
reaper
before
the
Manifest
that
it
refers
to
exist.
So
that's
inverting.
It
go
ahead.
Nisha.
C
Oh
I
was
going
through
my
head,
whether
it's
okay
to
say,
like
registry
May,
reject
a
manifest,
but.
A
In
other
words,
this
line
in
the
middle
here
is
redundant
because
should
accept
as
the
same
thing
as
May
reject
it's.
You
know
we
just
invert
the
terminology
there,
but
otherwise
it's
the
exact
same
condition
there,
and
so,
given
that
it
was
a
question
of
why
do
we
even
need
that
in
there
and
the
other
question
is
well?
If
a
registry
can
reject,
then
what
does
that
do
to
client
implementations
and
other
use
cases
out
there
in
it?
A
It
really
drove
it
to
me
that
I'm
wondering
does
it
make
sense
just
to
change
it
to
a
must,
because
for
a
lot
of
the
use
cases
I'm
thinking
of
it's
nice,
that
the
client
can
know
that
it's
allowed
to
push
this
and
that's
going
to
be
portable
across
all
Registries.
It
doesn't
have
to
worry
about
this
right,
she's,
going
to
reject
that
this
one's
going
to
accept
it,
and
it
needs
to
worry
about
the
different
use
cases
depending
on
where
it
sends
the
artifact
to.
A
And
I
see
Mike
Brown's
comment:
couldn't
move
forward
a
stronger
language
and
who
wants
to
open
the
pr
I'm
happy
to
open
the
pr
on
that
one
as
long
as
we're
thumbs
up
on
what
we
can
do
with
that
one.
A
For
wording-wise
on
this
I
kind
of
I
don't
want
to
change
it.
Just
must
accept
that
references,
a
manifest
does
not
exist,
because
that
gives
that
a
little
overzealous
terminology
there
that
someone
might
interpret
wrong
and
so
either
if
it
re,
if
it
references
a
manifest
that,
if
kind
of
gives
a
little
bit
more
clear
that
we're
saying
hey
if
the
Manifest
doesn't
exist,
you
can't
you
must
accept
it
because
of
that.
But
not
if
something
else
is
wrong
with
it.
A
All
right
so
I
will
throw
that
as
an
action
item.
I,
don't
think,
we've
seen
any
other
complaint
here,
I'm,
not
sure
what
Nemo
was
saying
in
this
I
was
a
little
bit
confused
of
what
was
going
on
with
other
people
follow
along
with
that
feel
free.
D
A
B
A
B
A
Since
we
picked
the
name
I
think
we
got
that
and
since
we've
got
our
should
to
a
must
I
think
we
got
that
language
in
there.
There
was
a
comment
early
on.
If
we
wanted
to
include
some
details
of
why
we
were
saying
that
I
can
put
a
little
bit
in
there,
but
I
want
to
try
to
be
careful,
I,
don't
step
on
the
GC
language,
just
because
we've
been
careful
not
to
include
that
in
the
specs
so
far
and
I
don't
want
to
be
the
one
that
touched
the
third
rail.
C
No,
the
the
the
fact
that
the
registry.
C
A
A
A
When
we
get
the
other
Michael
Brown
here,
I
think
he's
probably
got
a
few
items
that
he
wants
to
talk
about
still,
but
I.
Don't
know
enough
about
his
ideas
to
comment
for
him.
A
D
We
have
to
what
I,
if
checks
for
each
one
right
I
was
thinking
like
I,
think
it's
just
being
the
picky
here,
but
if
the
three
words
four
must
not
reject,
then
let's
just
go
with
that:
I
don't
have
any
I'm,
not
gonna
block
on
that.
It's
just
the
second
one
to
me
seems
much
more
clearer,
basically
you're,
saying
that
the
registry
must
accept
so
you
can
write
a
conformance
with
accepting
manifest
type
so
and
a
null
reference
field
or
a
reference
field
that
doesn't
have
the
digest
versus.
D
A
Yeah,
the
the
reason
that
I'm
concerned
about
the
wording
is
I'm,
just
I
think
I
want
to
make
sure
we
don't
allow
is
to
say
if
you
upload
a
manifest
that
has
31st
you'll
point
to
a
missing
manifest
just
doesn't
exist
on
the
machine
that
that's
not
an
excuse
that
you're
allowed
to
push
that
one
with
15
other
things
wrong
with
it.
Every
other
blob
missing
or
something
like
that
that
doesn't
override
all
the
other
checks
that
are
also
happening.
A
D
A
D
We
invert
the
wording
saying
that
the
reference
field,
the
the
Manifest,
that
that
first
field
is
pointing
to
may
not
exist
in
the
repository,
rather
than
talking
about
the
the
acceptance
or
objectives
of
the
reject
projecting
of
the
Manifest
itself.
Because
what
you're
trying
to
say
is
that
this
Manifesto
is
a
valid
manifest.
Even
if
the
reference
field
is
pointing
to
an
invalid
manifest.
As
long
as
it's
a
proper
descriptor.
D
It's
just
about
how
like
I,
think
I
did
not
see.
The
point
that
you
were
saying,
which
is
just
because
the
reference
wheel
is
invalid,
doesn't
mean
the
Manifest
is
valid
right.
So
that
makes
sense,
but
you
need
to
kind
of
like
I
think.
The
point
is
here
that
we
want
to
make
is
that
the
reference
field
might
point
to
something
that
is
non-existent
at
this
point.
A
Sounds
like
it
could
yeah.
That
might
be
another
good
way
of
saying
it
all
right.
I
can
I
can
work
on
that
as
up
here
all
day
on
cool,
so
20
minutes
in
we
finished
up
all
the
bullets
here.
I
think
we
finished
up
this
bullet
here.
The
other
one
was
coming
off
from
a
comment
from
Michael
Brown,
the
other
Michael
Brown,
so
I
don't
know
how
to
answer
that
one
either
I
can't
represent
them
here
on
this
one.
A
A
A
We
add
the
distribution
spec
a
while
back,
but
we
didn't
update
the
documentation
on
the
page
to
say
we
added
distribution
specs.
Now
this
just
going
through
and
everywhere
it
said
two
specifications.
It
changes
to
three
and
everywhere
we
mentioned
the
list
of
specifications
out
there.
We've
got
a
runtime
spec,
an
image
spec
and
a
distribute.
Now,
we've
added
that
we
also
have
a
distribution
spec.
A
A
And
yeah,
if
anybody
has
a
chance,
give
it
a
look,
I
think
we
got
a
few
people
over
here
that
probably
have
maintainer
access
over
there.
It's
I
don't
know
how
I
got
add
on
to
that
which
one
of
the
distribution,
I
misspecker
I,
guess
any
spec.
They
threw
me
on
the
maintainer
list
and
that
one
so
I
think
that's
pretty
open
for
us
a
thumbs
up.
B
A
Right
so
with
that,
you
know,
I'll,
say
Samuel
if
you
chime
in
over
there
and
give
that
your
thumbs
up
I'll.
Take
that
as
good
enough
for
me,
it's
technically
I
can
hit
merge
on
it
right
now.
It's
not
blocking
me
from
merging
it.
I
just
want
to
get
a
second
thumbs
up.
A
D
If
I
didn't
put
this
on
the
agenda,
unfortunately,
but
you're
aware
of
this
PR
Brennan,
the
schema
changes
to
in
the
schema
test
for
the
refers
as
well
that's
open
as
a
PR.
So
if
you
do
get
time,
I
can
ping
tag
you
and
others
on
the
on
that.
As
well
said.
A
A
That
one
we've
got
a
we're
waiting
on
a
second
thumbs
up
over
there,
so
it
can't
be
me
that.
A
This
one
also
brought
into
question,
and
someone
saw
it
and
jumped
in
there
and
did
across
the
board,
which
was
good
and
slightly
bad,
only
slightly
bad
to
change
all
the
Iowa
util
references,
because
if
anybody
knows
to
go
like
side
of
this,
go
like
deprecated
that
whole
package
a
while
back,
so
they
went
through
and
did
the
renames
all
the
new
names
of
the
fields.
A
One
or
the
other
I'll
just
have
to
rebase:
it's
not
a
big
deal
but
yeah
I've
already,
given
you
the
thumbs
up
on
that
one
I
think
I've
also
given
a
thumbs
up
over
here.
So
we
just
need
someone
else
to
jump
over
there
yep
someone
else
jump
in
there
and
hit
approve,
and
then
we
can
get
that
knocked
out.
C
Not
for
me
I
think
I'll
be
spending
my
time
doing
other
things.
Now
you
may
not
see
me
as
often
as.