►
From YouTube: OCI Weekly Discussion - 2023-04-06
B
C
C
A
Yeah,
that
kind
of
came
out
the
photos.
The
original
kind
of
discussion
that
we
wanted
to
have
was
more
about
searching
filtering.
Surprisingly.
To
me,
this
grew
into
something
bigger
right
now,
so
I'm
not
completely
sure
about
the
the
scope,
because
it
was
driven
by
its
cost
and
the
sorry
I
think
Scott
and
who
was
the
guy
who
submitted
it
to
the
work
to
the
attack
application
delivery.
A
A
C
A
I
am
not
sure
that
I
can
provide
the
latest
kind
of
status
and
and
scope
for
that,
so
it's
called
put
it
I
would
say,
he's
the
right
person
to
talk
about
that
as
I
said
so,
I
have
not
paid
too
much
attention.
I
was
kind
of
on
the
original
discussion
when
we
were
discussing
the
the
search
and
filtering
and
that's
started
from
there.
That's
what
we
wanted
to
kind
of
work
on
in
auras,
but
we
kind
of
couldn't
get
agreement
whether
we
should
create
a
working
group
under
auras
and
Scott.
C
C
So
yeah
this
one's
been
open
for
a
little
bit.
I
know
it's
kind
of
been
the
blocker
for
us
to
get
things
moved
to
the
next
step.
Oh
I,
see
Scott
just
joined,
should
I
go
ahead
and
turn
it
over
we're
going
to
continue
on
some
other
items.
While
we
wait
for
you
to
show
up
Scott,
but
since
you're
here,
I
think
you're,
the
man
of
the
hour.
D
D
D
F
D
D
D
D
The
widest
used,
oci
artifacts
out
there
right
now,
although
you
know
I
think
we,
maybe
we
all
hope-
or
it
seems
very
likely
that
that
will
continue
only
continue
to
increase
across
projects,
but
in
any
case
the
the
very
first
work
product
right
now
is
to
improve
being
able
to
find
the
like,
basically
discover
and
search
those
artifacts
the,
and
so
the
initial
thought
was
oh,
my
gosh.
Should
we
update?
E
B
B
There
is
a
possible
confusion,
even
even
if
the
plane
goes
exactly
according
to
plan,
there's
possible
confusion
among
consumers
of
the
plan
to
conflate
the
things
the
only
like
to
conflate
cncf
things
in
oci
thing,
the
only
thing
we
have
to
safeguard
against
that
is
our
own
discipline
and
our
own,
our
own,
like
vocabulary,
discipline
and
calling
people
out
when
they
say
oci,
artifacts
or
cncf
artifacts
and
saying
that's
not
a
thing.
What
you
mean
is
this
other
thing
so
I
just
want
to
I'm.
B
B
E
D
D
G
C
The
value
that
I
thought
of
when
we
were
originally
creating
extensions
was
that
it
gave
a
really
good
place
for
registry
operators,
whether
it's
ACR,
Hub
Harbor
whoever's
got
their
own
registry
to
say,
here's
an
extension,
we're
making
for
our
registry
and
it
might
interact
with
our
tooling.
It
might
be
a
Docker
Hub
class
that
talks
specifically
that
API.
E
B
Another
sort
of
a
center
of
gravity
around
it
less
about
I
mean
certainly
if
it
was
a
Docker
Hub
only
functionality
that
you
needed
a
doctor,
a
Docker
account
to
use
like
Aaron's
API
is
not
going
to
adopt
that.
So
that
won't
happen.
But
if
it
is
a
general
purpose
enough,
then
it
could
gain
a
center
of
gravity
and
people
would
move
around
it.
B
I
think
the
reason
I
would
not
want
that
in
oci.
Is
that
it's
a
bit
two
reasons?
One
is
it's
a
bit
easier
to
say:
we
don't
support
that,
like
that's,
not
part
of
oci
oci
specifications
and
conformances
the
bare
minimum
platform
of
things
that
you
know
all
Registries
should
support,
but
this
is
optional
additional
functionality
that
your
client
might
not
support.
One
nice
thing
about
extensions:
is
it's
really
easy
for
a
client
to
detect?
We
we
made
it.
B
G
G
You
know
and
work
on
iterate
on
a
proposal,
and
we
can
have
different
versions
of
that
proposal
and
not
have
oci,
never
necessarily
have
to
standardize
something
and
then
for
us
to
then
regret,
maybe
what
we
standardized
and
when
there's
actually
that
sort
of
center
of
gravity
when
enough
Registries
have
decided.
This
is
actually
a
really
sort
of
good
functionality,
or
this
is
what
we
might
consider
table
Stakes
or
something
like
that.
G
Then
maybe
it
would
also
make
sense
for
oci
to
also
say
this
is
we're
going
to
sort
of
freeze
this
extension
or
we're
going
to
adopt
this
extension
or
something
I
think
it's
a
good
problem
to
think
about
in
the
future
is
building
features
that
so
many
people
want
to
use
that
people
are.
You
know,
beating
down
the
door
of
oci
saying
we
want
this
to
be
part
of
oci
2.x
or
something
that
would
be
indicative
of
a
huge
amount
of
value
being
produced,
but
I
think
that's
pretty
far
out
as
well.
H
Trying
to
understand
a
couple
of
the
claims,
I
read
in
your
documentation
for
the
goals
and
the
the
reason
for
putting
the
group
together,
I
notice
in
there.
It
says
one
thing
that
sort
of
surprised
me
that
the
oci
top
was
had
denounced,
creating
any
support
for
apis
and
such
around
artifacts
for
images
well
find
that
surprising
and
then
the
goals
here
seem
to
list
out,
like
you
know,
apis
for
doing,
search
for
artifacts
things
like
that.
H
There
are
already
in
the
distribution,
API
spec
pull
request,
so
I
think
some
of
the
maybe
there
wasn't
enough
conversation
with
the
oci
top
or
the
oci.
You
know
maintainers.
Maybe
we
need
to
talk
some
more.
Maybe
we
need
to
put
some
more
maintainers
in
in
the
tag
a
little
I'm,
a
little
surprised
that
just
just
saying
and
re
in
reading
your
goals
and
what
you're
trying
to
put
together,
we
put
an
extension
API
there,
but
it
wasn't
to
replace
the
API.
H
The
goal
of
oci
was
to
create
a
standard
for
doing
this
type
stuff
right,
common
images.
The
images
grew
now
into
artifacts
I
think
we
we
haven't
issued
if
you
will
artifacts
so
maybe
maybe
there
was
a
little
bit
of
a
disconnect,
I
don't
know,
but
we,
but
we
need
more
people
to
work
together.
It's
open
source,
let's,
let's
work
together,
let's
figure
out,
we
do
work
groups,
you
guys
have
tag,
work
groups.
Maybe
we
need
to
do
a
common
or
combine
the
effort
right?
D
H
D
D
E
D
D
We
support
this,
but
but
you
know
this
really
is
not
what
we
want
our
Focus
to
be
and
the
people
that
are
actually
using
that
are
in
the
application
community
and-
and
it
seemed
like
the
theorus
project,
with
belonged
within
cncf
for
various
reasons,
and
that
was
the
place
where
a
lot
of
that
work
should
be
done.
So
I
think
that's
one
of
the
other
reasons
we
thought.
D
H
I
think
I
think
it's
the
everybody
or
not
everybody.
But
yes,
there
were
quite
a
few
groups
that
were
circling
around
the
horn
for
who
was
going
to
be
the
first
to
come
up
with
the
API.
You
know
that
everybody
was
going
to
implement
as
a
standard.
That's
generally
how
this
happens
until
the
standard
happens
right.
A
H
Of
your
a
little
bit
of
experience
on
the
RSI
we
can.
We
can
ask
some
other
people
to
help
and
try
to
understand
that
I,
just
don't
want
to
to
read
something
that
was
from
not
not
exactly
from
Chris
Hanks,
for
example,
who's
running
CNC,
oh
see,
I'm.
Sorry,
the
you
know
saying
something
that's
happening
over
here
absolutely.
H
H
We
don't
understand
why,
of
course,
I
mean
we.
We
don't
have
support
for
the
extensions
yet
in
the
client
tools.
So
if
you
go
down
that
route
you'd,
be
you
know,
shoehorned
into
Registries
that
are
supporting
an
extension
that
hasn't
been
released
in
an
actual
official
official
specification.
Yet
it's
only
been
in
a
World's
branch,
so
I'm
probably
talking
too
much.
D
H
D
So
can
I
ask
the
question
of
whether
it's
because
I
I
heard
some
really
good
proposals
and
like
discussed
and
and
in
the
chat
about
the
idea
of
extensions
being
a
testing
ground
for
seeing
if
there's
interest
in
adopting
opting
into
certain
functionality
before
it
moves
Upstream
into
you
know
into
oci.
Officially.
Is
that
something
that
you
I'm
kind
of
hearing,
something
from
you
and
I'm,
not
sure
if
I'm
interpreting
right,
but
is
that
something.
C
I'll
jump
in
right
just
because
I
have
my
hand
up,
but
also
because
since
I
originally
threw
the
chaos
grenade
out
there
saying
that
it
was
more
of
a
red
tree
specific
thing:
I'll
I'll
walk
that
one
back.
Understandably,
everybody's
got
very
valid
points
in
there.
That's
not
registry.
Specific
I
was
throwing
out
more
of
like
a
use
case,
for
where
extensions
made
a
lot
of
sense.
We
also
use
them
as
a
testing
ground.
We
implement
the
refers
API.
E
F
When
you
come
back
to
oci
and
say
like
hey,
can
we
actually
make
this
part
of
oci
two
so
that
we
all
implement
it
the
same
way?
But
that's
my
only
warning
is
like
if
we
want
this
ubiquitous,
everyone
needs
to
somehow
get
involved
and,
like
some
people
don't
participate
in
these
meetings.
Some
people
might
read
those
CM
mailing
list
or
I
subscribe
to
this
yeah
repos.
So
like
it's
a
lot.
E
I
All
right,
yeah
from
someone
who's
been
on,
you
know
doing
a
lot
of
the
work
in
and
he's
pushing
on
the
tag,
app
delivery
side
of
things.
We
understand
that
if
it
ever
comes
back
to
oci,
you're,
never
gonna
get
accepted,
saying
oh,
go
ahead
and
take
our
take
our
food
eat
it
and
enjoy
it,
it's
more
of
a
maybe
like
what
we
have
you
might
want
to
catch
up
on
it
instead.
I
F
Yeah
it
I
mean
it
would
be
great
for
the
like
consumer
side
to
know
what
we
need
or
what
they
need,
because
you
know
we're
bringing
together
like
three
different
groups:
there's
like
the
consumers
and
then
registry
operators
and
then
like
standards,
body
people,
so
yeah
I
would
say
your
responsibility
would
be.
You
know,
here's
what
we
need
and
then
we
take
this
to
register
people
saying
what
can
you
do
and
then
we
find
some
middle
ground
and
then
we
standardize
on
like
the
lowest
common
denominator.
That
gets
everybody
not
happy,
but.
C
C
There
are
three
different
places:
we're
looking
at
doing
that
now
already
today,
and
one
of
you
have
an
individual
image,
you
say:
I
want
to
search
for
all
the
artifacts
point
to
that
image.
We've
got
the
refers
API
that
was,
we've
been
working
on
so
hard
if
you're
looking
at.
What's
the
content
inside
of
a
specific
repo,
the
tag
listing,
API
needs,
work,
I
think
there's
a
general
desire
within
the
CI
itself
to
extend
that
tag.
Listing
API
to
say.
Give
us
back.
C
Four
descriptors
give
us
back
untag
manifest,
give
us
more
detail
there.
What's
in
a
repository
and
to
have
some
API
for
that,
and
then
beyond
that
you've
got
the
catalog
API,
which
has
notoriously
been
a
challenge
and
I
feel
like
you're,
getting
ready
to
walk
into
that
landline
I
feel
like
you're,
saying
what
is
outside
of
just
one
repo,
a
whole
bunch
of
repos,
and
it's
something
that
we
know
that
we
want
to
search
on.
C
We
want
to
add
some
kind
of
interface
and
do
some
kind
of
listing
or
search
or
query
across
multiple
repos
But
realize
that
when
we
walk
into
that
landmine,
we
have
pretty
much.
Everything
in
Registries
today
has
auth
to
find
and
scoped
specifically
to
individual
repositories,
and
so
you
quickly
get
into
negotiating
with
a
lot
of
people,
have
implemented
auth
differently
but
have
all
implemented
specifically
in
one
scenario.
D
Yeah
from
from
a
helmy's
case
from
end
users,
the
functionality
from
basically
there
are
generally
many
packages
within
a
Helm
repository,
that's
kind
of
the
the
language
of
it
right
and
then,
but
within
oci.
A
repository
is
specific
to
one
package
and
all
the
versions
of
that
one
package.
So
the
language
is
a
little
bit
confusing
I
think
for
some
people.
If
any
of
you
aren't
that
familiar
with
with
like
with
the
helm
side
of
things
for
kubernetes,
maybe
everyone
is
but
I
just
wanted
to
make
that
clear.
D
It's
just
the
community
need
for.
It
is
so
enormous
that
I
don't
want
us
I.
Don't
want
to
claim
that
it's
single-handedly
made
the
case
for
artifacts
in
oci,
but
it
sort
of
sounds
like
it
was
top
of
list,
probably
by
a
lot
to
start.
So
the
the
the
the
thing
that
you
can
do
with
Helm
right
now,
so
when
you're
installing
applications
like
kubernetes
is
you
can
search
that
catalog
or
that
registry
for
the
different
applications?
And
then
you
can
go
into
each
of
those
applications
or
each
of
those
packages?
D
C
Natural
thing,
let
me
let
me
give
you
a
little
bit
of
the
history.
Yeah
I,
don't
know
at
all.
People
probably
correct
me
and
know
a
lot
better
than
I
do,
but
the
catalog
API
was
originally
in
the
distribution,
spec
and
Docker.
It
had
on
their
side
but
instantly
when
they
make
Docker
Hub.
They
don't
enable
that
and
it's
because
when
you
think
about
the
catalog
listing
of
all
the
repositories
on
something
like
Docker
hub,
there
are
a
a
whole
lot
of
repos
out
there.
C
So
that'll
be
a
very
long
listing
that
would
probably
never
end
but
B.
The
other
really
important
thing
is
that
it
has
a
lot
of
private
repos
everywhere,
a
lot
of
individual
users
namespaces.
They
don't
have
public
images,
and
so
you
quickly
get
into
how
do
I
handle
the
auth
request
that
can
query
and
say
to
the
auth
server.
Give
me
access
to
query
all
these
things
it.
C
It
becomes
a
very
complicated
problem
for
people
who
are
writing
the
authentication
servers,
and
so
they
just
quickly
threw
up
their
hands
and
said
unless
you're,
some
kind
of
registry
administrator.
You
don't
have
access
to
this
API
or
something
along
those
lines
so
taking
their
issues
they
face
there
and
then
trying
to
model
that
over
you've
already
said.
You
know
you
get
that
big
long
index
and
it
just
becomes
too
huge.
We
got
the
same
problem
historically
on
oci,
and
so
they
just
immediately
threw
up
their
hands
and
just
turn
it
off.
C
A
Yeah
actually
I
agree
with
you
on
the
the
catalog
stuff,
by
the
way,
ghcr
right
now
lists
the
full
catalog
and
if
you
do
a
at
least
on
that
is
just
a
nightmare
but
I
wanted
kind
of
to
maybe
give
our
perspective
or
more
specifically,
my
view
on
where
we
and
why
I
was
kind
of
initially
involved
in
driving
this.
This
discussion
until
Scott
took
it
over
and
kind
of
he
drove
it
into
the
attack,
Hub
delivery
stuff.
A
We
were
looking
for
a
much
deeper
search
capabilities
than
we
currently
have
and
honestly
we
are
kind
of
starting
to
see
some
limitations.
Let's
say
on
even
on
the
referral
apis
right,
because
one
thing
is
to
go
and
find
something
in
a
big
catalog
right.
We
don't
want
to
actually
go
and
list.
The
catalog
then
browse
the
Json
use,
JQ
and
so
on
to
to
find
the
thing,
but
we're
looking
for
to
index
also
based
on
certain
types
right.
A
This
life
cycle
discussion
that
we
had
and
one
of
the
issues
with
canonical
folks,
you
participated
there.
So
it's
it's
not
just
like
getting
the
the
the
the
catalog
and
getting
a
couple
of
referrals.
I
have
I
talk
with
customers
that
they
say
now.
We're
gonna
push
all
these
s-bombs
I,
don't
want
to
go
and
store
the
index
of
the
s-bombs
in
some
other
storage.
Now
they
come
back
and
say:
can
I
go
and
find
every
image
that
has
locked
for
j214?
No,
you
cannot
write
now
and
I.
A
D
It's
true
what
toddy
was
saying
that
the
idea
was:
could
it
be
a
sub-project
divorce?
That's
focused
on
this
and
we
just
kind
of
work
on
an
extension,
and
we
just
try
to
prove
this
test
this
out
and
prove
this
out
and
and
leave
it
at
that
and
we're
not
leaving
at
that.
But
let's
start
with
that
and
yes,
that
can
definitely
happen.
D
Or
every
type
of
application
and
platform
related
thing:
there
are
many
many
different
yeah,
not
just
applications,
but
things
like
things
like
rules
for
four-year
platforms
and
so
on,
like
all
of
that
they
they
can.
They
are
and
can
be
artifacts
of
different
types,
but
they
don't
all
share
a
common
specification,
they're,
not
all
using
oci
artifacts
or
supporting
it.
We
would
like
them
to
and
we
would
like
to
help
use
the
new
artifact
type.
Well,
not
not
new,
but
you
know
the
newer
artifact
type
field.
D
J
D
E
D
Personally,
going
to
be
there
I
I,
I
I,
don't
know
how
many
other
folks
in
this
call
are
going
to
be
there,
but
but
that's
exciting,
and
so
she
was
saying:
hey
the
really
before
starting
a
working
group
within
cncf.
Just
just
talk
to
the
oci
people
to
make
sure
that
that
it
makes
sense
and
that
you're
not
somehow
misaligning
so
I
think
that's
our
our
main
goal,
or
that
was
my
main
goal.
E
D
D
But
we
do
want
to
explore
this
and
do
what
tati's
talking
about
and
really
just
try
one
way
or
another
try
to
see
how
we
can
help
that
happen
and
invite
you
all
to
join
that
too
and
I
wonder
if
that's
I
wonder
if
that
would
be
given
all
the
discussion
so
far
like
Brandon,
for
example,
I
wonder
if
that
would
be
kind
of
good
enough
for
now
and
say:
Hey.
Listen,
we're
going
to
start
joining
each
other's
meetings
a
bit
and
and
And
discussing
this
kind
of
functionality
and
moving
ahead.
C
C
K
K
The
pro
like
some
of
the
problem
statements
would
be
helpful
for
me
into
like
it's.
It
feels
kind
of
generic
like
the
abundance
of
package
types
and
formats,
adding
complexity
and
confusion
like
I,
don't
know
what,
like
there's
there's
a
lot
of
Patrick
package
types
that
exist
today
and
a
lot
of
the
clients
are
there's
like
a
one-to-one
relationship
between
a
client
and
a
package.
Type
and
I.
Don't
know
how
or
why
that's
a
problem
like
a
lot
of
people
are
doing
things
with
what
exists
today.
K
Now,
when
I,
when
I,
when
we
when
I
look
down
to
the
like
the
the
proposed
activities
or
potential
work
like
the
the
search
and
Discovery,
definitely
fits
very
well
into
the
the
oci
or
or
like
getting
feedback
from
the
oceanic
group
makes
a
lot
of
sense
for
that.
When
I
think
of
more
generic
things
like
security,
then
my
my
head
kind
of
explodes,
if,
like
all
right
well,
there's
the
open,
ssf
doing
all
sorts
of
work
in
in
supply
chain
security,
specifically
in
the
securing
software
repositories
group.
K
But
then,
when
we
like
slightly
step
out
from
that
into
s-bombs
like
then
it
explodes
even
more
and
so
like.
Is
there
a
problem
specific
to
supply
chain
metadata
that
we
would
like
to
see
solved
in
a
way
that
could
apply
to
all
different
package
types
I
like
I,
think
that
would
be
a
really
interesting
conversation
to
have
I.
Don't
know
how
many
people
in
this
group
are
interested
about
that
conversation
and
like
it's.
It
quickly
spans
three
different
Foundations
at
least
and
many
different
working
groups.
K
E
L
G
Yeah
John
I
think
my
response
to
that
is
I
feel
like
we're
not
being
ambitious
enough
in
some
of
these
spaces,
where
we're
having
to
reinvent
the
wheel
in
terms
of
how
to
attach
an
s-bomb
or
how
to
attach
an
attestation
to
something
over
and
over
again
and
I
would
really
like.
This
is
just
my
own
perspective.
This
isn't
essentially
participation,
WG,
artifacts
or
or
oci,
or
anything
like
that.
G
But
can
we
nudge,
or
can
we
figure
out
how
to
make
an
oci
registry
expansive
enough
that
it
could
be
used
as
an
npm
package
repository
that
it
could
be
used
as
a
Pi
Pi
backend
that
it
could
be
used
as
I?
Look
at
a
tool
like
a
jfrog
artifactory
right,
which
is,
is
almost
essentially
the
gold
standard
for
how
you
do
internal
package
management
and
and
understanding
your
security
landscape
in
an
Enterprise,
and
they
have
30
40
50
Integrations
with
different
sort
of
protocols
that
they
have
to
support.
G
That's
a
huge
Matrix
of
things
to
figure
out
how
to
attach
s-bombs
to
all
of
those
things,
how
to
attach
an
intodo
accessation
to
how
that
thing
was
built
to
all
of
those
things,
but
an
oci
artifact
or
an
image.
That's
an
artifact
whatever
with
an
s-bomb
attached.
That
is
really
clear
to
me
and
we
could
build
common
protocols.
G
I
really
want
to
think
about
how
we
can
build
something
that
works
for
packages
and
package
authors
and
also
to
enable
the
next
sort
of
generation
of
tooling
right,
like
the
next
top
programming
language
they're
going
to
have
to
build
their
own
registry
right.
That's
basically
table
Stakes!
Now
for
every
new
programming
language,
every
new
project
is
to
figure
out
how
to
build
a
registry
can
oci
and
possibly
WG
artifacts
sort
of
Define
like
here's,
how
you
do
it
and
you
don't
have
to
buy
into
all
of
these
features.
G
This
is
a
uniform
way
of
getting
there
and
I.
Think
that's
really
exciting.
To
me,
it's
much
more
exciting
to
me
than
trying
to
solve
this
at
one
registry.
At
a
time
one
npm
one
Pi
Pi
at
a
time.
Can
we
solve
this
once
and
build
something
robust
that
scales
to
yeah,
something
as
small
as
the
a
new
project,
but
also
to
as
large
as
something
like,
Docker,
Hub
or
ghcr.
I
I
work
with
customers
everywhere,
and
what
do
they
all
have
in
common
these
days?
They
have
a
registry,
they
may,
they
may
have
Nexus,
they
may
have
artifactory,
but
they
have
a
registry.
The
reason
why
I
got
into
this
space
is
because
I
was
an
avid
Helm
user
and
standing
up
a
distributed.
Helm
capability
was
a
pain
in
the
ass
if
you're
familiar
with
Helm,
because
you
had
to
do
deal
with
HTTP,
you
know
end
points.
It's
like
I,
don't
know,
I,
don't
want
to
deal
with
that.
I
I
want
to
just
be
able
to
throw
my
damn
Helm
chart
in
a
damn
registry
and
call
it
a
day.
That's
why
very
much
just
like
you
just
said,
Aaron
I
want
to
be
able
to
put
everything
on
the
damn
oci
registry
call
it
a
day
and
be
able
to
search
and
use
it
effectively.
That's
it
that's
why
I
have
been
really
focused
on
working
with
the
community
to
help
enable
these
type
of
capabilities.
E
J
I
L
They
can't
be
stakeholders
and
and
creating
working
groups
and
oci
so
like
it
for
any
of
these
efforts,
I
think
it
makes
sense
to
have
that
working
group,
otherwise
we're
all
just
going
to
come
back
here.
Every
week
and
kind
of
semi
discuss
the
same
topic
with
no
deliverables,
so
I
think
having
something
scoped
and
some
deliverable
around
artifacts
makes
sense
like
yeah.
It
was
kind
of
brought
up
earlier
with
the
on
the
chat
about.
L
Like
the
output
of
that
is,
it's
kind
of
like
artifacts
kind
of
squeaked
in
and
then
we
didn't
quite
figure
out
like
where
it's
going
to
go
from
there,
but
I
think
having
something
that's
specifically
tied
to.
We
want
this
artifact
manifest.
We
want
a
working
group,
we
have
it
tightly.
Scoped
to
that
like
that
makes
more
sense,
and
you
know
the
discovery
like
that
can
be
a
separate
working
group.
L
We
don't
need
to
try
to
do
them
all
in
one
again,
like
we
have
an
artifacts
working
group
and
then
we're
like.
Oh,
we
also
want
to
do
Discovery.
Let's
get
that
in,
like
I
think
it
makes
sense
to
to
have
like
those
tightly
scope
at
the
oci
level
like
higher
up
I.
Think
it
makes
sense
like
for
those
tags
to
have
their
own
kind
of
higher
level
discussions,
but
at
least
something
that
scoped
to
oci
scope
to
specific
output,
I.
Think
it's
more
beneficial
for
oci
like
we're
not
like
a
generic
prototyping
group.
L
We're
like
hey,
there's,
there's
the
very
specific
thing
people
are
using
and
want
like,
let's
design,
let's
figure
out
like
how
we
how
we
actually
standardize
that,
and
the
same
goes
for
like
if
there's
a
cat.
If
we're
doing
some
sort
of
discovery
like
like,
we
need
to
have
something:
that's
could
start
with
some
sort
of
prototype
and
we
can
standardize
it
not
just
like
these
open-ended
discussions
that
really
can
go
on
forever.
With
everybody's
opinion,
yeah
I'll
stop
talking.
G
Yes,
yeah
I
just
want
to
say
I
I
completely
agree:
I,
don't
think
that
there
needs
to
be
a
tight
coupling
between
the
process
of
a
cncf
group
and
oci
right
that
I
think
within
cncf.
It's
common
for
working
groups
to
be
relatively
long-lived
and,
have
you
know
multiple
sort
of
outputs,
but
each
of
those
outputs
could
individually
be
its
own
ocni
matter.
I.
Think
there's
a
reasonable
I
think
going
back
to
earlier
in
the
call
I,
don't
think
oci
would
want
to
immediately
standardize
anything
that
the
tag
said.
C
Yeah
I
think
the
second,
what
you're
saying
Derek
I'm
a
strong
fan
of
more
and
smaller
and
more
rapidly
iterating
working
groups
I
think
the
biggest
reason
we've
avoided
one.
That
so
far
is
that
just
bandwidth,
the
people
that
are
implementing
a
lot
of
stuff
only
I
only
want
to
go
to
so
many
meetings
in
a
week
and
so
trying
to
spin
up
a
whole
lot
of
working
groups.
All
at
once,
simultaneously
is
terrifying
to
me
personally,
but
yeah
definitely
a
hard
agree.
It's
more
and
smaller
working
groups
is
a
good
plan.
K
However,
we
do
like
we
end
up
in
this
interesting
overlap
of
what
is
the
the
lowest
common
denominator
and
and
to
make
it
as
generic
as
possible
of
like
not
every
artifact
may
exist
inside
of
a
registry,
and
not
every
artifact
may
even
be
Cloud
native
and
like
if
we
want
to
say
that
in
so
that's
where
it's
like
from
the
scope,
though
of
of
cncf,
it
has
to
be
a
cloud
native.
Some
things
an
open
ssf
are
are
not
at
all
Cloud
native
or
or
other
like.
G
Yeah
I
completely
agree.
There
is
a
degree
of
of
philosophical
idealism
in
what
I
said
earlier,
no
more
than
just
a
little
degree,
there
was
quite
a
bit
and
pragmatically
you're
not
going
to
get
all
of
these
language
package
managers
into
oci
right
or
at
least
anytime
soon,
but
the
way
I
think
about
these
things
is
that
the
vast
majority
of
things
that
will
ever
exist
is
in
our
future
right.
C
Cool
well
we're
at
time
had
an
awesome
conversation.
I
appreciate
everybody.
That
said,
all
the
went
through
all
the
great
conversations
there
I
do
want
to
throw
two
little
quick
agenda
things
in
there.
The
two
open
PRS
that
we've
got
still
also
third
thing:
I'll
welcome,
Tiana
new
maintainer
awesome
appreciate,
welcome
aboard
and
then
the
higher
up
in
the
thing
for
our
kubecon
EU,
there
is
a
link
to
the
hack
MD
over
there.
So
if
you've
got
topics
you
want
to
discuss
during
that
event,
fill
out
that
as
well.