►
From YouTube: OCI Weekly Discussion - 2023-05-18
B
A
But
Brandon
I
don't
know
whether
it's
actually
not
this
article,
but
Microsoft
did
some
analysis
on
how
much
time
we
spent
in
writing
emails
and
sitting
in
meetings
or
spending
in
meetings.
So
it
turns
out
it
two
days
out
of
the
five
days
that
we
have
in
the
work
week
very
relevant
to
our
topic
of
discussion.
D
B
E
F
B
I
should
probably
also
pull
in
the
Dev
thread
over
there,
because
we're
going
to
talk
about
that
over
here,
a
little
bit
lust,
Dev
versus
maestev,
syntax
on
the
SIM
for
I.
Think
they've
had
a
lot
more
discussion
on
their
thread.
B
So
the
easy
ones,
while
waiting
for
anybody
left
to
show
up
I've,
got
a
few
that
are
just
sitting
out
there
for
like
actionable
items.
I,
don't
know
how
much
discussion
there's
need
on
them,
but
the
plus
Dev
and
the
version
numbers
the
first
one
up
there.
We've
got
an
issue
over
an
image,
spec,
there's
one
over
on
runtime
spec.
If
we
don't
have
it,
we
need
one
over
in
distributions
spec
as
well
I
think
or
do
we
I
think
we
at
least
keep
track
of
something
over
here.
B
I'll
have
to
dig,
but
the
plus
Dev
is
kind
of
the
indicator
that
this
is
development
work
after
whatever
that
commit
was
versus
before,
and
so
it's
the
proper
order
when
you're
looking
at
semper.
B
So
we
got
a
few
PR
sitting
out
for
that.
If
folks
want
to
look
at
those,
the
other
quick
actionable
item
in
there
that
threw
in
just
shortly
for
this
was
someone
was
commenting
on
what
the
scratch
blob
content
should
be,
and
I
said:
yeah
it's
right
over
there
in
the
description
and
then
I
went
look
and
I
was
like.
Oh,
we
didn't
actually
document
the
content
of
the
scratch
blob
where
we
are
defining
what
the
scratch
descriptor
looked
like,
and
so
one
line
change
there.
B
B
It's
kind
of
gone
back
and
forth
different
different
interpretations,
but
the
gist
of
it
is
that
they
want
to
specify
that,
when
converting
from
the
image
spec
to
the
runtime
spec
that
you
might
not
want
to
convert
everything
over
all
The
annotation
server
and
then
the
runtime
specification
there's
back
and
forth
with
some
language
on
the
implementer's
note
saying
that,
oh
by
the
way,
a
bunch
of
the
runtimes
out
there
a
day,
they
don't
do
this
anyway,
even
though
it
is
a
should
and
parts
of
it
or
must
another
components.
B
It
gave
me
hesitation
seeing
that
for
anyone
that
hadn't
had
a
chance
to
read
this,
that
the
hesitation
for
me
is
just
knowing
that
so
much
what
we've
been
doing
is
kind
of
a
backward
spec.
B
You
know
defining
what
someone's
already
been
doing,
and
then
we
just
specify
that
in
the
specification
and
here
we're
saying
that
what
everybody
is
doing
is
wrong:
we're
defining
the
opposite,
behavior
and
respect,
and
so
it
gives
me
a
little
bit
of
pause
to
see
that
on
the
flip
side,
a
lot
of
this
language
has
been
in
the
spec
for
a
very
long
time,
and
so
things
that
we
said
that
you're
supposed
to
be
doing.
We
have
been
doing
and
no
one's
really
complained.
B
Art
that
really
confused
me
jump
it
off
go
ahead.
B
It's
I
I've
questioned
that
myself,
it's
been
over
here
in
image
specs
since
the
early
days
for
a
very
long
time
and
it's
the
border
between
image
and
runtime
so
apparently
way
back
in
the
day
they
felt
it
belonged
over
here.
B
But
it
kind
of
goes
to
comment
that
through
and
was
saying
that
probably
only
makes
sense
for
people
that
are
in
both
to
really
be
looking
or
people
that
are
in
both
specs
are
the
only
ones
that
are
really
going
to
understand
this
and
I'm,
not
one
of
them.
I
think
a
bunch
of
us
here
are
not
in
both
specs.
So
is
not
the
easiest
to
review
for
us,
not
knowing
what
happens
over
on
the
runtime
side.
G
B
F
Well,
I
mean
this
is
a
complicated
subject:
right
should
the
clients
of
oci
be
able
to
pass
a
label
or
an
annotation
right,
and
what,
if
one
of
those
annotations
would
do
security
interesting
topic?
You
know,
but
it's
sort
of
up
to
the
clients
and
the
administrators
to
do
that.
I
would
suggest
that
container
runtimes
provide
some
kind
of
filtering
mechanism,
so
it's
certain
annotations
can
be
reduced
eliminated
either
completely
with
a
star
or
whatever
right.
F
I'm,
not
sure
this
needs
to
be
in
the
image
spec,
except
for
the
you
know
the
opportunity
for
the
image
spec
to
recommend.
You
know
what
happens
to
some
of
these
annotations,
so
the
you
know
should
they
only
be
read.
H
F
The
container
runtime
and
then
filtered
before
calling
the
runtime
engine.
That
seems
like
a
pretty
arbitrary
statement
right.
F
We
we
use
these
annotations,
usually
temporarily.
Until
you
know,
certain
features
have
been
implemented
either
as
a
cap
in
the
kubernetes,
for
example,
you
know
we're
in
a
container
runtime
for
some
new
native
desktop
type
application.
B
Yeah,
a
line
that
got
my
attention
was
a
little
bit
earlier
in
there
where
it
said
converters
should
not
extract
annotations,
which
I
thought
was
a
very
interesting
line,
since
the
very
next
thing
is
saying:
hey
if
there's
a
conflict
between
the
two,
you
should
use
config
labels
here
for
the
annotations.
So
it's
the
same.
You
just
told
me
not
to
use
it
now,
you're
telling
me
the
order
to
use
it
so
yeah
and
I
share
a
concern.
F
B
The
runtime
executes
I
share
I
think
it
was
probably
10
on
I'm,
not
sure
if
that
was
the
comment
or
it
might
have
been
made
elsewhere,
where
the
comment
was
made,
that
using
labels
instead
of
annotations
isn't
the
greatest,
because
labels
get
copied
from
the
base
image
down
to
the
resulting
image,
and
so
it's
very
easy
for
someone
in
a
base.
Image
change
just
update
latest
with
something
that
has
an
extra
label
on
there.
B
G
Conversion,
which
is
a
link
to
the
runtime
student
and
the
file
system,
bundle
spec
is
pretty
lightweight
and
it
feels
like
feels
like
everything
in
this
document
should
go
into
bundle.md
and
run
defense,
but
I'm
actually
also
a
little
confused,
because
it
seems
like
this
is
my
ignorance
of
the
state
of
the
world
and
yeah.
H
B
I
You'd
be
hopeful
if,
in
the
runtime
spec
there
was
something
that
could
be
linked
to
from
here
to
say
exactly
what
type
of
annotations
shouldn't
be
passed
on
passed
along
like
if
there's
specific
security
related
ones
or
like,
if
it
should
be
a
like
instead
of
filter
out
filter
in,
like
only
only
filter
in
annotations,
that
you
know
are
good
rather
than
these
known
bad
ones,
but
yeah
it's
it's
kind
of
unclear
like
as
an
implementer
there,
I
wouldn't
really
know
exactly
what
I
should
do
with
that.
Still.
H
H
H
B
Yeah,
so,
instead
of
calling
out
that
hey
some
of
these
are
there
are
these
implementations
and
they
should
not
do
this.
I
change
the
phrasing
and
say
they're
many
implementations
don't
and
for
portability,
try
to
depend
on
Behavior
assumptions
that
they
do.
H
B
C
B
This
came
up
after
an
issue
have
been
raised
for
a
while,
went
back
and
forth.
It
got
a
little
cold,
and
so,
instead
of
continuing
the
issue,
the
pr
was
raised
on
it.
It's
been
a
lot
of
back
and
forth
on
this
one
in
the
issue.
B
I
think
it's
a
little
bit
easier
to
follow
some
of
the
discussion
here,
but
the
request
is
that
we
already
Define
the
image
source
and
it
says:
hey,
there's
a
git
repo
here
where
all
this
is
stored
in
they
want
to
know
the
subpath
within
that
for
their
tooling,
so
they
can
uniquely
identify
what
was
being
built
and
what
was
the
bill
tonight.
They
were
working
with,
was
it
Bill,
pecks,
probably
Bill
packs
anyway,
I
think
it
was
Bill
Paxton
there,
and
so
the
suggestion
was
yeah.
B
It
was
the
suggestion
that
threw
in
at
the
very
end
here
was
to
say,
I
think
we're
looking
at
three
possible
different
things
going
on,
because
what
they
want
is
a
unique
way
to
say
this
is
the
image
we
created
out
of
here,
and
we
don't
have
a
way
to
say,
uniquely
that
when
you
do
a
build
from
a
certain
path
that
you
know
that
there
is
a
unique
image
that
comes
out
of
it.
If
you
do
a
build
from
something
like
a
Docker,
build
you've
got
build,
ours,
you've
got
the
build
targets.
B
You've
got
all
kinds
of
you
know
which
Docker
file
on
the
path,
all
kinds
of
ways
you
can
change
the
build
to
be
something
completely
different,
but
have
the
path
be
exactly
the
same,
whereas
other
tools,
it
is
unique
and
so
they're
looking
for
some
kind
of
unique
key.
If
they're
looking
for
that,
then
we
could
maybe
Define
what
a
unique
key
is.
B
If
we
really
want
to
know
what
the
sub
path
is,
then
we
should
probably
redefine
it
to
say
that
it
isn't
unique-
or
maybe
we
just
push
back
and
say
if
this
is
for
Bill
packs,
make
a
build
pack
annotation
for
their
environment
and
just
rely
on
that.
So
that
was
the
three
options.
B
I
threw
out
there
and
I
hadn't
heard
anything
back
from
them
since
that,
but
I
wanted
to
raise
this
one
up,
because
it
has
been
going
back
and
forth
a
little
bit
and
just
kind
of
want
to
get
a
little
bit
get
some
input
from
the
rest
of
the
group
here
see
what
people
think.
B
B
C
B
I
thought
this
might
get
more
responsible
in
the
group
than
it
is
no
strong
opinions
by
anybody.
B
B
E
A
B
B
Cool
other
than
that
toddy
you
raised
the
question:
do
you
want
to
ask
it
directly.
A
Yeah
I'm
just
curious
to
are
we
targeting
any
dates?
What
the
update
is
I
think
there
is
a
at
least
like
a
lot
of
interest
to
know
when
the
1.1
will
be
released
and
right
now
it's
like
the
last
date.
Everybody
knew
was
the
end
of
January,
beginning
of
February,
and
since
then
it's
I,
don't
think
at
least
I'm
not
aware
of
what
are
we
targeting
and
should
we
look
forward
to
a
specific
date
when
that
will
be
released
or
should
we
go
our
ways
and
hope
for
the
best.
B
I
always
thought
entertaining
where
he
was
a
very
aggressive
date,
but
it
motivates
some
people
to
get
a
little
bit
more
active
from
my.
C
B
B
Candidate
is
really
helpful,
so
I'm
glad
that's
out
and
I
see
a
lot
of
people
trying
to
do
some
implementations
I've
seen
for
us
do
stuff
on
their
side.
I've
seen
soft
do
stuff
on
their
side,
so
I'm
hoping
that
having
that
release
candidate
out,
there
is
getting
some
more
visibility
and
the
big
thing
that
I
want
to
do
before
he
releases
make
sure
that
all
the
conformance
tests
are
updated.
A
B
A
The
feedback
yeah
the
problem
that
actually
we
we
have
right
now
or
at
least-
and
this
is
kind
of
my
my
experience-
I'll
take
it.
That's
just
my
my
opinion,
but
I
think
we
are
afraid
to
do
anything
because
we
don't
know
what
change
will
happen
right.
So
we
are
in
this
sketch
22,
where
people
were
ready
back
in
January
and
then
something
happened
and
everybody
reverted
whatever
they
have
done
and
now
I
think.
F
Lisa,
it's
harder
to
revert
a
spec
after
it's
gone
out
permanently
it's
in
candidate
two
mode
right
now,
apologies
again,
for
you
know
the
change
and
plan
it's.
It
is
painful
and
we
understood
that.
F
A
it's
a
risky
take
when
you're
trying
to
generate
a
new
standard
as
opposed
to
following
you
know
the
standard
that
plus
users
have
picked
we're
trying
to
push
it
and
that
we
pushed
a
little
too
hard
I
think
either
way
it's
what
happened.
A
Okay,
yeah,
but
so
coming
back
Brandon
to
your
question,
so
RC
RC
we
had
rc1
rc2
rc3
right
now
like
we
can
have
RCS
forever
and
I
can
tell
you
that
from
experience
right
or
not
like
that
does
not
give
us
confidence
on
when
the
release
will
happen.
So.
F
Yeah
traditionally
we
we've
wanted
to
do
you
know
the
gas
faster,
but
we've
also
supported
release
candidates
for
years
on
some
of
the
specifications
we've
had.
So
it's
hard
it's
hard
to
pick
the
the
way.
The
way
you
move
forward
is
you
propose.
You
know
that
the
release
candidate
is
finished
and
see.
If
you
can
get
everybody
to
vote
for
it.
Sometimes
it
takes
more
years.
F
It
takes
a
lot
of
time
to
get
to
get
this
to
make
this
happen,
but
the
good
news,
the
oci
specification,
even
though
it
was
in
release
candidates
generally,
can
become
a
de
facto
standard
even
before
it
is.
You
know,
finalized.
G
Yeah
I
think
yeah.
There's
some
discussion
about
the
the
alarm
Tower
debate.
I
think
I
remain
disappointed
as
a
potential
implementer
and
user
of
the
spec,
because
in
the
current
form
we've
defined
refers,
we've
defined
the
capacity
to
attach
objects
to
images
we've
even
added
artifact
type,
but
there's
actually
nothing
in
the
spec.
G
That
requires
that
an
oci
1.1
registry,
allow
me
to
put
an
artifact
or
attach
a
s-bomb
and
that's
I,
think
a
pretty
glaring
a
mission
is
that
it's
a
it's
a
specification
that
doesn't
have
any
teeth,
because
there
are
implementations
that
could
fully
Implement
oci
1.1,
but
you
can
only
attach
images
to
images
which
is
just
like
an
absurd
like
we're
going
to
end
up
in
a
situation
where
people
are
going
to
end
up
sneaking
s-bombs
in
as
images
with
layer
with
layers
that
are
defined
as
layer
art.
G
You
know
blobs,
because
that's
what
we've
specified
and
I
think
we
need
to
address
that
I,
don't
think
we
can
release
it
1.1
unless
the
specification
actually
requires.
If
you
be
able
to
attach
something,
that's
not
an
image
or
upload
a
manifest
like
something
an
image.
G
B
So
I
thought
you
were
going
One
Direction
I
think
you
went
a
different
direction
in
there,
so
there
was
the
an
oci
registry
can
implement
this
without
the
new
artifact
manifest
that
we
had
been
working
on
for
all
that
time
and
so
use
the
image
manifest.
But
I
think
you're
going
the
other
direction
of
saying
that
Registries
can
reject
the
content
and
only
support
an
oci
image
and
not
all
the
other
artifacts
that
we're
going.
G
Yeah,
which
I
think
undermines
all
the
work
that
we
put
into
OCR
1.1
is
what
does
referrers
mean
if
they
can't.
H
G
I
can't
attach
an
annotation
I
think
OCR
1.1
has
to
you.
You
left
your
comment,
I
think
it's
an
appropriate
comment
on
10
30,
which
was
we
should
figure
out
what
Registries
want,
but
I
think
if
you
look
at
say
the
research
that
was
done
on
1025
right,
like
the
research
on
what
Registries
currently
support
today,
one
of
the
like
the
holdbacks,
the
was
the
Google's
container
registry
right,
but
they
are
deprecating.
G
B
I
think
that
that
one
was
a
different
reason,
I'm
happy
to
chat
with
you
all
on
that
one
I
think
there's
some
googlers
who'll
be
happy
to
chat
with
y'all,
find
that
one
the
registry
I
know
there's
going
to
be.
The
big
concern
is
kitlab
because
they
they
explicitly
block.
G
I,
what
can
we
do
to
be
proactive
here
and
unblocking
this
so
that
oci
1.1
is
a
is
a
meaningful
Baseline
for
client
implementations,
because,
right
now,
as
I
said
it
isn't,
it
isn't
something
that
a
wasm
producer
or
an
s-bomb
producer
or
any
artifact
producer
can
actually
say.
Oh
it's
LCA
1.1
our
tool
is
supported
right.
It
is
it's
a
specification
that
doesn't
actually
have
any
teeth
to
mean
something
for
client
implementations.
B
Yeah
I
mean
I've
run
into
a
scenario
just
the
other
day
where
I
realized
you
can't
push
by
digest,
which
is
breaking
my
head
right
now,
but
some
of
that
might
come
into
what
can
we
throw
into
the
conformance
and
if
you
find
a
way
to
put
in
a
conformance,
even
if
it's
not
a
hard,
must
in
the
spec
you
kind
of
throw
a
stick
there,
the
other
way,
I
I,
don't
know
we
want
to
go
that
direction
because
people
say
hey,
they
can
formation
only
enforce
the
must
not
the
shoulds,
but
there's
I.
B
Think
for
me,
it's
a
little
bit
of
shell
shock
after
pushing
out
the
working
group
that
we
worked
with
and
we
came
out
and
said:
here's
here's!
What
we're
looking
for
to
hear
registry
implementers
come
back
after
the
fact
that
weren't
part
of
that
discussion
and
say
they
had
concerns
with
some
of
the
stuff
we
were
doing.
They
were
making
decisions
on
their
part
that
were
completely
opposite.
What
we
were
pushing
for
in
the
whole
working
group,
and
so
before.
We
make
a
decision
like
this
I'd
love
to
get
more
feedback
from
those
registry
operators.
G
Yeah
I
guess
I
would
say,
I
think
we
probably
shouldn't
push
1.1
GA
until
we've
had
that
conversation
right
and
we
should
figure
out
what
this
impasse
is
and
I
think
that's
probably
on
the
maintainers.
The
people
who
are
you
know
officially
part
of
the
post
guy
image
spec
maintainers.
To
do
that
reaching
out
and
understand
you
know,
is
gitlab
taking
the
stance
that
they're
just
now
going
to
support
oci
1.1,
in
which
case
is
that
is
that
acceptable
right.
A
Yeah,
just
maybe
I'm
a
little
bit
confused
about
the
list
of
registry
operators
because
we
have
AWS,
we
have
a
say
Seattle
we
have
Aram
is
here
also
John
John
attends,
so
we
don't
have
representation
with
Harvard
and
jfrog
and
I
talk
with
both
these
actually
vendors
at
cubecon.
They
would
be
interested
to
participate
more,
but
at
the
end
of
the
day,
I
think
the
concerning
part
for
me
is
like.
A
If
one
of
the
Registries
doesn't
want
to
do
it,
then
how
do
we
move
the
the
industry
going
forward
and
everybody
else
is
on
board
and
I
don't
want
to
actually
do
that.
So
can
I
stop
this,
and
what
is
the
process
that
actually
we
resolve
these
these
things
at
the
end
of
the
day,
it's
kind
of
a
democracy,
I,
I,
hope
and
not
autocracy,
where
we
can
go
and
say,
look
five.
Other
registries
already
are
doing
this
either
you
do
it
or
you
are
out
of
the
of
the
picture.
B
G
Of
it,
yeah
I,
don't
I,
don't
think,
there's
anything
wrong
with
your
comment
like
it
makes
sense
that
we
should
build
a
standard,
that's
aligned
with
what
registry
implementations
want
to
do.
If
we
go
too
far,
especially
like
we
push
them
in
a
direction
where
they
are
not
interested
in
going.
B
G
B
B
Having
an
allow
list
is
a
lot
better
than
having
a
deny
list
if
you're
worried
about
someone
pushing
malicious
content
is
very
easy
to
just
change
one
single
character
on
your
malicious
content
and
suddenly
you're
allowed
again,
and
that
that
makes
it
a
very
a
very
bad
situation
from
the
registry
operator's
Viewpoint
that
they
want
to
be
able
to
block
bad
content,
and
so
I
want
to
be
sure
to
hear
from
them
before
we
say,
thou
thou
shall
only
do
deny
list
and
realizing
what
that
cuts
off
from
them
in
the
future.
B
B
I
want
it
before
Christmas,
I
I,
don't
know
how
quickly
we're
going
to
answer
this
specific
question
that
Aaron's
raising
is
a
good
question.
I
think
we
should
we
probably
wanna
answer
it
before
it
is
in
one
of
I
think
we
did
flag
it
as
part
of
the
Milestone.
So
we're
we're
going
to
answer
it
one
way
or
another
before,
but
I
really
want
to
see
this
before
before
Christmas
I.
Don't
want
to
wait
that
long.
G
So
actually,
I
I
think
we
may
be
misreading
the
comment
from
gitlab
I'm,
not
100
sure,
but
I
see
that
they
have
a
open,
pull
request
or
issue
to
support
this
activity
and
they
have
some
interest
in
supporting
refers
and
so
in
these
issues.
G
Just
checking
to
see
if
they're,
actually
Yep
they're
from
someone
on
the
git
lab
team,
so
it
it
may
be
a
misinterpretation
of
like
maybe
they're
talking
about
top
level
media
types
right
like
supporting
your
defense
right
and
I.
Think
we
should
probably
ask
for
some
clarification
here
from
their
team
is
if
they
have
open
issues
that
they
intend
to
support
bombs
and
other
artifacts.
It's
kind
of
difficult
to
comport.
With
this
comment
here.
B
Yeah
because,
because
the
comment,
the
way
I've
always
read,
it
is
that
from
what
they're
doing,
if
it's
a
media
type,
they
don't
recognize
they're
going
to
reject
it
and
they've
they've
done
that
with
the
configmia
type.
I
would
be
surprised
that
they
didn't
do
the
same
thing
with
the
artifact
type.
B
But
then,
back
to
toddy's
comment
there
to
answer
your
do
the
best
I
can
to
try
to
answer
your
question.
I'd
love
to
see
us
come
out
with
something
in
the
next
couple
months
to
get
another
release
candidate
out
that
has
conformance
tests
and
hopefully
a
couple
of
these
things
answered
and
then
give
that
another
month
for
people
to
look
at
it
before
calling
that
GA.
That
would
be
my
Ideal
World.
F
E
I
mean
debating
on
one
zero,
three
zero
for
quite
some
time
and
I
haven't
said
anything
for
quite
some
time
also
I
feel
like.
We
have
clearly
stepped
into
distribution
spec
in
one
zero,
three
zero,
whether
a
registry
accepts
a
type
or
not
should
be
in
the
distribution,
spec,
not
an
event.
Spec,
you
can
store
anything
on
your
file
system.
E
Nobody
tells
you
what
you
can
store
on
your
file
system
or
what
you
can
represent
so
expectation
of
what
the
registry
returns
as
error
should
not
be
in
the
image
pack
is
what
I
feel
like
and
any
of
these
implementations
of
how
the
registry
Implement
should
also
be
moved
to
a
distribution.
Spec
is
what
I
think.
F
E
E
Right
so
so,
from
the
image
spec
standpoint
we've
already
defined
the
artifact
type
and
we've
said
that
it
only
needs
to
conform
to
the
Iana.
What
a
registry
rejects
or
allows
is
up
to
that
implementation.
I
think
I'm,
also
in
line
with
that,
which
is
if
they
want
to
filter
by
some
types
or
look
at
what
the
content
does
it's
up
to
them,
to
implement
it,
for
example,
in
the
government
organization.
Maybe
they
don't
want
specific
algorithms,
they
don't
want
sha1
or
something
like
that.
E
So
it's
up
to
them
to
Define
that
so
I
just
feel
like
there's
nothing
in
the
image
spec.
That
is
explicitly
calling
out
that
artifact
is
not
supported
anymore,
ignoring
the
history
of
the
discussion
that
happened.
So
can
we,
if,
at
all
any
of
these
discussions
for
the
registry
exist,
can
we
focus
on
the
distribution
spec
to
kind
of,
like
all
that
out.
B
E
That's
how
I'm
reading
it
I'm
reading
it
as
you
want
Registries
to
probably
allow
more
yeah
image.
Spec
is,
in
my
opinion,
give
gives
a
good
enough
guidance.
It's
got
the
feels.
It's
got
the
way
to
add
annotations.
We've
defined
precedence
of
artifact
type
over
config
media
type.
Now,
when
you
make
that
HTTP
call
that
failure
is
not
a
part
of
the
image,
spec
is
what
I
read
it
as
so
pushing
that
forward.
E
I
think
Dotty's
question
is
stemming
something
from
what
we
have
discussed,
which
is
even
for
ACR,
we're
kind
of
like
hesitant
on
taking
up
rc3
it's
taking
time,
and
how
do
we?
E
How
do
we
build
confidence
within
that
team
to
say
that
okay,
rc3
is
good
enough
and
let's
move
forward
and
I
think
that's
a
it's
a
tough
discussion,
but
it's
worth
understanding
that
other
operators
are
probably
in
the
same
bucket.
As
should
we
do
this
and
yank
it
out
it's
it's
kind
of
hard
for
online
like
services
that
never
stop
to
be
able
to
break
or
change
behavior
on
customers
underneath.
E
But
if
this
stays
stable
for
quite
some
time,
then
this
just
might
be
the
the
ga
candidate
is
what
we're
seeing.
Yes.
B
E
Discussion
trying
to
see
how
we
can.
A
E
A
Is
hesitation
actually
to
do
the
change,
because
we
don't
know
what
will
be
reverted
after
that,
then
we
cannot
constantly
go
and
Chase
the
spec
and
rc3
rc4
rc5
right.
So
we're
looking
for
some
stability
and
I,
as
you
remember,
like
Jesse
from
AWS,
was
saying
the
same
thing
so
whatever
they
implemented,
they'll,
never
release
it
to
customers
until
it
is
actually
ga.
B
C
B
That
I
I
completely
sympathetic
to
that,
especially
given
that
we
we
have
been
backing
some
of
these
things
off
and
making
changes.
But
to
me
the
big
value
of
the
RC
is
that
someone
actually
does
implement,
even
if
they
don't
release
it
but
implement
it
to.
Let
people
know
that
it's
working
internally,
they're
ready
for
us
whenever
we
do
decide
to
ga.
A
I
I'll
go
back
to
January
like
we
had
everybody
implemented
artifacts
and
everybody
reverted
it
so
I
I
I'm
kind
of
a
little
bit
confused
with
what
is
the
goal
that
and
what
are
we
targeting?
We
had
the
implementations
that
were
working
and
everybody
ripped
it
out.
Even
Docker
Hub
had
implementation
that
was
working
right.
B
A
A
Right,
I
I,
don't
know
whether
it
was
disagreement
or
was
like
some
registry
did
not
have
it
Implement
and
then
that's
why
we
said
in
order
to
support
these
Registries,
we
need
to
go.
We
need
to
go
and
actually
do
all
these
changes
every
spec,
because
now
we're
touching
every
spec
I
guess
for
that.
But
so
whatever
happened
happened,
Brandon
I,
I
think
my
more
question
is
because
I
was
listening
to
you
and
I
was
joking
with
Christmas.
A
But
if
you
say
that
the
next
RC
is
in
a
couple
of
months,
we
are
at
Christmas
right.
So
if
the
next
RC
is
in
three
months
that
September
and
then
three
months
after
that
is
Christmas
right,
I
I
would
rather
have
like.
Okay,
let's
put
a
Target
date
for
the
next
RC
like
end
of
July
end
of
August
at
least
some
date
towards
which
we
can
look
at
and
say
by
this
date.
We
can
say
that
will
happen,
and
is
it
one
RC
or
is
it
two
RCS
with
five
RCS
that
we'll
have?
A
Because
if
we
kind
of
look
from
project
management
point
of
view
right,
we
had
rc1
like
in
in
December,
then
a
couple
months
later,
rc2
rc3.
If
we
say
we
have
five
RCS
I-
can
make
some
estimation
of
when
eventually
this
will
be
stable
and
when
we
should
be
releasing
it
as
to
our
customers
and
when
AWS
will
release
it
yeah.
A
B
When
I
say
a
few
months
or
mid-may
so
June
July
time
frame,
I
would
like
to
see
us
in
July.
Have
all
the
conformance
tests
updated
and
have
an
RC
being
pushed
out
sometime
then,
and
then
the
thing
that
gives
me
hesitation
is
hearing
registry
operators,
say
we'll
think
about
trying
it
out
and
see
if
it
works
after
you've
G8
it
that
that
gives
me
concern,
because
that
means
for
NGA
something
that
people
haven't
tested.
A
999.,
that's
that's
where
we
are,
we
were
actually
we
had
everything
implemented
in
Nazi
one
right
and
we
did
it
without
any
hesitation
at
that
time.
Now
every
engineer
is
like
I,
don't
know,
I,
don't
want
to
write
something
that
actually
I
need
to
reap
out
in
three
months
or
I
need
to
change
in
three
months.
B
A
A
E
Question
more
than
like
talking
to
hey
we're
going
to
do
this,
irrespective
of
any
feedback
but
Target,
like
you
said,
maybe
July
have
a
milestone
and
saying
that
this
is
when
we're
targeting
the
next
RC
and
if
there's
no
feedback
that
is,
requires
an
RC,
then
we'll
G8,
more
Transportation
might
ease
the
the
tension
with
all
the
consumers
right
like
and
people
know
that
okay,
we're
gonna
head
down
this,
then
basically,
when
I
get
asked
like
okay.
What
is
the
next
thing?
That's
gonna
happen.
A
And
maybe
also
as
a
group
to
to
figure
out
because,
like
we
are
trying
to
build
something
perfect,
that
fits
everybody
and
my
experience
is
that
never
happened
right.
What
is
kind
of
our
plan
as
a
as
a
group
and
more
towards
the
maintenance
question?
I'm,
not
a
maintainer
I'm,
just
talking
in
this
in
this
meeting.
But
what
is
like
the
plan
to
resolve
these
situations
in
the
future
right?
Is
it
like
voting?
A
Is
it
like
I,
don't
know
some
other
process
about
that,
because
we
will
always
have
somebody
who
is
not
happy
with
something
or
has
not
implemented
certain
fields
in
certain
Json
and
something
like
this.
That
is
the
reality.
I
I
think
we
talked
about
before
how
we
can
improve
the
working
group
process
to
make
sure
what
comes
out
of
it
is
agreed
upon
by
the
necessary
stakeholders,
because
I
I
think
that
was
a
promise.
Some
people
felt
it
ended
too
soon
and
not
everybody
got
their
vote
in,
whereas
yeah
I
think.
Ideally,
these
registry
operators
are
part
of
the
working
group
process
and
what
comes
out
of
that
is
more
solid
and
we
wouldn't
be
stuck
in
that
situation
like
yeah
I.
Agree
like
the
revert,
doesn't
look
good,
but
there's
also
nothing
else.
B
And
into
that
point,
I
think
the
working
group
we
had
a
I,
don't
know
if
it
was
unanimous
or
nearly
unanimous
within
the
group
of
what
we
released.
But
we
didn't
have
the
right
makeup
within
the
group
of
people
that
had
differing
opinions.
A
I'm
looking
at
the
time
and
we're
getting
at
the
end,
so
I
should
we,
at
least
for
for
my
clarity,
should
I.
Think
of
maybe
next
RC
end
of
July.
B
It's
yeah
the
the
goal
for
me
is
that
we
want
to
get
those
conformance
tests
in
and
so
the
sooner
that
that
can
be
worked
on
I'm
I'm
thinking
of
my
own
availability
between
then
and
now,
and
how
much
time
I
can
spend
doing
that
kind
of
stuff.
But
if
other
people
can
jump
in
and
want
to
start
writing
that
that
can
speed
the
process
up.
A
Okay,
okay,
that
that
helps
remember
so
giving
some
some
idea
and
if
you
are
the
only
one
writing
the
the
conformance
test.
Actually,
we
need
to
consider
that,
actually,
you
have
your
your
own
availability
and
that
may
be
impacting
the
time,
but
at
least
that
gives
some
clarity.
Why
why
we
are
not
making
making
progress
faster,
I.
A
B
Unless
we're
saying,
unless
we're
trying
to
put
a
fixed
60-day
time
period,
instead
of
a
hour
long
between
RC
and
ga,.
B
J
Well
then,
y'all
didn't
get
to
hear
me
say:
God,
damn
it
either.
So
there
you
have
that
the
is
just
explicitly
put
parameters
on
rather
than
leaving,
leaving
it
completely
as
an
open-ended
RFC,
but
that
sales
person
you
got.
You
got
yeah.