►
From YouTube: [OCI-WG] Reference Types - 2022-02-22
B
A
Many
hairs
were
cut
and
even
a
face.
Shave
too
right
yeah,
you
just
did
the
lot.
I
have
not
made
it
that
far.
I
have
a
hairdresser
in
the
family
and
I
only
like
going
to
her
and
she's
been
busy.
So
it's
been
what
much
of
my
wife's
dismay
that
my
hair
looks
like
this,
but
I
will
only
go
back
because
the
person
down
the
street,
if
they
ever
do
my
hair.
A
I
end
up
looking
like
somebody
from
the
beatles,
so
my
wife's
at
the
point
where
she's
like
go,
get
it
done
there
and
just
leave
it
a
little
longer
so
that
my
aunt
can
correct
it.
A
I
never
used
to
mind
you
know
when
I
live.
When
I
lived
in
new
york
city,
there
was
a
sign
out.
It
was
like
two
dollar
haircuts
and
I
went
in
and
got
it
one
day
and
it
was
right
before
a
wedding,
and
I
horribly
regretted
it
now,
I'm
a
little
less
conservative
on
how
much
money
I
spend
on
my
haircuts.
A
All
right,
I
will
again
post
the
link.
Please
add
your
names
to
the
attendee
list,
hello
and
welcome
to
the
working
group
reference
types
in
oci.
I
said
reference
types
working
group
are
kind
of
set
up
backwards.
Today
is
february
22nd,
tuesday
february
22nd
2022.
I
should
have
known
that
from
all
the
palindrome
conversations
I've
seen
around
the
place,
but
I
apparently
missed
it
hello
and
welcome.
Please
add
your
names
to
the
attendee
list.
This
meeting
will
be
recorded
and
posted
to
youtube
afterwards.
A
So
please
be
considerate
to
everybody
around
you
and
choose
your
words
carefully,
we're
all
in
support
of
each
other
here
and
trying
to
help
each
other.
In
this
working
group.
I
see
brandon's
nominated
himself.
Hopefully
that's
self-nominated.
I
can't
actually
see
that,
but
thank
you
brandon
for
notes
really
appreciate
that
we
have
two
agenda
items
at
the
moment.
A
If
there
are
any
subsequent
items
that
people
want
to
raise,
please
edit
the
agenda
and
we'll
try
and
get
through
it
as
we
have
time,
but
for
the
named
agenda
items
we'll
go
through
them
first
and
I
guess
we'll
kick
it
off.
A
I
won't
share
my
screen
because
I
I
assume
somebody
else
will
need
to
do
as
we
go
through
the
next
things.
Okay,
so
first
agenda
item
go
through
bucketed
list
of
use
cases
and
generalize
them.
Nisha
can
lead
with
the
outcome
of
submit
preference
types
working
group
repo.
When
done,
would
you
like
to
take
it
away?
Nisha,
please.
E
Yeah,
thank
you.
Okay.
I
managed
to
go
through
just
one
section
of
that
bucket
bucketed
list,
and
that
was
the
filtering
part
and
thanks
to
I
think
it
was
brandon
who
made
the
bucketed
list,
or
was
it
lucky
thanks
a
lot
for
that
it
was.
It
was
very
easy
for
me
to
go
and
shrink
this
out,
and
I
have
four
questions
that
I
would
like
the
community.
E
I
would
like
some
community
feedback
from
question
one.
Have
we
agreed
that
our
primary
artifact
is
the
container
image?
I
think
we
we
do
because
we
want
to
ensure
backwards
compatibility
but
yeah
I'll,
open
up
the
floor
to
that.
D
E
Okay,
would
that
be
something
that
is
under
user
stories
or
would
that
be
goal
under
the
goals
for
this
working
group
is
to
make
sure
that.
D
E
Oh
okay,
yeah
you're
right,
maybe
touch
is
too
strong.
A
word
will
not
be
impacted.
D
E
D
E
Does
anyone
have
any
additions
objections.
A
B
And
I'm
going
to
say:
if
we're
talking
about
reference
types,
the
thing
that
we
ultimately
go
back
and
reference
is
going
to
be
a
container
image,
but
whether
we're
talking
about
backwards,
compatibility
and
other
things
along
those
lines.
I
think
we've
got
a
lot
of
other
items
in
our
user
stories
that
should
cover
a
bunch
of
this
stuff.
Like
josh
is
saying.
E
Okay,
so
a
follow-up
question
would
be:
do
we
call
these?
E
E
A
E
Yes,
I
and
the
reason
why
I'm
bringing
this
up
is
because
I
would
I
mean
our
objective
here
is
to
generalize
the
user
stories
and
we
have
a
number
of
dupes.
E
I
think
that
talk
about
the
same
things,
but
for
container
images
and
artifacts
separately,
and
sometimes
we
have
user
stories
that
talk
about
them
in
general.
So
I
I
want
to
find
out
whether
we
reference
these
two
things
separately
or
in
general.
E
B
So
my
take
on
it
myself
excuse
me,
is
today:
oci
has
a
separate
little
category
for
artifacts,
even
though
they
kind
of
get
implemented
as
a
container
image
manifest
with
some
other
things
there.
So
as
oci
we've
already
kind
of
broken
everything
other
than
the
container
image
out
a
little
bit,
but
not
quite
so.
B
I
would
just
kind
of
classify
everything
else
right
now,
as
just
an
artifact,
so
whether
it's
nest
bomb
a
signature
attestation,
whatever
we're
putting
into
a
registry,
whatever
we're
throwing
in
there
helm
chart,
put
all
those
things
under
the
artifact
label
for
right
now,
so
we're
not
being
too
picky
and
realize
that
a
container
image
right
now
is
to
some
people.
It
is
an
artifact
to
other
people.
It
is
the
primary
thing
we
store
in
a
registry,
so
could
be
a
subset
could
be
a
parallel
item,
depending
on
who
you
talk
to.
F
Hi,
I
think
I
kind
of
agree
with
what
I'm
saying
there,
which
is
there
is
a
divergence
of
what
container
imagine
an
artifact
is,
but
for
the
use
case,
I
think
talking
about
the
container
image
might
be
an
easy
way
to
define
to
validate
this
signature
on
this
container.
So
do
so
things
things
like
that
or
store
this
reference
type
with
this
container.
The
other
thing
that
I
wanted
to
raise
a
pointer
around
is
the
vernacular
regarding
backward
compatibility.
F
I
don't
think
we
have
agreed
that
everything
that
we
propose
from
this
group
would
be
backward
compatible,
which
means
that
we
won't
break
anything.
For
example,
the
image
spec
did
introduced
a
requirement
for
a
media
type
field
which
might
break
certain
clients,
even
although
it
was
a
minor
bump
right.
So
the
the
goal
from
what
I
understood
was
to
define
how
clients,
maybe
how
backward
com,
how
clients
that
are
not
using
this
new
feature
can
still
make
changes,
deterministically
and
kind
of
implement
the
backward
compatibility
features.
F
E
So
my
takeaway
from
last
week's
meeting
was
that
backwards
compatibility
was
a
primary
goal,
whether
that
had
to
do
with
container
runtimes
or
development
workflow
or
just
in
general
people
using
container
images.
E
I
don't
know
that
that
seemed
to
me
like
a
secondary
thing,
but
it
seems
like
we
have
room
to.
E
We
have
room
to
maneuver
around
that
in
the
sense
that
we
can
specifically
say
that
developer
workflow
will
not
be
affected.
B
Yeah,
for
me,
my
ideal
is
that
any
users
and
servers
so
clients
or
server
on
the
registry
side
if
they
are
following
the
oci
spec,
would
not
be
impacted
by
the
stuff
we're
doing
negatively,
but
it
doesn't
mean
that
somebody
doesn't
incorrectly
implement
something
out
there
and
could
see
an
issue.
We
we've
seen
plenty
of
those
out
in
the
field
already
and
we
just
can't
do
our
best
job.
We
can
to
minimize
that.
E
Okay,
so
it
seems
to
me
that,
as
as
far
as
naming
is
concerned,
someone
I
I
think
at
this
point
when
we
talk
about
container
images,
we
are
specifically
when
we're
specifically
concerned
about
developer
workflow
not
being
impacted,
but
in
general,
all
of
these
things
that
we
store
in
the
registry
can
be
considered
as
objects
or
artifacts
such
as
you
have
your
hand
up.
F
E
F
I
want
to
probably
keep
the
conversation
open
for
possible
changes
that
improve
the
specification
rather
than
saying
that
nothing
will
change
for
all
clients,
so
backward
compatibility
in
my
head
was
actually
a
bucket
which
we
defined
how
clients
would
implement
it.
I
was
not
under
the
impression
that
it
already
made
a
goal
that
no
existing
clients
or
developer
workflows
would
be,
would
not
be
impacted.
F
So
it's
it's
more
like
let's
talk
through
the
scenarios
of
what
the
impact
might
or
might
not
be
in
the
bucket
of
backward
compatibility.
That's
what
the
whole
thing
was
and
definitely,
as
a
registry
operator,
I
don't
think
I
want
to
impact
the
clients
negatively.
But
let's
say,
for
example,
if
they
can
actually
get
reference
types
in
the
data
field
that
would
affect
or
not
affect,
but
it
does
does
tell
clients
how
to
kind
of
reason
it
move
with
it,
and
things
like
that.
F
So
to
me,
it's
been
a
bucket
till
now,
but
I
think
we
should
at
least
have
the
conversation
on
the
scenarios
once
we
identify
the
scenarios
for
backward
combat
or
how
we
might
not
impact
it
in
any
way.
B
E
A
A
A
A
couple
of
observations
is,
I
wanted
to
come
up
with
a
fixed
set
of
personas
because
there
was
a
personas
and
then
refactor
them
all
into
a
set
of
personas,
because
I
did
read
security,
vendor
user
developer,
artifact
producer
security,
admin
tool,
writer
registry
operator,
so
I'm
trying
to
figure
out
how
I
can
synthesize
those
down
into
a
set,
some
of
them
I've
already
aggregated
and
fixed.
So
I
was
going
to
go
and
just
class
in
under
each
bucket,
put
each
sub
persona
and
then
have
them
bucket
and
sub
bucketed
at
each
sub
persona.
E
E
A
A
A
I
have
a
couple
of
other
suggestions.
If
that's
not
is
what
what
I
hear
from
you
saying
nisha.
Is
it
worth
it
to
go
through
and
replace
the
wording
of
a
stored,
object
and
registry
object
to
be
succinctly
container
image,
an
artifact
which
groups
s-bomb
signatures
and
other
things
that
aren't
container
images
and
then
a
reference
which
an
artifact
would
reference.
A
reference
would
be
a
reference
between
an
artifact
and
a
container
image.
A
Would
that
be
useful
to
clean
those
up
or
just
leave
them
in
their
current?
Because
I'm
trying
to
think
of
what's
the
outcome
we're
trying
to
drive
here
with
these
personas?
Are
we
going
to
take
them,
as
is
scrub
them
put
them
in
a
pr
and
then
kind
of
look
over
them,
because
we've
done
a
lot
of
de-duping
right
now?
A
It's
I
really
want
to
get
make
some
movement
on
this,
and
and
so
I'm
looking
for
succinct
next
steps,
so
that
what
I
can
you
know,
work
with
everybody
to
get
them
get
them
done,
because
I
see
some
questions
about.
How
do
we
start
rationalizing
proposals
so
trying
to
just
give
some
ideas
here
to
push
through.
B
Brandon,
if
we're
thinking
about
terminology,
I
would
say,
let's
document
up
top,
that
we
are,
as
our
group
defining
an
artifact
to
be
anything
that
can
be
stored
in
a
registry
along
the
lines
of
signature.
S-Bomb
and
container
image
so
include
container
image
as
a
possible
artifact.
That's
just
one
of
the
many
things
and
a
reference
type
is
anything
that
can
refer
from
one
artifact
to
another
artifact.
Okay.
I
don't
want
to
limit
us
to
just
container
images,
because
there
are
situations
like
signing
an
s
bomb
or
signing
a
help.
Chart
okay,.
E
I
agree
I
was
gonna
propose
that
we
have
a
general
term
called
artifact
and
a
specialized
artifact
called
container
image.
A
So
yeah,
where
do
we
want
to
get
to
do
we
want
to
take
these
and
just
take
them?
As
is,
I
don't
think,
there's
too
much
value
in
having
people's
names
against
specific
use
cases
anymore,
but
I
don't
know,
is
that,
should
we
keep
people's
names
there
and
then,
where
do
we
want
to
actually
agree
on
which
ones
are
we're
going
to
say,
are
valid
use
cases
for
this
working
group
working
group
to
consider?
E
Let's
do
a
pr,
I
think
we
have
enough.
I
can
submit
one
to
start
off
and
then
folks
can
comment
on
it.
A
Okay,
so
I
will
I
will
update,
I
think
the
only
other
thing
is
there's
a
bunch
of
comments
and
the
google
doc
copies
comments
from
things
that
I
copied.
I
don't
know
if
it's
worth
me
just
copying
some
other
doc,
then
putting
them
back
without
comments,
because
I
think
a
lot
of
the
comments
are
probably
from
the
first
pass
and
then.
A
Those
comments
because
I
don't
like
leaving
dangling
dom
comments
on
docs
because
it
looks
like
the
things
are
unanswered
and
unresolved,
so
I'll
I'll.
Do
that
I'll,
get
the
glossary
and
get
it
into
a
state
that
you
can
go
put
it
into
a
pr?
And
then
you
know
maybe
next
week,
do
we
just
go
over
and
say
which,
which
is
in,
which
is
out,
and
at
least
then
move
move
user
stories
out
of
being
considered.
E
Well,
I
I
just
want
to
say
that
actually
the
fact
that
we
have
decided
that
the
artifact
is
generalized
object
and
the
container
image
is
the
specialized
object,
helps
us
shorten
the
user
stories.
So,
for
example,
we
can
now
shorten
all
of
the
container
image
s
sign
signatures.
All
of
that
can
just
be
artifact,
so
we
can
just
have
one
user
story
that
says,
as
a
user,
I
want
to
query
an
artifact
based
on
tag
and
digest
and
that
reduces
the
number
of
user
stories
under
the
filtering
bucket.
A
Okay,
so
I
can,
I
can
take
a
pass
at
getting
the
glossary,
condensing
all
the
different
things
under
the
terminology
that
we've
established
there
just
to
clean
it
all
up,
and
then
we
can
get
it
in
a
pr
and
then
we
can
discuss.
Does
that
sound
like
the
best
next
steps.
A
B
A
Before
you
do
that,
let
me
just
I'm
going
to
copy
the
content
out
and
then
lose
all
the
metadata
and
then
put
it
back
into
the
google
doc.
So
it's
commentless,
because
I
think
if
I
actually
resolve
all
the
comments
now
it's
going
to
resolve
the
parent
comment.
I
don't
know
how
the
commenting
works
anymore,
but
when.
B
A
B
We
can
go
through
and
resolve
a
bunch
of
these
things,
and
that
way,
if
there's
any
important
comments
that
we
don't
want
to
resolve.
Yet
when
you
do
your
copy
back
and
forth
and
lose
that
metadata,
okay,
it
might
be,
might
be
useful
just
to
get
that
back
out
of
it
and
just
be
able
to
say:
oh,
we
don't
need
these,
or
are
you
saying
we're
going
to
somehow.
A
E
A
A
B
A
Yeah
yeah,
I
wasn't
going
to
take
the
unsorted
comments
there,
but
the
problem
is
now.
If
everybody
goes
and
updates
the
unsorted
list,
I
kind
of
said
they're
frozen
in
time,
don't
keep
updating
them
there
because
I'm
not
going
to
replace
them
back
into
the
bucketed
list.
So
I
guess
in
that
case
it
makes
sense
for
people
to
review
and
say
do
they
still
stand
regardless
of
the
list
and
update
them
in
the
bucketed
list.
Sorry,
hopefully,
I'm
not
making
this
too
complicated.
E
We
okay,
shall
we
move
on
then
sounds
yeah
good,
okay,.
E
So
the
next
question
I
have-
I
don't
know
if
we
resolved
this
in
the
last
meeting-
was
whether
a
ui
for
looking
at
artifacts
and
container
images
is
part
of
this
proposal
and
the
reason
I
bring
that
up
is
because
we
have
one
user
story
about
viewing
top
level
container
images
in
the
registry
through
tags,
but
only
see
the
references
as
a
selected
detail.
E
And
steve
is
not
here,
so
I
wonder
if
that's
something
that
we
should
consider
brandon.
B
E
Okay,
in
that
case,
I
think
just
the
general
querying
user
stories
that
we
have
should
be
enough
or
are
we
missing
anything.
F
E
Okay
next
question
is:
there
is
a
user
story
about
reducing
the
number
of
tags
that
reference
related
artifacts
is
reducing
tag,
clutter,
a
content,
management
issue
or
a
querying
issue.
E
It's
bucketed
under
query
filtering.
I
think
this
is
brandon's
user
story.
E
Nice
to
have
I
mean,
I
guess
I'm
wondering,
is
that
something
is
that's
a
user
story,
but
it
seems
more
like
you
know
it,
it's
something
a
user
would
not
like
would
not
want
to
deal
with,
or
would
you
know
prefer
if
there
was
like
a
straightforward
way
to
handle.
B
It's
a
user
story
where,
if
we
implement
reference
types
and
give
these
to
the
users,
it's
one
of
the
things
they'll
come
back
to
me
and
complain
about,
and
so
I'm
trying
to
avoid
people
coming
back
to
me
and
complaining.
But
it's
also
one
of
those
where
it
comes
out.
When
you
say
hey,
that's
the
way
it
works.
There's
no
way
around
that,
then
sorry
we
did
the
best.
We
could.
E
B
D
Yeah,
I
guess
maybe
as
we're
going
through
this-
I
you
may
have
already
said
it.
I
just
I
could
not.
I
did
a
controller
for
tags
and
didn't
know
what
talking
about.
E
I'm
taking
a
look
at
the
original
thing,
real,
quick,
I'm
wondering
now
was
that
a
was
that
a
thing
I
missed.
Let's
see.
E
B
Be
it's
because
this
can
be
solved
in
different
ways.
You
can
solve
this
either
by
not
creating
tags
and
so
we're
creating
something
else
that
refers
and
it's
just
a
digest,
and
so
there's
never
anything
in
the
tags.
Database
get
cluttered!
You
can
solve
this
by
filter
on
the
tag
listing
you
can
solve
it
on
the
client
side
that
filters
this
out
so
because
it
can
be
solved
in
several
different
places,
it's
hard
to
say
which
bucket
it
should
be
in
because
different
people
solve
it
different
ways.
B
F
F
Can
you
be
careful
of
not
wording
it
like
reduce
tag
clutter?
That
means
we
have
assumed
that
tags
are
cluttered
in
some
way,
but
we
haven't
chosen
an
implementation.
So
it's
it's
basically
to
make
sure
that
we
ensure
that,
however,
we
do
tack
filtering
or
how
we
do.
This
is
not
going
to
create
clutter
or
something
like
that,
because
the
other
one
kind
of
implies
that
we've
chosen
to
use
tags
in
some
way
right,
fair
enough.
E
E
Okay,
such
I
said,
that's,
that's
good
organizing
means
content
management
to
me,
but
it
could
be
like
other
ways
if
a
user
would
like
to
you
know,
interact
with
the
registry
in
an
organized
and
in
an
organized
way
or
user-friendly
way.
I
guess
clutter
would
go
against
that.
E
Okay,
all
right,
so
that's
all
the
questions
I
have
for
the
filtering
part.
Shall
we
move
on
to
backwards
compatibility?
We
are.
We
are
making
good
progress.
I
don't
know.
Do
folks
want
to
move
on
or
do
folks
want
to
call
it
a
day
lucky.
E
Yeah,
I'm
sorry,
that's
that's
up
to
folks.
So
do
the
second
I
would.
I
would
move
on
to
the
second
item
just
for
discussion,
because
it's
a
top-level
thing
that
maybe
resolving
it
now
would
help
us
move
forward
with
our
conversations.
So
the
question
is:
when
we
look
at
propos,
when
we
look
at
the
proposals,
do
we
look
at
them?
E
Do
we
take
a
particular
use
case
and
see
if
the
proposals
solve
for
that
use
case,
or
do
we
take
up
the
proposal
and
see
if
it's
all
what
use
cases
it
solves
for
and
what
use
cases
it
doesn't
solve
for
lucky?
Oh
lucky's
got
to
send
out
josh.
D
Sorry
so
I
don't
want
to
go
back
to
the
last
one,
but
I
just
want
to
make
sure
are
we?
Is
this
list
or
like
as
we're
going
through,
that
misha
making
some
changes
like
artifact
versus
image?
Are
we
gonna
get
this
back
into
the
repo?
Was
my
one
question
like?
What's,
I
guess
like
what
is
our?
E
So
I
I
can
submit
an
initial
pr,
and
I
guess
this
is
done
when
that
pr
gets
merged,
that's
the
short
form
of
it,
but
there's
also
the
second
question
which
is:
do
I
do
I
well,
I
guess
not
so
does
that
mean?
Do
you
want
to
continue
forward
and
look
at
look
at
the
backwards
compatibility
and
the
no
artifacts
came
in
all
of
that
before
we
move
on
to
the
next
one
before
looking
at
proposals.
D
No,
let's
go
on
I'm
just
right,
so
we
have
23
minutes.
I
think,
there's
more
than
enough
to
talk
about
once
we
open
up
the
can
of
worms
with
proposals.
I
think
let's
say
we
run
out
of
time.
Are
we
just
gonna
like
open
up
this
list
next
week
and
like
look
at
it
forever?
I
know
lockheed
was
saying
something
about
getting
it
on
my
pr,
I
just.
D
Are
we
are,
are
we
planning
to
like
get
a
list.
A
E
A
That
we're
saying
is
not
going
to
be
covered
by
this
working
group.
Agree
on
that,
get
it
into
the
doc
and
I'd
like
to
like
start
that
asap.
Let's
get
that
up.
Hopefully
I
can
dedicate
some
time
today
to
scrub
it
get
at
the
pr,
but
then
async
comments
on
the
thing
get
that
merged,
as
as
nisha
was
saying,
and
then
you
know
the
second
part
of
nisha's
question,
I
was
thinking
with
that
merged.
It
would
be
interesting
to
with
an
accepted
set
of
use.
Cases
do
a
matrix
of
here's.
A
E
So
okay
brandon
has
a
signed
up
and
then
I
have
a
proposal.
I
mean
I'm
making
a
motion
to
move
that
topic
of
looking
at
the
making
a
proposal
matrix
till
after
we
finish
merging
the
use
cases.
B
Yeah
doing
the
matrix
later
separate
pr
makes
sense
to
me
when
we
go
through
making
the
matrix.
I
think
we're
going
to
spend
some
time
actually
going
over
the
proposals.
I
don't
think
we've
really
done
that
yet
and
so
spend
a
little
bit
of
time
running
over
what
the
proposals
are
make
sure
everybody
understands
each
one
of
the
proposals
and
how
it's
how
it's
implemented,
not
necessarily
whether
we
like
it
or
not.
I
think
everybody's
going
to
have
their
own
favorites.
B
B
You
know
there
there
are
challenges,
you
make
some
choices
when
you
go
through
that
and
then
potentially
this
can't
do
it
directly,
but
we
can
push
that
off
to
a
user
to
implement
themselves
and
maybe
there's
some
other
categories
in
there,
but
just
kind
of
think
through
those
as
you're
thinking
at
this,
that
there
might
be
more
than
just
yes,
no.
A
E
Josh,
you
have
your
hand
up,
no
you're
done.
Okay,
all
right,
and
because
we
answered
that
question
about
a
specialized
artifact
as
container
images,
I
think
backwards.
Compatibility
user
stories
are
pretty
succinct,
so
I'm
gonna
like
quickly
go
on
to
artifact
schema.
E
Blobs
and
layers-
I
did
not
understand
if
the
if
this
group
had
come
to
a
consensus
consensus
on
whether.
E
Considering
that
you
know,
we've
now
said
an
artifact
is
a
genetic
term
for
things
stored
in
a
registry,
and
the
container
image
is
a
specialized
artifact.
So,
with
that
said,
are
blobs
something
we
care
about.
E
So
I
will
put
forward
that
the
blobs
I
mean
there
are
file
systems
out
there
that
do
not
use
layers
and
we
still
call
it
a
blob.
E
B
So
I'll
clarify
my
overly
short
answer
there.
Some
proposals
are
looking
at
making
a
new
media
type
for
how
they
capture
artifacts
and
if
you
design
a
new
media
type
with
a
new
layout
and
schema
in
there
deciding
how
you
structure
that
becomes
very
important.
So
I
think
that's
where
they're
trying
to
capture
how
we
structure
it
needs
to
include
an
array
of
blobs
and
things
like
that.
So
I
think
they
were
going
two
or
three
steps
down
this
path.
B
E
B
Yeah,
I
can,
I
can
agree
with
you
that
is
getting
a
little
bit
into
the
weeds
of
implementation
rather
than
user
side.
I
just
wasn't
going
to
fight
too
hard
on
the
user
stories,
because
I
figure
our
fights
are
going
to
come
later
on
this
project.
So
after
you
let
everybody
throw
whatever
their
own
individual
user
stories
were
on
there
and
if
they
make
sense
to
only
have
people,
then
that's
the
only
problem
to
have
people
have.
E
So
steve
is
not
on
the
call,
and
I
would
I
would
reach
out
to
him
to
ask
his
opinion
about
this.
Maybe
in
another
meeting
or
just
on
the
slack,
does
that
sound,
fair.
E
A
A
E
Okay,
so
moving
on,
there
is
one
question
about
I
I
suppose
I
could
shrink
that
down
to
round
tripping.
So
the
specific
one
is,
oh
goodness
I
I
lost
it.
E
E
Brandon,
would
you
like
to
clarify
that,
for
me.
B
Yeah
the
clarification
on
that
one
is
think
through
a
scenario
where
you've
got
a
security
system
out
there
that
is
doing
daily
scans
on
all
of
your
artifacts
out
there,
all
your
container
images
and
you
expire
them
after
a
day,
but
you
don't.
You
haven't
implemented
the
garbage
collection
process
yet
so
after
a
month,
you've
got
30
of
these
30
these
scans
sitting
out
there.
I
don't
want
to
have
to
have
someone
go
through
and
pull
all
30
of
those
individual
scans
to
find
the
one
signature
that
hadn't
expired.
B
Yet,
especially,
you
know
you
keep
going
longer
and
longer
it's
going
to
go
a
year.
Something
like
that.
So
I'm
just
looking
for
a
way
that
users,
if
they
need
to,
if
they've,
pushed
a
whole
lot
of
these
signatures
up
into
the
registry,
that
they
can
quickly
find
the
one
they're
looking
for
without
pulling
each
one
of
them
individually.
E
Wouldn't
that
fall
under
content
management,
though,
because
it
seems
to
be
connected
to
like
how
what's
what's
the
retention
like
folks
wanting
to
define
the
retention
policy
on
certain
artifacts.
B
Possibly
this
is
another
one
of
those
where,
depending
on
how
you
implement
it,
it
can
be
grouped
in
a
different
bucket.
You
know
if
somebody
says
we're
just
going
to
implement
as
a
filter
and
you
can
filter
those
specific
things
back.
You
want
from
your
query.
That's
one
way.
E
Of
doing
it,
and
then
you
can,
you
know,
delete
based
on
some
time
stamp
yeah.
So
it's
it's
about
like
who,
whether
it's
a
registry
that
you
know
does
this
or
whether
it's
the
client
that
does
it,
but
I
still
think
that
that
falls
under
content
management,
because
I'm
thinking
that,
if
you
want
someone
to
be
able
to
do
this,
then
the
ability
to
be
able
to.
E
E
Yeah,
I'm
not
sure
now,
whether
now
that
I
said
that
sentence,
I'm
not
sure
whether
that's
that's
a
concern.
So
suppose
you
had
suppose
you
had
an
like
a
object
that
is
metadata
about,
like
specifically
timestamp
metadata
about
what
scans
exist
or.
E
B
Yeah,
it
comes
down
to
how
it's
implemented,
and
so,
if
you
implement
it
a
different
way,
you
might
only
have
two
references
to
look
up
because
you've
automatically
cleared
out
all
the
other
ones.
It's
it
it's
one
of
those.
It
just
depends
on
how
you
write,
so
it
gets
factored
into
a
different
bucket,
depending
on
who's
implementing
solution.
D
E
Yeah,
I
think
at
least
for
now
it
seems
that
there's
a
good,
I
mean,
there's
a
there's
solid
ground
to
be
able
to
organize
all
of
these
into
genetic
user
stories
and
be
able
to.
E
You
know,
submit
changes
to
the
initial
pr
or
like
make
comments
on
the
initial
pr
and
move
forward,
because
I
I
look,
I'm
looking
at
the
list
right
now
and
I
do
not
have
really
any
other
questions.
Like
any
other
clarifying
questions,
it
seems
reasonably
straightforward
once
you
have
the
the
glossary
of
terms
and
what
we,
what
we
are
considering.
E
One
issue
that
I
have
is
yeah
the
the
last
issue
was
about
the
blobs
and
the
layers.
Oh
pooh.
I
missed
one
one
final
question,
but
I'll,
but
lucky
has
a
sound
up,
so
go
ahead.
Lucky.
A
A
A
A
Is
that
actually
a
use
case?
I
don't
know
so.
I've
just
went
thinking
about
this.
Should
artifact
schemer
exist,
or
should
everything
get
filtered
brought
up
a
level
and
put
somewhere
else
in
one
of
the
other
three
buckets?
And
this,
in
which
case
this
one
isn't
really
a
valid
use
case?
It's
it's
more
us
posturing
on
a
an
api
design
through
things
that
aren't
really
use
cases
like
you
know,
air
quotes.
That's
just
should
this.
Should
this
category
exist?
A
Should
it
be
moved
out
because
if
you
go
and
fix
up
steve's
to
what
the
actual
use
case
is
the
other
three
I
think
could
probably
go
into
you
know,
as
a
user
take
the
last
one
josh's
one,
I
want
to
store
images
in
one
registry
and
signatures.
That's
kind
of
content
management.
If
I
squint
you
know,
yeah.
A
It's
something
has
to
land
in
the
schema
of
course,
but
it's
really
like
do.
We
need
to
say
that
there
is
a
lot
of
stuff
that
needs
to
land
in
the
scheme
here
by
virtue
of
the
other
buckets
right
backwards,
compat
and
other
things.
Is
this
actually
a
real
bucket,
or
is
it
a
fake
bucket
for
stuff?
We
didn't
want
to
put
in
any
others,
because
you
know
brandon's,
for
example,
has
it
could
be
in
filtering
too,
and
you
said
it
could
be
in
content
management?
A
So
that's
just
you
know
one
thing:
should
the
artifact
scheme
of
bucket
really
actually
exist
in
a
set
of
use
cases,
because
you
could
squint
and
say
that
everything
should
be
in
the
artifact
bucket
and
that
is
artifact
schema
bucket
as
well,
by
virtue
of
the
fact
that
yeah
you're
going
to
need
to
put
something
in
an
api
to
facilitate
this.
B
E
Okay,
can
we
move
that
discussion
to
next
week,
we'll
keep
it
in
the
let's.
A
Just
put
it
in
the
pr
and
then
we'll
just
start
to
talk
it
out
there,
because
I
feel
like
capture
of
these
notes
over
time
and
then
working
towards
the
goal
of
getting
that
merged
is
probably
we've
done
a
lot
of
finessing
in
the
doc.
I
feel
like
it's
time
to
start
working
towards
resolution.
That's
just
my
take.
E
Yeah,
so
I
have
one
last
question
one,
and
this
is
actually
regarding
my
own
user
story
that
I
put
in
there,
which
is
as
a
user.
I
want
to
fetch
the
most
updated.
E
E
Well,
like
I
don't
have
assurances,
I
don't
know
whether
what
I'm
pulling
is
most
updated,
even
if
it
is,
if
it
even
is
updated
or
not.
E
I'm
looking
at
marina
here
and
as
I
as
I've
read,
the
tough
specification
I
feel
like
there
is
one
thing
missing
in
this
whole
is
talk
about
registry,
which
is
the
concept
of
streams
or
series
or
you
know,
feeds.
As
I
mean.
If,
if
we
want
the
registry
to
be
part
of
an
update
system,
then
it
means
that
we
also
need
to
have
like
this
concept
of
a
feed
that
people
subscribe
to.
E
C
Yeah,
I
guess
just
for
context.
The
way
I
thought
about
the
use
of
tough
in
kind
of
this
whole
system
is
that
you
could
use
the
references
to
basically
to
include
tough
metadata
on
a
registry
which
isn't
which
can
then
provide
you
things
like
the
timeliness
properties
that,
without
having
to
be
natively
supported
by
the
registry
right.
C
The
registry
doesn't
need
to
know
what
these
tough
metadata
pieces
are
doing,
but
by
existing
on
the
registry
and
referencing
artifacts
that
are
on
the
registry,
you
can
then
use
them
to
to
get
that
that
information,
which
is
just
kind
of
how
I've
been
thinking
about
it.
I
don't
know
how
that
relates
exactly
to
the
user
story,
but
yeah.
C
E
If
I
wanted
to
find
well
so
I
mean,
if
I
wanted,
to
find
the
most
updated,
artifact
or
product
or
like
something
that
I'm
subscribing
to.
If
I'm
using
the
tough
terms,
that
would
mean
that
I
would
be
like
my
client
will
be
looking
for
specifically
timestamp
metadata,
to
find
whether
it's,
whether
it's
the
most
updated
thing
or
not,
is
is
that
the
yeah
is
that
what
you're
thinking
about
okay.
C
So
yeah,
so
registries
are
a
little
bit
different
than
file
systems
in
how
you'd
find,
especially
like
the
versioned,
tough
metadata
files.
I
don't
know
if
this
is
going
too
far
in
the
weeds
for
folks
who
aren't
as
familiar
with
tough
but
but
basically
you
could
use
the
references
like
you
could
reference
from
timestamp
back
to
say,
root
metadata.
C
You
could
update
that
reference
without
having
to
actually
mutate
the
you
know
the
artifact
that
you're
updating,
which
is
the
timestamp,
so
that
you
can
basically
upload
a
new
timestamp
which
then
points
to
the
root,
and
you
just
find
that
reference
and
the
timestamp
in
it
is
what
gives
you
the
timeliness
property
and
make
sure
it's
the
most
recent
one
as
well
as
the
reference.
I
don't
know.
If
I
explain
that.
Well,
sorry,
brandon,
I
know
you
had
your
hand
up.
B
E
E
You
know,
tombstone
updates
that
didn't
work
and
move
on
and
try
the
next
update
those
kind
of
things
we're
just
a
little
over.
E
Oh
yeah,
okay,
my
suggestion
would
be
to
maybe
move
this
to
just
keep
the
simplified
one.
The
simplified
user
story
that
I
want
the
most
updated
artifact
and
I
want
to
bisect
artifacts.
B
Yeah
for
the
for
the
bisecting
case,
something
to
think
about
and
not
to
solve
it
now
because
real
time,
but
whether
that
can
be
handled
at
a
layer
above
us,
and
so
if
you've
got
a
build
system,
that's
pushing
out,
builds
every
day,
they're
going
to
have
individual
tags
for
each
one
of
those
builds,
and
so
there
might
be
other
ways
to
solve
that
that
don't
need
to
go
all
the
way
down
into
the
reference
system.
To
look
at
that,
if
it's
possible,
that
saves
us
some
headache.
E
Exactly
exactly
exactly
my
point,
so
maybe
we
have
actually,
you
know
identified
what
the
user
story
is
that
we're
trying
to
resolve,
and
with
that
I
think
we
can.
We
can
call
this.
We
can
call
it
a
day
and
move
on
to
submitting
appear
yeah.